Which CGI Language For Which Purpose? 332
zpengo asks: "The blessing and curse of CGI is that there are dozens, if not hundreds, of ways to accomplish any given task. All languages have certain strengths and weaknesses, and there is no "best" CGI scripting language. I'm wondering what the community has learned about CGI languages through their experiences. Which languages go best with which tasks? (Also, are there any less-known languages that work well for particular circumstances?)"
What about the children? (Score:2)
What, for example, is the name supposed to imply?
That this language is so far removed from reality that nothing will affect it?
That this language will give you feelings of strength, power, and invulnerability?
That this is a "supercharged" web scripting language that will stop at nothing to achieve whatever delusional whims you set out for it to accomplish?
That this language will put some real "rocket fuel" into your dotcom enterprise, even more so than, say, small investments from an angel? (Which would be "angel dust", no?)
Let me ask you, then - what kind of message does this send to our children? I have a twelve year old daughter who wants to be a webmaster, and she came home from school the other day and asked me about PHP. What am I supposed to tell her? That it's ok to use it professionally, but not recreationally? Only if you're putting up a website? Please -- we all know that that's the long slide towards addiction, a mad quest for the drug, and finally going broke and living under an overpass with a 40 oz. bottle of Old English, begging money from passing strangers and carrying on extensive conversations with crows, pigeons, and skinny, mangy rats.
Somebody needs to take a hard-line stance against this language and make sure that it spreads no further. Why can't people use sensible, wholesome languages such as Perl [microsoft.com], Python [perl.org], ASP [python.org], and TCL [uni-ulm.de]?
Next time, before you go and create a scripting language with dubious moral intent: think about the children. Please.
Like Perl and Java Servlets--Love PHP (Score:5)
PHP (Score:2)
As for database support, it's very thorough though I'm having a little trouble getting PHP4.0 to compile against Solid 3.5. Of course I've only put an hour or so into it, including download time.
----------------------------
Be careful of PHP; separate code and layout. (Score:2)
I've said it before, and I will say it again: Do everything you can to separate the program logic (the code) and the HTML layout.
Why:- The people who originally build, or later fix, the HTML may very well be different than the people who work with the code. The skill sets are almost completely different, but if you let the two comingle, you will require the maintainers be proficient in both skill sets.
- If the look of your site changes but the code and the HTML are entangled, it can be very easy to break program logic while trying to make visual changes.
- If you ever hope to support multiple natural languages, you're going to want your program logic to reside in completely different files from any of HTML or visible text.
- Clean application design and clean web design are almost completely incompatible. If you try to find a compromise between them that lets you alternate between code and HTML, you will get a result that is bad design for both targets.
- Future content formats (such as XML) might be nearly trivial if you can keep the layout (currently HTML) seperate from the code.
How:So in conclusion, I would recommend perl along with HTML::Template. This also allows for future migration to mod_perl instead of CGI, giving you a performance upgrade path. Although this is obviously not the best solution in all cases, it very often is the best, and is very rarely the worst.
--Chouser
Separate code and layout (Score:5)
I've said it before, and I'll say it again: Do everything you can to separate the program logic (the code) and the HTML layout.
Why:- The people who originally build, or later fix, the HTML may very well be different than the people who work with the code. The skill sets are almost completely different, but if you let the two comingle, you will require the maintainers be proficient in both skill sets.
- If the look of your site changes but the code and the HTML are entangled, it can be very easy to break program logic while trying to make visual changes.
- If you ever hope to support multiple natural languages, you're going to want your program logic to reside in completely different files from any of HTML or visible text.
- Clean application design and clean web design are almost completely incompatible. If you try to find a compromise between them that lets you alternate between code and HTML, you will get a result that is bad design for both targets.
- Future content formats (such as XML) might be nearly trivial if you can keep the layout (currently HTML) seperate from the code.
How:So in conclusion, I would recommend perl along with HTML::Template. This also allows for future migration to mod_perl instead of CGI, giving you a performance upgrade path. Although this is obviously not the best solution in all cases, it very often is the best, and is very rarely the worst.
--Chouser
Re:Separate code and layout (Score:2)
Actually, PHP never "encouraged" embedding code in HTML. It just enables it. You can do it and you can avoid it. For the latter approach use "templates" mechanism, which, for example, is a part of PHPLIB [netuse.de], though I don't like their implementation too much. Seems to be analogous to HTML::Templates from the standpoint of functionality.
Remeber, PHP is a tool, tool can't determine it's use. It is the programmer who tells the tool how to work.
Re:Using C++, but open to (constructive) suggestio (Score:2)
On top of that, if you get in to J2EE then you reach the level were you don't have to worry about the database at all, where your own objects can be distributed, and where you can embed Java into web pages.
Seriously, give it a whirl.
APL: Largely Not An Option (Score:3)
Unfortunately, ISAP - Information Server Auxiliary Processor [aplteam.de] from Dyadic Software offers APL integration only with MSFT IIS, and does not run them as CGI programs.
On the other hand, German speakers might find something useful at Sergy Alpin's JUMP page [snafu.de]
I hear rumor that NIAL, an APL with with a Lisp-like syntax, offers the ability to run it in CGI apps...
So, for those that feel the need to write web apps using reduction operators, preferably without ever using the diamond operator ( looping! ), it seems rather likely that there are some options available. Perfect for making use of that IBM 360 you picked up on eBay...
I somewhat think I'd rather do my APL reduction work by way of the Common Lisp (reduce #'whatever-function whatever-list) function, mind you....
Graphics (Score:2)
That's all very well, but the CGI interface allows you to generate any kind of MIME type you like.
Some of the CGI scripts I'm happiest with are written in GNUPlot, and display PNG graphs of live data.
I guess GIMP's Script-FU can be used for nifty CGI scripts; also NetPBM.
--
Re:Some language, any language (Score:2)
ColdFusion also runs as a separate process, but for some reason you can only run one of these servers on each machine. Ick.
Re:coldfusion--ick... (Score:2)
an ex-Perler now using Python (Score:2)
Its regular expressions are excellent, and its syntax is very nimble. However, there are various design flaws (such as lists not being intrinsically nestable without using a lot of ugly reference kludges). Perl's object orientation is somewhat of an afterthought. Also, because of its flexibility of syntax, Perl encourages unstructured coding.
A few months ago I looked at Python, and after going through the tutorial [python.org], I was hooked. It really is a much more elegant language for programming. Also, it has a first-class collection of classes and utility functions.
These days, I use Perl for writing short text-processing hacks and the like, and Python for anything larger, which includes most CGIs.
Thinking outside the box (Score:2)
- updating the order database
- communicating with distributed objects
- handling file conversion (we do this with TIFF -> GIF and TIFF -> PDF translations for a couple online systems we've written)
This system is written to be fast and to provide core services. It takes your best programmers to write it, and you test the hell out of it.
The front-end system can run anywhere, via any Web server, written in any language. So long as it can connect to the dedicated server (via URLs or a simple socket-based communications method), it can do simpler processing and the generic request/response cycle.
Your more junior people can easily handle writing the front end then -- they just use the API to the server, and handle the tasks of the presentation layer.
This means speed is less of an issue (the optimized server handles it, and can even act as a transaction processor or middleware), and the parts of the system that change most (the presentation and navigation) are easy to code and do not affect the underlying business logic.
Sometimes it helps to be creative like that, it's solved a lot of problems for us. Your dedicated server can even be as simple as something like Apache+jserv with some simple servlets that are accessed via URLs and return an XML document as a response. This also helps when you eventually want a more distributed, load-balanced system. Have too many image conversion requests? Add another dedicated box for that purpose, and made it part of a round-robin DNS scheme.
CGI Languages (Score:5)
Perl
Awesome language. Great library support (stellar, really) and very easy to learn. Stick to good programming practices, avoid the dark side, and you can do a lot with it.
For anything beyond trivial apps, mod_perl or a similar accelerator is definately needed.
Object oriented programming is fairly nice; it allows OOP without being strictly wedded to it, and it has very powerful introspective and adaptive features (closures, ability to interrograte and modify the symbol table so you can actually *add* methods dynamically as the code runs. Wow. Allows multiple inheritence if you really need it).
Database programming via DBI/DBD is very well supported.
Java
Another good tool. A very nice OO syntax, strict exceptions to insure a robust system, and an architecture for using it with a Web server (Servlets). Add to that JDBC (which is well supported, and not hard to use or learn). Also add introspection and built-in RMI.
I haven't used Enterprise Java Beans at all yet, but I like the concept. Implementations seem fairly weak and non-performant so far, however.
I would prefer Java over Perl in cases where I needed to have a distributed system that might talk to other systems I didn't code or have ability to modify. In Java, CORBA and RMI are pretty easy to use, and EJB support will probably be well worth having in the somewhat near future.
Java is a lot more inherently performant than Perl, although the difference between jserv and mod_perl is not all that huge in our tests.
Bad points of Java: the compile cycle bites once you're used to Perl (edit and run). It also is a tad too strict (again, once you're used to a more free-wheeling approach in Perl).
Tcl
Phil at photo.net [photo.net] loves this. He uses it in AOLServer, which handles embedded Tcl (somewhat like mod_perl?). It has the same sort of benefits as Perl (no compile cycle, loose syntax and ability to do things more than one way, several libraries), but I personally never liked Tcl all that much. I wouldn't rule it out, though, check out photo.net.
C/C++
As usual, use this for maximum speed. Despite any claims people might make, Java is even in the best of cases not as fast as C. However, C is not going to be the fastest language to develop in, and since speed to market and ability to adapt are often key in Web programming, I tend to not consider C or C++ a good choice. The lack of a lot of external support or common specs hurts C and C++ -- I'm not aware of a server-independent API for "embedded" C code (like Servlets are for Java, for instance -- code that runs with the Web server persistantly or on some other persistant server). C could be great for implementing a separate server process that front-end scripts connect to from the Web server. Imagine a mod_perl front-end that connects to a server written in C -- this could be pretty fast and have a lot of flexibility.
Just throwing ideas out. Maybe this answers some part of your question??
Oh yeah, speed of text processing! (Score:5)
Perl is great for two other reasons: text processing in general is great (the language was built to do that as it's first design goal!), and regular expression support is first-class.
Given that most Web programming is pure text-processing work, Perl has a big leg up there. Java lacks simple text processing (it can do it, but the code is more verbose and harder to write), and C, although fast, has little text-processing built in to the standard library (other than scanf, strtok, and other functions I'd love to forget ever having learned ).
So yeah, another win for Perl. Text processing is easy to code, and fairly well optimized, given that it's the core of the language. I also find DBI/DBD easier than JDBC!
So, to reiterate, my preference is:
Perl, Java, C, C++
But choose wisely! Pick something you feel competant to program in, something that addresses your needs of speed and complexity, and something that is maintainable!
As an aside, I skipped all those "code in page" paradigms: ASP, PHP, JSP. I just cannot pursue those sorts of paths, because in all my experience, the need to totally separate presentation and code is pretty strong.
"Hey, you got code in my HTML!"
"Hey, you got HTML in my code!"
Not a nice mix
(As an alternative, we use a templating language with XHTML + XML that our code can "fill in" values in and branch around conditional text.
Home grown, but very effectively for our purposes)
Apache C module (Score:3)
There are a few reasons why mod_virgule was a more pleasant programming experience than your usual CGI script in C. First, Apache's pool mechanism lets you use memory without having to worry about freeing it. It's almost as convenient as using a garbage collected programming language. Second, the Apache module API contains a lot of functions for regexps, tables, lists, and so on. These are the most important features of Perl that are lacking from raw C. It's nice to be able to write code in C that has a bit of a Perl "feel".
Finally, mod_virgule uses XML extensively in the backend, using Daniel Veillard's excellent libxml [xmlsoft.org] for parsing and handling. The use of XML makes the code for the site a lot cleaner.
So, I suggest that you not reject C out of hand just because it has a reputation for being more difficult or time-consuming to program than your more popular interpreted scripting languages. For what I was trying to do in mod_virgule, it turned out to be an excellent choice.
Re:The list (Score:3)
--
Re:Like Perl and Java Servlets--Love PHP (Score:3)
- However, PHP, even well-written PHP. will never be as fast as a well-written mod_perl handler, for the simple reason that mod_perl handlers are compiled once and live in memory for the life of the Apache server (parent) process.
This is fixed in php4, using the zend engine. It automatically compiles and optimizes your php4 code.http://www.zend.com [zend.com]I write php for a living, and love every minute of it, it's a dream to code in. I've yet to run into any problem that I can't solve. I hear people bitching about perl all the time, granted most of those people bitching are people that have gotten used to php already....
---
Python or Perl (Score:5)
Now, what you choose SHOULD be based on your server. Although in this case I'm of the Linux mind, I do see MS IIS or whatever as a valid if somewhat more buggy variant on the web-server landscape. Apache is still the best server out there if you want real POWER over you system. So, the first question you have to ask yourself is what platform you will be using. In the Win32 world, you have a lot more choice than most realise because there is not only ASP, as simple Microsoft Scripting language (though I personally abhor it) and the Microsoft Internet Classes for both MFC and COM. One thing you have to watch out for though is depending on the client browser's platform. Relying too much on Win32 could completely alienate Macintosh users, never mind *NIX. However, there exist Win32 ports for both Python and Perl so whichever you choose you should be safe in developing for the target server platform. I personally give extra points to Mark Hammond's WinPython UI. Also note that Zope has been ported to Win32 in case you decide to go the Python-Zope route. More on Zope later.
The beauty of CGI is that it only runs on one or a small number of machines so you have complete knowledge of the architecture on which your CGI will run. Such is not the case for UNIX Shell Script [sh, bash, or *csh], and except for the smallest of Web applications, Perl is typically just as good. Such is not the case with JavaScript or VB Script or even the state of the Java VM of whoever is your client. One thing I will say though is if you're sure you'll have a small client base, you can safely rely on your clients all running the latest version by forcing them to get it from Sun periodically. However, if the client base is large, this is prohibitive. Not only will you get more complaints from people regarding the frequent updates, but also you'll have a greater chance of introducing bugs because the users are not properly updating. The alternative is to stick with the AWT 1.0 distributed with most browsers and suffer all those nasty bugs with a lost of nasty kludges.
Anyway, so I've brought up Java, and now let me relate it to CGI. Basically, the question is, who plays better with Java: Python or Perl. I think given JPython alone Python can take that match, so if your client base is small, or you can suffer all the kludgy bugs of the nasty Java VM distributed with most web browsers, and you want to distribute some of the work over the clients using Java, Python is the way to go.
Next I want to discuss text processing. Text processing tends to be a big part of web development and thus having a good parser is a major benefit. In this contest, Perl wins hands-down. There is no better language for text parsing I know of, and not even Snowball can out-perform Perl in this respect. However, Python 1.6, now in Beta, is supposed to introduce UNICODE Regular Expression matching narrowing the gap between the two languages quite a bit.
Now for size, each language can serve a different need entirely. For small-scale applications, Perl is easy to hack and quickly get your programme out. However, once you know Python, you can code at comparable speed. The Python advantage comes out in the large-scale project. Since Python is a strictly-syntaxed language as opposed to the more free-form Perl, it is typically much easier to understand for the new programmer or developer. It is much easier to debug Python code than it is Perl. However, a skilled programmer in either discipline will code the same application in near comparable time, the training a Python coder to use Perl or a Perl coder to use Python is usually pretty easy to do, though the time to train in a small application may not make it worth it. As a rule of thumb, the larger the project, the more of an advantage you'll get out of Python. Also the more hands you need to develop a project, the easier it will be to co-operate with Python, as the code is easier for an outsider to understand.
Now both Python and Perl have a byte-code and many many libraries, so there is little advantage with either, though perhaps because of the longer life I think we can give reusability over to Perl. After all, more people have been developing Perl than any other CGI language over time. The same goes for third party support, such as connecting to a database. One advantage I think Python has though is the ease with which one can convert Python code to ANSI C++, my personal language of choice. With the Python / C++ combination, one can develop prototypes quite easily and quickly in Python, then slowly move each component over to C++ for speed. [Yes, you could move to ANSI C too, but why would you want to when good C++ code can be just as fast and is a lot easier to understand.] To be sure, you can do the same thing with Perl but the languages [Perl and C++] don't convert as well and the interface, as will most things Perl, is rather kludgy.
Now, there is one issue with web development that neither Python nor Perl do address well, and that is remote development. Typically to do remote development, you have to either SSH / Telnet to the server and do your work there, or more typically run a web server locally and synchronise files from time to time as needed for each version. However, with a tool like Zope, you can do all of your development remotely without having to use ftp or telnet. Plus, Zope is built from Python so you can extend it with packages and external methods written in Python quite easily. The downside to Zope is that for package development it is very tedious to use. The problem with Zope is that for every change you make to a package structure, you need to restart Zope for it to recognise the changes. This can be tedious in the extreme. Another possibility is Microsoft Visual InterDev, which relies heavily on Microsoft components and architectures. I don't recommend it for anything but the most Win32 of circumstances. There is also Web Objects, which can make development very simple but the price / performance ration is usually out of the range of all but the most corporate of servers. However, none of these give the true Web feel of a good CGI script and there is no substitute for the usefulness of Python or Perl.
In conclusion, I'd say you could use either language for just about any web application, but certainly for pre-existing libraries Perl is your best bet, and for long-term development you should go for Python. Whatever you choose, I wish you luck and hope that I can in even a small way have been some help.
Be Seeing You,
Jeffrey.
Re:CGI and ASP (Score:3)
example --
response.write "This is a ""test""."
I have found the most frustrating thing about vb scripting under asp is the syntax.
Such as
response.write "This is a line 1." & vblf _
& "This is line 2." & vblf _
& "This is the last line"
I like php3 and perl. You can do this...
print ("This is line 1.
This is line 2.
This is the last line");
With that little ; you know where the end of the line is. It makes tracking down syntax errors _ALOT_ faster.
ASP does have some nice real world features to it that make things easy, such as formatcurrency(). I hate having to write a function to format a number as currency.
On the other hand, I _LOVE_ how php3 will assign values to variables that posted to a page. No more request("variable") or request.cookies("variable"). You get $variable.
I have to program asp at work, but I love php3
I don't buy the difference as being that big (Score:3)
As for mod_perl and multiple CPUs, that is no problem. Apache is designed to have multiple child servers running in parallel. Different children get different CPUs and so mod_perl will scale across CPUs. If you want single requests to multi-thread, this is not good. If you want to have multiple people using the site at once, this is quite sufficient.
Of course this has issues on operating systems like Solaris that do complex things to try to optimize threads. But when Linux can do a process switch faster than Solaris does a thread switch on identical hardware, I have to wonder whether those complex things are worthwhile.
Now redundant memory usage is a real problem, and a big one. mmap helps (a lot) on this, but this is a big loss for Perl. No, it won't be solved soon. But then again Perl has always taken the view that memory is cheap, and indeed it is getting cheaper and faster. So it probably isn't that big of a loss either.
Another big loss is clustering. Java solves that better than Perl does. Perl is dependent upon the OS. Of course the direction that Linux is heading is very clustering friendly, Apache has pressure to do likewise, so again you can act as if that it is not Perl's problem.
So yes, I agree with quite a few things that you said, but I don't think that it reflects badly on Perl.
Cheers,
Ben
Don't underestimate the power of builtins (Score:2)
The builtins (esp. those of PHP3) also save you a lot of typing. The great advantage of Java Servlets (over mod_perl and PHP3) at this point is, that it's so easy to share data among Servlet threads, so they are much more memory-efficient if used correctly.
The answer is simple (Score:2)
The one you know.
More specifically, the language you know well enough to write the required program.
If you're struggling to make it work at all, it won't work well.
Now, if you're wanting to know which languages you should LEARN, we're headed into religious war territory, but here's my opinion:
Perl and Java.
Between the two, you have enough options to do anything, including compilation with processor-specific optimizations, and you'll find more documentation than you can shake a stick at. You can practically close your eyes and grab a book at random from your local book store, and have a reasonable chance it's about one or the other.
--
languages (Score:3)
Some of the CGI that I have done is intensly complicated and involved a well thought out design and implementation. And it involved a bunch of people working on the same project--so it needed to be easy to read and object oriented. For this Python is really good.
Some of the CGI that I have done needed to run fast and I had canabalized it from other places. This is pretty much entirely in C. C is good, but takes too long to write.
Hyper Builder (Score:2)
I would like to invite you all to check out Hyper Builder, at http://bachue.com/hb [bachue.com]. It is a very simple "scripting language" that allows you to solve many of the typical web-development problems very easily.
It has a system of modules (which can be loaded dynamically at run time or compiled into the interpreter). This works kinda like Server Side Includes where the tags are mapped to callback functions in the modules.
HB comes with a standard set of useful modules. Some examples are the SQL module (currently supporting MySQL and PostgreSQL), the Wall module (to make bulletin boards, guest books, etc), the polls module (with lots of code from Pollera, a standalone application for making polls on the web), the Perl module (to embbed Perl code in your pages), the access counter module, the authentication module (which can authenticate against different backends) and many other. They allow you to do things such as set/read cookies, show input from HTML forms, print the system time, show the output of system("commands"), send email, show/write files, etc., very easily.
You can also combine all those different modules very easily. It's kinda messy to combine all the different Perl scripts you just downloaded and have them show all their output in the same page. You end up editing different scripts to have them print the HTML the way you want and use something like Server Side Includes to tie them together. With HB it's natural to do things such as placing a message wall under the poll and allowing only registered users to vote (you are using the walls, polls and authentication modules here). And just in case you can't find a module to do what you are looking for, you can always go create it in C or Perl.
HB can run as CGI (useful when recompiling Apache is not an option and performance is not that important) or as a pthreaded application server that a Apache module provided contacts via a TCP socket (increases performance greatly and lets you run the application server and web server on different machines).
You can take a look at some examples of what can be done with the standard modules at http://bachue.com/hb/ex/examples.cgi/ [bachue.com]. The source code for all of them is provided in http://bachue.com/hb/ex/examples.hb [bachue.com].
One big advantage of HB over other systems such as PHP, Servlets, ASP, Perl, C+CGI and Zope is that it is very easy to maintain big sites designed on it. For example, showing an access counter usually goes like doing <counter src="file" inc="1" show>. In all the other languages, you usually have to open the file, lock it, read the counter, increase it, write it, close the file (unlocking it) and print the counter. Since everything is so easy to do, sites are very easy to maintain.
Anyway, I strongly recommend it for your web development.
Alejo.
Disclaimer: I'm the current maintainer of HB so I might be a little biased.
Did I miss something? (Score:2)
Oh, you mean the other CGI.
The Zend optimizer (Score:2)
Most Obscure CGI Language: RPG IV (Score:2)
I am not making this up. [ibm.com]
Yeah, it sounds nutty to me to.
Re:Don't use Java (Score:2)
People use Java with servlets and/or JSP, which starts up the JVM once, so the JVM startup time argument is irrelevant.
----------
perl is fast enough (Score:2)
Re:Like Perl and Java Servlets--Love PHP (Score:2)
Fixed in php4. Next?
You want to modify how the URI gets translated into a filename? You can't do that in PHP.
Yes, you can. I'm beginning to think you haven't used PHP.
You want to customize the authentication process? Nope, you can't do that in JSP.
That may be true in JSP (I haven't tried it), but in PHP it's a cakewalk (can you tell which side I'm taking?).
For anything other that generating output, you have to use either C or mod_perl.
I'm thinking you're smoking something. I consider socket communications, DB access, mailing, LDAP/SMB/PAM access, and the ability to run any executable in reach... a bit more powerful than just producing output. Don't know again about JSP (did I mention I don't use it?) but PHP can do these, and I'd grudgingly admit you can pull off the same tricks with ASP if you know where the right hooks are.
And the beauty of the whole thing is -- yup, you guessed it, it runs at memory speeds -- no filesystem accesses (unless you write them in specifically), no scripts to stat, no logic/HTML combination to parse.
This is a bit of a red-herring. Everything that doesn't need pre-processing will run at memory speed (or the closest approximation thereof since you ignore paging/swapping/etc. in your discussion, which is fine as we aren't holding an operating systems seminar here) as long as it has everything it needs. Talk to a database? Open a socket? Open a file? Run an outside script? The point about compilation is essentially dead-on (which is why the Zend engine for PHP is a Good Thing(tm)). If you're really pressed for time/memory however, right your own mod_* for Apache.
Most of this is merely for the sake of argument though -- I've been a Perl zealot for years. Now I do a lot of presentation in PHP, and save Perl for the heavy lifting. I optimize THE HELL out of my perl though, and use mod_perl when possible. I hate the thought of JSP (what an abortion) and so don't use it, and ASP is of course "right out".
Re:PHP - how to avoid mixing code and HTML. (Score:2)
So how do you code a loop in these "fast templates"? Oh, wait... you code the loop separately in the macro and just drop in the template referring to that macro to position its output. Yeah, that's it. Scatter the code around in pieces so I have to jump around from file to file to see what the hell you are really doing. That's not unlike having a bunch of function calls. But I don't think the boundary between separated chunks of code should necessarily be forced to be aligned at syntax class boundaries.
The whole issue of code mixing is just a special case instance of the long time argument about whether separation or consolidation of code is the better choice. And each has its advantages and disadvantages. The difference here is that we are fixating on a boundary between steps that are each optimally coded in different languages.
The solution I generally use (and there are exceptions to this, too) is that if the modular element is (or can be made to be) a re-usable piece of code, then it should be separated (e.g. make the template) but if it is just a component of the current object (page) it should be consolidated. For example, if I have a menu of actions generated from what permissions a user actually has rights to do, it may be re-useable (if more than one page would have the same menu) or not (if each menu set on each page is different). One option is to make it like a function call if I can pass arguments to it (but I don't see how you might propose a syntax to do that) such as giving it a list of menu items appropriate for this page for it to actually output those the user has permission to do. Of course, once you do that (add argument passing systax) you're moving back to mixing code because you're going back to programmer, rather than layout, syntax.
Personally, I'm not opposed to mixing code at all. I can read HTML, and PHP, or even C, equally well. My C code typically has tons of printf calls generating large blocks of HTML anyway (though I am working on encapsulating re-useable chunks of that into separate functions or classes). There is the question of which way is the best way to mix code (assuming you can be convinced that mixing is allowed). Should I just have HTML in output statements, or should I integrate the syntax as ASP and PHP do? I am currently planning to explore the latter with C/C++ as the basis language.
Using C++, but open to (constructive) suggestions (Score:2)
I'd like to use a scripting language to do this, but couldn't find something with ODBC, CORBA and the other pieces I need. For example, a particular CORBA interface may not have been tested with Visibroker, which is what I have, and I didn't want to spend a week figuring out how to compile/link all the add-ins I'll need.
Invitation - if somebody has a better way to integrate all this stuff, please let me know.
/bin/sh is it (Score:2)
Easy, portable, small interpreter, decent facilities.
CGI is the most improperly-used term on earth. (Score:3)
CGI stands for 'Common Gateway Interface'.
It defines the INTERFACE between the web server and the 'CGI application' (meaning, an application using the CGI interface).
I'm SOOOOO tired of hearing about 'cgi languages' and 'cgi this' or 'can you write cgi scripts?'
Hey. I bet a lot of people who write 'cgi scripts' use a pre-built library to actually implement CGI, and couldn't actually write the CGI parser if they had to. (okay, I'm exaggerating a bit.. but hey...)
In other words.. there is no such thing as a 'cgi language', only software that implements the CGI interface spec.
The ongoing code vs. presentation argument (Score:2)
Man, people get DAMN religious about this one. I totally support back-end components, because they increase the readability/maintainability of code and enable code re-use. However, I CONSTANTLY hear about people taking this to unnecessary extremes.
For instance, I really enjoy working with JSPs. The "purists" complain that they encourage you to put code in HTML, but, damn it, there are times when you need code in HTML, such as loops, if/else logic, and tiny utility functions. Forcing all of these into the back-end components ends up putting too much presentation into the logic, so the components lose their generality.
If you constrain your Java-writing to the syntax you learned in the first week of "Teach Yourself Java in 21 Days" (i.e., don't do any serious coding, and don't import packages other than your custom components and java.util in most cases), you'll be in good shape. Why use a separate macro system (as I used to do before I switched to JSPs), which will simply force you to learn another syntax? Just don't go making frickin' SQL queries from your JSPs, either!
By the way, I do recommend Resin from caucho.com [caucho.com] if you're interested in JSPs. It handles some cool things, like database connection pooling (very important!) for you and, coolest of all, it supports JavaScript as a for JSP development. Just as serious Java coders shouldn't have to go learn some other macro syntax to code pages, web designers should be able to use a language familiar to them, which, in almost all cases, is JavaScript.
--JRZ
arghhhh (Score:2)
Every time, every single time this comes up at least 20 people ALWAYS ALWAYs ALWAYS say PHP is bad because you embed the code in the html. Let me clue you in since you apparently don't bother to research this stuff. When it comes to outputting html from php, IT IS ABSOLUTELY NO DIFFERENT THAN PERL. Read it again for the first time. Perl offers you what? Templates, print, requires, and functions to seperate content from layout. What about php? Templates, print, requires, and functions. Woah, perl is so much better! Oh, don't foget that php can actually be used from Java Server Pages to seperate content and layout...
Hmmm... (Score:2)
Perl is fast enough, but not for Slashdot (Score:3)
I do love Perl though, and use it a lot on my own websites. But when the websites get too many hits, Perl can't scale the traffic.
The list (Score:5)
If you are looking for something easy: Python or PHP
If you are looking for speed: PHP4/Zend Optimizer
If you are looking for flexible: Perl
If you are looking for good XML compatibility: Perl/Java applets/PHP+expat
If you just want to make headers/footers for a common theme: SSI/XSSI
Now, I don't know about most webmasters, but the three I see most often are Perl, PHP, and ASP. I have to admit, ASP is great for connecting to databases, as long as you grab someone else's code. PHP has built-in ODBC connections, and Perl has modules for it.
Perl seems to have the most free scripts written for it, followed by PHP. ASP seems to show a strong commercial following, which is not a surprise.
If you know C, PHP is easy, and Perl is as well. PHP is a bit more strict than Perl. Perl has more than one way to do things down to an art.
ASP is OK, but if you have a choice, stick to plain HTML. We have a phrase when it comes to ASP in our office. The phrase is "what were they thinking?" and it applies to anything from the choice of VBasic, to Management's deciscion to implement it in the first place.
I prefer PHP, for its flexibility, it's portability (moreso under version 4) and its ease of use.
Re:Like Perl and Java Servlets--Love PHP (Score:2)
The real problem is memory overhead. Our mod_perl processes can reach 20-30MB each. But then again we have 70,000 lines of Perl code...
-JF
Re:Like Perl and Java Servlets--Love PHP (Score:2)
In web applications, such complex calculations tend to be the abnormal case.
All Apache-mod_perl does is remove the over-head. Well, there is very little overhead to perl to begin with.
Absolutely false. There is a great deal of overhead to forking and execing Perl. And mod_perl does MUCH more than merely eliminate that overhead. mod_perl gives you the ability to do things like database connection caching and provides access to Apache internals giving your script more information and more control.
I've run all sorts of comparisons between java and perl, and for small - medium sized scripts, compilation is barely noticable.
My company has 70,000 lines of Perl code. Compilation time is significant.
The slowest parts tend to be in database reconnections, forking off seperate processes to do simple operations like file grepping, finding, etc.
First off, nothing will compensate for poor code. If you are using mod_perl, you can cache database connections. Forking a process to grep a file, or find a file -- that's ludicrous! It can be done trivially in Perl.
but I found that the same algorithm would run incredibly slowly in a java-servlet world because of the un-optimized string parsing in Java.
There are regex engines for Java that provide much of the performance and flexibility of Perl.
But if I redesign the java-system so that it uses a truely optimized 'parser' then I can get better performance than even in perl.
Of course. And there's probably a better way to do the Perl version too. There's *always* a more efficient way of doing something. And there's always a less efficient way.
The only problem is that you have heavy context switching, as opposed to the light-weight context switching of a threaded model ( such as java-servlets).
Apache 2.0 addresses this issue allowing a hybrid solution. (Multiple processes with multiple threads)
Another issue with process segmented workers is the redundant usage of memory and thus the propensity to Virtual memory thrashing. You, of course, always want to put more than enough memory in a server, but you also would like to cache as much of the web site as possible. If you were to scale to 50 workers, your memory contension would be well beyond that of a CPU-cachable range.
Much Perl code can be pre-loaded into the parent Apache process allowing it to be shared among processes. Thanks to the joys (grr) of copy-on-write, it gradually gets unshared -- a fault of Perl intermingling code and data -- but tuning process lifetime can alleviate this.
For small-scale operations ( Apache-Front-end, HTML-rendering, Business-logic, database-back-end ), where the business-logic is minimal, you can use mod_perl with apache and have the DB on another computer and you have plenty of scalability. To my understanding this is exactly slashdot. It is when business-logic becomes comparible in resource requirements to the other elements that perl really falls short.
My company handles 2,000,000 page views per day. Most of that is our web-based e-mail client. (heavily customizable/cobrandable!) We're growing at as much as 40% per month. We handle 1,500,000 mailboxes. We use Apache, mod_perl, and MySQL. With careful design our system ust keeps getting faster and faster.
It's hard to farm out CPU cycles to other machines or CPU's.
That depends on how well you designed your code. We have no such difficulties. I believe we have 11 web servers handling our e-mail client, 6 or so handling our message boards product, and a handful serving our search and chat products. (Both of those are in Java -- but receive trivial usage thus far...)
And if your logic serializes access to data ( via DB row/table locks ) then the ability to finish business logic computation really starts to stand out like a soar thumb.
That problem really depends on your RDBMS. MySQL is not well suited to such situations, but Oracle and DB2 handle them fairly gracefully.
Perl just doesnt show up in the enterprise model, or even the real service model beyond the simple form entry services like slashdot.
I must take exception to that statement. My personal site, my previous employer (BrainPower -- now out of business unfortunately), my present employer (Everyone.net) all use(d) complex business logic rules and all have found Perl to perform quite well when properly managed.
A web based e-mail client does not classify as a "form entry service." Our inter-company communication/integration protocols are also Perl based with great success.
Java was designed with all of this in mind, they just don't always achieve their goals completely.
If you can get over Java's screwy I/O model. No asynchronous I/O? Come on! One should not be forced to take on the overhead of threads for synchronous or multiplexed I/O. It's become a pain in the neck for our search product. We have to spawn 20 or more threads to do a meta-search. That's all well and good until you have a thousand people doing it at the same time!
I'm really tired of hearing the "Well [x] is a great toy for small companies/sites/whatever but when you want real power and performance use [y]." That argument has been used by Sun and Sco to describe Linux, by Python, Java, and other language advocates to describe Perl, and in many many more cases...
I stand by my experiences. BrainPower: data mining application. MrJoy.com: Customizable news and community site. Everyone.net: Cobranded, web based e-mail, community (message boards), search, and chat. With much more on the way.
2,000,000 page views per day and growing rapidly.
-JF
How can you blame perl for slashdot's sluggishness (Score:3)
Perl Isn't always the answer (Score:2)
Perl and Java are good for things that use databases. Maybe python too. Lisp is good for algorithms. C is good for speed. VBASIC is useful for windows dependant stuff.
Avoid shell scripts. Use safe_perl, safe_python or the equiv. Use lots of ASSERTS in you C if you do that. Watch for NULL obects in Java. Let someone else warn you about BASIC-like languages. Then use the language you are most comfortable with.
Re:Like Perl and Java Servlets--Love PHP (Score:2)
I think others have covered the mod_perl debate reasonably well already, so I'll cover the object model issue.
Many people seem to confuse the minimal number of additional keywords for OO in Perl 5 (mainly the bless keyword, plus a few magic variable names), as being an indication of patchy support for OO.
I strongly suggest reading Damien Conway's Object Oriented Perl; I bet you wouldn't keep these beliefs about Perl after reading it. Conway is a computer science professor who has spent a lot of time with C++, Java, Smalltalk, etc, and he shows how Perl allows a marvellous OO design without the inflexibility and complexity that these other languages display.
Perl provides encapsulation, (multiple) inheritance, polymorphism (both interface and inheritance), and persistance. It also allows operator overloading, and reimplementation of basic types (using 'tie'). Many CPAN packages are available to simplify creating common object types (e.g. Class::MethodMaker).
Personally, I've used mod_perl to create a large, complex, fully OO web application, and I loved every minute of it. Because it's a "Swiss Army Chainsaw", you can quickly prototype functionality as basic CGI scripts, and it's then a piece of cake to incorporate them into the mod_perl app when you're ready.
JavaServer Pages, or Java-based Web applications (Score:2)
Why?
* Java is fast (and please, don't start dissing Java because it's not natively compiled). Java executes much faster than, say, perl, ASP or PHP. The inital overhead in displaying a JSP is larger than invoking a perl script (assuming you're using mod_perl), but that's not because Java is slow, it's because of all the features the servlet/JSP runner implements.
* Java is OO. IMO, this is a great advantage, although I guess many will disagree (especially here on
* Java is very much suitable for writing anything from small hit counters to large-scale web applications. The reason for this would be obvious to anyone who has programmed Java for a while. I personally can't imagine writing anything large in perl.
* Java is cross-platform.
* Java is a GC:d language (this argument doesn't apply "against" perl of course).
Q1: What problem are you trying to solve? (Score:3)
If you are doing classing CGI, you first task with every request serviced will be to get the query params and the host environment. Look for a language that provides good facilities for that. Perl's CGI.pm is a good example, Here's how simple it is:
use CGI.pm
$q = new CGI;
@querykeys = $q->param();
foreach $key (@querykeys) {
print $q->param($key);
}
I'm sure fans of other languages can come up with similar languages.
Most, if not all, CGI handling will involve some text manipulation. There are few arguments that Perl is king of that domain.
Will you be doing any database accesses or otherwise responding to the request with persistent data? Look for a language that supports some kind of useful DB interface.
Do you need to maintain session state? You'll need a language that provides facilities for easy cookie handling or URL mangling.
The only language I know that meets all these criteria for straight CGI is Perl. If you are willing and able to go to the next step beyond CGI, look at Java servlets and JSP.
Re:Don't use Java (Score:2)
There are regexp packages for Java, and it's true they are more cumbersome to use than the ones in Perl, but I think that because of general support in many areas regexps are normally used you really don't need to use them as often even to support a very generic system.
Re:Some language, any language (Score:2)
Re:I disagree (Score:2)
Re:What I believe (Score:2)
Re:Incorrect! (Score:2)
Re:CGI is the most improperly-used term on earth. (Score:2)
however, i'd like to add, that the cgi interface is outdated imho, it requires that a new process is started for every call to a 'cgi app' which is very expensive. ... or other servers that are easely extendable, like roxen [roxen.com], which allows for easy integration of your code with modules that others have written...
today there are much better things like mod_perl, mod_php
greetings, eMBee.
--
REXX (Score:2)
Want a short tutorial?
http://www.slac.stanford.edu/~bebo/rexx/title.h
http://www.networking.ibm.com/icserver/pub/icsw
Re:CGI is the most improperly-used term on earth. (Score:2)
wow, a Common Gateway Interface interface?
That's almost as bad as the W2K boxes that proudly proclaim it is "Built on NT technology." NT, IIRC, stood for "New Technology."
--
Ask Slashdot (Score:5)
1. What editor should I use?
2. Which window manager should I use?
3. What license should I release my code under?
4. Which programming language should I use for _____?
5. Which Linux distro should I use?
6. Linux or GNU/Linux?
7. Big-endian or little-endian?
8. Buy or lease?
9. Boxers or briefs?
10. Blonde, brunette, or redhead?
11. Paper or plastic?
12. Ginger or Mary Ann? (Ladies: Professor or Gilligan?)
13. Tastes great or less filling?
14. How many licks does it take to get to the Tootsie Roll center of a Tootsie Pop?
15. Star Trek, ST:TNG, Deep Space Nine, Babylon 5, or...?
16. Shaken or stirred?
17. Color or monochrome?
18. Frames or no frames?
19. Country or western?
20. Walk or Don't Walk?
21. Dr. Drew, Dr. Ruth, Dr. Laura, or Dr. Suess?
22. Joystick, mouse, or keyboard?
23. Cooperative mode or Deathmatch?
24. POP3 or IMAP?
25. Hex, Octal, or binary?
26. WHAAZZZzzzzzUUUUUUuuuuP?
27. Troll or Flamebait?
(Sorry, I got a little carried away.)
PHP - how to avoid mixing code and HTML. (Score:4)
Why, oh why?
For some bizarre reason, people in this thread keep insisting that the best choices for web scripting languages are those that don't mix the actual code (aka the 'logic') and HTML code.
And of course, they have a point. Unfortunately, they then argue that PHP is a poor choice because you have to mix PHP logic and HTML code in pages, (usually ending in
So, PHP is a bad choice, right? Wrong.
Most people here seem to be completely oblivious to the fact that PHP3/4 can use the FastTemplate.class, which is (for Perl people out there, just another module) used for just that purposes - creating templates that don't have any PHP code in them. Instead, they have XML-like PHP calls in all the right places, and nothing else.
Example: Let's say Slashdot was coded in PHP, using Fast Templates. I haven't looked at the Slashcode lately, but I'm guessing that at the top of the page, it references your currently-used login name, and displays it. If Slashdot were coded in PHP, it could either have
get_current_loginname() ?>
or whatever. PHP code, right? Ugly. Don't want to mix code and HTML. So instead, we're using Fast Templates.
{DisplayCurrentUsername}
And that's pretty much it. You can predefine dynamic rows, blocks, whatever, and play around with variables inside them, but you simply use { } to denote a dynamic Fast Template call, and that's it. The entire code side is then handled by another fast template code file, call it index.php or whatever you want, where the defined { } variables are defined and coded in PHP. Which means full separation of code and HTML. When your designers start messing with the page, all they have to do is to remember to insert very short, simple calls like the ones above wherever they want to have them. They can even use font tags or any other mean of design to change the { } output in any way they wish, so the entire design part is up to them, and the coders don't have to worry about Netscape4x backwardscompatibility, etc.
And btw - Fast Templates really are fast. With the upcoming PHP4 Zend optimizer, tests have shown 100%+ speed increases over ASP, and it's all free, and well-documented. PHP has great database interaction modules, and for a site like Slashdot (or, to use an example that actually uses PHP, Freshmeat) there is no faster solution that PHP+mySQL. Many of the sites out there that have filenames ending in
But of course, if you do choose that path, you will have to explain to your boss why that critical project came in way under budget, and much faster than expected. Won't that be just horrible?
Alex T-B
Some language, any language (Score:2)
-russ
Only dynamic content, BTW (Score:2)
It depends on what you want to do. (Score:2)
Re:Like Perl and Java Servlets--Love PHP (Score:5)
This is false. Apache with mod_perl runs at the same speed as Apache -- the combined speed of your computer, network connection, disk, etc. Yes, you can write slow mod_perl stuff (if you use it as glorified CGI), but mod_perl itself has no such limitations.
mod_perl scales very well -- Boston.com serves a few million pages a day using Apache/mod_perl. It's all about how you write your Perl.
But, I will give you this much -- if you run CGI scripts under mod_perl, they do not run nearly as fast as they would if you wrote mod_perl handlers, though they still run much faster than CGI.
How can you dislike the JSP way of doing things, but like PHP? They use an identical model. PHP suffers from many of the same problems as CGI (logic and HTML combined in the same place, etc), but the speed issue is definitely not one of them. However, PHP, even well-written PHP. will never be as fast as a well-written mod_perl handler, for the simple reason that mod_perl handlers are compiled once and live in memory for the life of the Apache server (parent) process. There is no file to read every time it gets called. Plus, PHP (and CGI, and JSP, and servlets) have the limitation that they can only produce output. You want to modify how the URI gets translated into a filename? You can't do that in PHP. You want to customize the authentication process? Nope, you can't do that in JSP. You want to modify the environment for all the other handlers? Not is ASP, you can't. For anything other that generating output, you have to use either C or mod_perl. And the beauty of the whole thing is -- yup, you guessed it, it runs at memory speeds -- no filesystem accesses (unless you write them in specifically), no scripts to stat, no logic/HTML combination to parse.
You are right about Perl's object model, though.
darren
Cthulhu for President! [cthulhu.org]
Re:Like Perl and Java Servlets--Love PHP (Score:2)
Perhaps the Gnu Regular Expression Library for Java [cacas.org] would be of some use.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Learnin' from each other's knowin,
THE CGI Language (Score:2)
MS-DOS Batch Files!!! Yah, baby!
Also, look into writing your CGI in COBOL.
Re:CGI and ASP (Score:2)
Yup, whoever told you that was kidding. Just use two quotes in a row. The string > becomes:
"He said, ""Why me?"""
I'm not going to argue with this, but I will say that it definitely can be done. So far, the worst thing I've done with it was Tic-Tac-Toe [silverlight.org]. Or here [silverlight.org] if you want to see the source.
Correction to parent (Score:2)
Whoops, somehow forgot I can't use angle brackets... that should read:
The string <<He said, "Why me?">>
Lesser known CGI Language? How about Ada? (Score:2)
Ada is the highest level language there is, even above Java. The military uses it the most.
If you need strong data-typing and easy code management, Ada is a good route to go. There are compilers for many platforms.
"...we are moving toward a Web-centric stage and our dear PC will be one of
Re:CGI is the most improperly-used term on earth. (Score:4)
I don't mean to sound sarcastic, but the 'CGI Application' is a script, therefor it's a 'CGI Script'
It's kinda like 'Coffee cup'
Re:Like Perl and Java Servlets--Love PHP (Score:4)
All Apache-mod_perl does is remove the over-head. Well, there is very little overhead to perl to begin with. I've run all sorts of comparisons between java and perl, and for small - medium sized scripts, compilation is barely noticable. The slowest parts tend to be in database reconnections, forking off seperate processes to do simple operations like file grepping, finding, etc.
You get past all of that with PHP and java-servlets though, so everyone is really on a level playing field. PHP even makes use of perl reg-exs ( though I'm not sure if they use the same optimized engine, even though they have compatible syntax ). It really comes down to the advantage your language has to your type of solution. For example, I have created a very powerful web templating system in perl which takes HTML and imbeds them into other HTML files all the while emulating both static-HTML and perl-CGI ( really just a glorified extension to Apache::Registry and Fast::CGI ), but I found that the same algorithm would run incredibly slowly in a java-servlet world because of the un-optimized string parsing in Java. But if I redesign the java-system so that it uses a truely optimized 'parser' then I can get better performance than even in perl.
I don't have numbers to back me up. But assuming a multi-CPU configuration, ( perl-threads still being considered beta ) a well designed java-solution will outperform a mod_perl solution ( especially since java-servlets can transparently span multiple computers, either by resource pooling, or through RMI segmentation / pipelining of the logic ). You can achieve this sort of distribution in perl ( I've successfully tried ), but it is non-trivial and not a logical attribute of the language.
Thankfully though, mod_perl gives you the advantage of running multiple independant, concurrent perl-proceses in each Apache-worker. Thus you can make use of multiple CPUs at the process level. The only problem is that you have heavy context switching, as opposed to the light-weight context switching of a threaded model ( such as java-servlets ). You really notice the difference in a thread-optimized OS such as Solaris and associated [uSPARC] hardware ( where the CPU can thread-swap between instructions ). At this point, one file goes out to the DB while one reads from CGI parameters while two or three fight for raw computing horsepower.
Another issue with process segmented workers is the redundant usage of memory and thus the propensity to Virtual memory thrashing. You, of course, always want to put more than enough memory in a server, but you also would like to cache as much of the web site as possible. If you were to scale to 50 workers, your memory contension would be well beyond that of a CPU-cachable range.
Apache will soon be multi-threaded, and perl is making serious strides to make it's threading both safe and portable. 5.6 has a nice multiple interpreter model which works nicely for global variable consistency ( it's main purpose is to emulate forks on win32 machines ). This combination could bring perl almost back up to par, in terms of scalability, as java-servlets. But it is yet to be seen.
For small-scale operations ( Apache-Front-end, HTML-rendering, Business-logic, database-back-end ), where the business-logic is minimal, you can use mod_perl with apache and have the DB on another computer and you have plenty of scalability. To my understanding this is exactly slashdot. It is when business-logic becomes comparible in resource requirements to the other elements that perl really falls short. It's hard to farm out CPU cycles to other machines or CPU's. And if your logic serializes access to data ( via DB row/table locks ) then the ability to finish business logic computation really starts to stand out like a soar thumb.
As we move back into the world of server-based computation ( java-applets and client side web-apps never really took off ), this sort of massive business-logic will become increasingly important. Serious apps are still done in C ( or C++ if you're into extending your code ), but more and more are done in java in order to give you platform flexibility. Perl just doesnt show up in the enterprise model, or even the real service model beyond the simple form entry services like slashdot.
I'm not saying you can't do magical things with perl ( I've already proven to my company that you can. TCP, forks, and threads are your friends ), but the technology does not easily afford you to do this. Java was designed with all of this in mind, they just don't always achieve their goals completely.
I hope enough of you read this and find value in my experiences. I am not an authority, just a power user.
-Michael
Lisp (Score:3)
Check out any of the following:
SIOD [delphi.com] - A small, easy-to-extend Scheme interpreter that can be used to do CGI.
AllegroServe [sourceforge.net] - This is a small Common Lisp based web server which can sit behind Apache or do it all itself. They have a very nice mapping between Lisp lists and HTML that makes dynamic content generation a breeze. The source is currently implementation-specific, but it's LGPLed and available at Sourceforge.
CL-HTTP [mit.edu] - If you want to do dynamic content and don't want to learn HTML, this is what you want. Query processing and page generation are buried behind deep and powerful abstractions. Long learning curve, but worth it for really complex stuff.
There are others, but I don't have the links handy right now.
Re:With all due respects... (Score:2)
There is nothing which prevents you from reading in template files when designing using PHP3, in fact its a piece of cake to do, and I am using it in at least one area of my current project. You can do anything you want to do in PHP that you can do in Perl with regards to includes, functions, templates etc.
There is even a group currently producing some sort of meta-scripting language for templates that is used with PHP - although I know nothing more than that about this project (Personally I think it is unnecessary because PHP is already so easy to use that it hardly needs an even simpler scripting language dropped on top of it).
Perls advantage is that it offers greater flexibility in the methods you can use to construct your script than PHP does. PHP's advantage is that someone else coming along after you can very easily determine what your script is doing - which is a different matter with Perl.
Its probably comes down to a matter of personal preference. Both are excellent scripting languages, both have strengths and weaknesses, both have their advantages in specific situations. I personally prefer PHP because I find it easier to understand, suited to my needs, and capable of rapid development.
PHP (Score:4)
If you are building webpages I think the best tool is undoubtedly PHP [php.net]. It has all the power of perl (with the exception of regexes which are not as evolved) and it is far faster to develop in, and probably to learn as well.
It supports multiple different databases, including mysql, postgresql, as well as any ODBC compliant db.
Version 4, due to be released this month I believe (its currently available as RC1) offers an optimizer (available at Zend.com [zend.com]), and will come with a compiler as well.
It easily integrates directly into your HTML code. It is multiplatform, and its free.
Its main advantage is the ease with which web applications or websites can be developed. I am currently working on the software for the backend support of several websites, and using PHP I am able to develop this application very rapidly. Far faster than I might be able to do with Perl.
Obviously for those who already know Perl, they will be able to develop just as effectively in that scripting language anything that can be done in PHP. But for the new user seeking to learn a scripting language, PHP cannot be beat.
Heh (Score:2)
Java Servlets (Score:2)
Re:Using C++, but open to (constructive) suggestio (Score:2)
On NT, Python can access any COM object that you can script with, say, Visual Basic. Since nearly every application on NT is also accessible via COM, this opens many possibilities.
On NT, Python also includes the ability to talk to ODBC data sources. I believe there is direct access via ODBC class libraries. If not, you can definitely use the ADO COM objects (I have done this to access SQLServer).
Python has good access to system calls on whatever platform it is running on via its rich class libraries. This is also the case with NT.
Python has a CORBA ORB, called FNORB, available that should be able to interoperate with Visibroker.
Check out www.python.org [python.org] for more information about Python. There is a link from the main page to Mark Hammond's extensions to allow Python to run on Win32. You need to get two things for this: the base Python package for Windows, plus a package of extensions.
Finally, Python is undergoing a transition from the current version (1.5.2) to the new version (1.6) due out by the beginning of June. Any 1.6 stuff you see will be alpha/beta quality code.
Best of luck to you. I hope you find Python as enjoyable to work with as I have!
Re:CGI and ASP (Score:3)
If the script itself can't do something I can create a component and call it through ASP. I can also separate my display/data/logic layers that way.
One of the beauties of ASP is you can use vbScript, JavaScript, PerScript [slashdot.org] (more perlscript) [slashdot.org], etc...to develop with as well as COM object built in vb, C/C++, etc... There are also MANY good code snippets and help available without having to look hard.
Some good URL's:
ActiveServer pages.COM [activeserverpages.com]
4guys from Rolla [4guysfromrolla.com]
Abundance of helpful mailing lists & FAQ's [asplists.com]
ASPToday [asptoday.com]
ASPHole [asphole.com](Under construction right now)
15 Seconds [15seconds.com]
and a whole slew of other good sites (they usually link back & forth to articles.
If you want a " in your string with vbscript you can stick in two " and it'll be escaped OR you can append the Chr() of it to the string.
So far the only limitation I have come across has nothing to do with ASP: HTML sucks for complex forms. Client side Javascript can do a lot but often you still need to split your forms up if you can't use ActiveX or Java.
Any other Q's?
--Clay
Re:Some language, any language (Score:3)
set handle [ns_db gethandle]
Using ns_db with other arguments you then get to do your queries/inserts/etc (simplifying just a little):
ns_db $handle "select * from table"
ns_db dml $handle "insert into table (field1, field2) values ($value1, $value2)"
Then, when you are done, you just release the handle:
ns_db releasehandle $handle
Each AOLServer process can hold 8 database connections open.
AOLServer 2.3.3 is free, non-open source. AOLSerer 3.0 is free and open source, thanks to the efforts of Philip Greenspun and company.
Philip has written an intro to AOLServer that was published in Linux Today, it is now available in two parts here:
Part 1 [photo.net]
Part 2 [photo.net]
A quick quote from part 1: "AOLserver runs as a single Unix process. You can deliver the 20 dynamic pages per second of our example without your server having to start any new programs. If those pages need to connect to Oracle, they simply ask AOLserver to let them use an already-open connection from a configurable pool. Note that this ability to pool database connections is a consequence of AOLserver's one-process-with-threads architecture. With a process-pool Web server such as Apache, nothing stops you from linking in the Oracle C libraries. Your Apache server can then function as an Oracle client. However, there would be no way to share a database connection among Apache server processes. What's the bottom line difference? A site like http://photo.net can serve 700,000 hits per day, to about 120 simultaneous users at once, with one AOLserver process holding open eight connections to Oracle. That's a total of nine Unix processes (one AOLserver, eight Oracle). With Apache, providing the same level of service from photo.net would require 120 Apache server process, each of which held open two connections to Oracle: 360 processes total.
Another dividend from the single-process architecture of AOLserver is that you can cache stuff in AOLserver's virtual memory. For example, consider the Bill Gates Personal Wealth Clock (http://www.webho.com/WealthClock). It gets as many as two hits per second at peaks. Yet it relies on invoking CGI scripts running at foreign Web sites where they probably wouldn't appreciate getting hammered by my server. The solution is to cache the page in AOLserver's virtual memory. Again, this is something you could do with a process-pool server such as Apache but you'd be gradually building up 120 separate copies of the same data. "
Part 2 shows how to use the "ns_db" command that I mentioned above in some detail.
P.S. Philip Greenspun developed a great open source toolkit that sits on top of AOLServer called the Ars Digita Community System (aka the ACS) and wrote a book about it that is well known as a must-read for web-heads. It is on line for free, complete with all the photos:
Philip and Alex's Guide to Web Publishing [photo.net]
P.P.S. There's a version of the ACS available that uses the open-source Postgresql database, if you don't want to pay for Oracle: Open ACS [openacs.org] (they have a working beta but are waiting for Postgresql 7 to come out before making an official release).
My Experiences With Java Servlets and C CGI (Score:3)
1.) CGI and C: Even though I am comfortable with C, I felt very uncomfortable using C to handle server side processing. C's little idiosyncracies (no array bounds checking, poor text processing, almost non-existent exception handling capabilities, etc) made it a poor language (in my opinion) for creating a large, maintainable, complex user-driven web experience. Also the fact that an SQL pre-processor is needed to deal with handling database interaction is also rather annoying.
2.) Java Servlets: Java's extensive libraries make it possible to develop the entire web experience with Java. This allows one to design the entire site from the ground up in a proper fashion (Yes, design with UML diagrams even). Servlets are rather slow the first time they are used because they have to be loaded into memory but after the first user hit, they execute very quickly (as fast as or faster than most CGI by certain benchmarks). Exception handling is another boon that allows even the most unexpected problems to be handled properly. For example, when developing a recent project I wrapped the entire program in a try...catch block which sent me an email with a stack trace whenever a run-time exception was caught, I also printed a message to the webpage with the a hyperlink informing the user to mail the error message to me just in case my mailer failed. This proved to be a whole lot more useful than the default message screen Apache provides on script errors and would have been impossible in C. The database interaction via JDBC was rather smooth and could be modularized into special DB accessor classes and servlets objects could be modularized for later reuse. The ability to use other aspects of Java easily (e.g. the XML parsing API) is also a big bonus. In fact mail.com now uses Java extensively on it's site.
Which CGI language to use? (Score:2)
I've been writting CGI scripts from about the time HTML 1.0 was first introduced. I've written in C, C++, Perl, PHP3, sh, and in apache's SHTML languages. Each has it's good points and each has its bad points.
Downside is that the development time for the infrastructure is huge. C isn't designed for string processing. Even REs are harder to do in C. My 2nd to last choice in CGI programming.
On the downside it is a programming language first and a web design langauge 2nd. It also has a serious limit in that it often takes longer to compile to byte code for the run time engine than it takes to run the script. Startup times on largish scripts can be huge. Somewhat solved by embedding Perl into your web server. All in all, my 2nd choice for a CGI Language.
On the downside? It is another langage, sometimes I don't have a standalone PHP interpreter to do testing with. My favorite CGI lanague.
Summary: PHP for almost everything, Perl for the rest, C/C++ if you must, stay away from shells.
Chris
On the downside? It is another langage, sometimes I don't have a standalone PHP interpreter to do testing with. My favorite CGI lanague.
My experience (Score:2)
I tend to shy away from the ASP/JSP/PHP3 paradigms just because they integrate presentation with the code. It means designers and coders will be working in the same domain. Jason Hunter has an article [servlets.com] contrasting JSP (and the models like it) to what he favors, a template system.
We're presently using Java Servlets with our own home-grown template system. Java is a pretty darn good language, in my opinion. It has nice, consistent syntax, good OO design, and a wonderful set of libraries for just about anything (particulary, threading, RMI and JDBC come in very handy).
It is a valid point that much web work is text processing, simply because HTTP is text-based (and all parameters/info passed back and forth is text based for the most part, too). Thus, regular expressions, and Perl because of its RE support, lend themselves well to web work. However, I know of to regular expression packages for Java, one of which we use. We still hand-code some text processing in inner loops for the best possible speed, but RE's are a tremendous development-time saver.
All of that said, my preference considering the high-level models models I've used would be: Servlets, JSP(/ASP/PHP3), plain out-of-process CGI.
Please forgive me if I have incorrectly lumped ASP, JSP and PHP3 together incorrectly, but I believe, at least from the high-level, they are similar.
CGI and ASP (Score:2)
Re:ASP is not a language (Score:2)
Uh, when most people refer to ASP, they mean VBScript running under IIS.
Jeff
Sort of (Score:4)
I hope you're not saying that CGI script is an invalid term. It is a script that conforms to the CGI protocol, not a script that implements the CGI protocol.
However, you're right; this question is clearly misstated. There is one clear favorite language for developing CGI scripts: Perl. You can write CGI scripts in virtually any language (that was the goal when defining the interface), but few people do. Not with CGI.
However, there are a wide variety of languages for web development, including Java (servlets and JSP), VisualBasic (ASP), PHP, ColdFusion's CFML, C/C++ (via NSAPI, Apache module), etc. Few people use these languages for CGI; each of these languages has its own respective interfaces for communicating with the server instead. (Incidentally, so does Perl: mod_perl or PerlEx.)
For more info:
- Original CGI spec [uiuc.edu]
- CGI RFC Project [golux.com]
- O'Reilly's new Programming CGI (2nd Edition) [oreilly.com] to be published this summer (*cough*
;-)
- Scott GuelichFrom primitive CGI scripts to Enterprise solutions (Score:2)
If all you need is a simple to use program that communicates with database and formats output - use CGI (whatever language)
Internet is about mass use, it is about global access to the information and it is about services that can be provided over its networks.
What do you do when you need an Enterprise solution for your website to handle increasing numbers of users, how do you scale well into millions (and hopefully billions) of users? You need smart systems and plain CGI is just not enough.
For an Enterprise solution to work you need n-tier applications that utilize processes spaned faster than CGI (think servlets or DLL components,) you need fast data access, you can not afford forcing your user to wait, you need smart cache to store data locally without relying on your primary data sources and legacy systems. You need load balancing to take care of your increasing user base. You need easy to maintain and manage architectural view of your entire site and developer view of the site's components. You need to have reporting and maybe billing tools (what good is your site if you don't know who accesses it and who and how to bill) You need support for various language bases since you want to go global (however maybe you don't care to do that) and PHP sounds good for this, but it is only a small business requirement. You need batch processes to run when they must (not all data must be accessed during user request, some can and must be brought to your cache beforehand to optimize performance.) You need multiple device support (browsers on PC, on your cell phone etc.)
Basically the languages you are going to use are not as important as correct architecture for your entire business.
perl (Score:2)
I know a lot of people already posted this (or are going to), but you will see a lot of perl around in the CGI camp. It does have some good qualities (not saying you can't find these in other launages, but...)
It can process text really well and quickly, this is very usefully in CGI program.
It is portable, quick change it from one platform to another without a lot of modifaction
A glue launage, glue an html front end to a DB back end, glue a mail server with an html form, etc...
Supported, the perl community is activlly supporting and developing new feartures into this
Some disadvantages though, is that the launage isn't to clean, some times it is very hard to maintain code, even 15 minutes after you wrote it! You can maintain the code, but you have to activelly think about this BEFORE you even start chuncking out code.
CGI programing is more or less like any other programming, you just need more in the way of
text processing
portable
interact easliy with other things (databases, sockets, etc)
IMHO perl does all these things really well. The only bad thing I have found using perl, is that a really big project can get really mess if you don't think ahead and make sure everything is written down on a white board first. If you are working on a large project using perl, please do your self a favor and sit down and write down the program "flow" before you start just randomly typing code, it will say you a lot of greif.
Use Templates!!! (Score:3)
It all depends on the task at hand... (Score:2)
Choosing a CGI-language is like any other software development process. You've got to choose the right tool for the job. That being said here are some of my lessons learned.
Perl - an excellent choice for simpler projects. It can be used in large systems, but suffers from too much flexibility. What I mean is that you can write a Perl program that looks similar to C or you can write real ugly, but compact and elegant code (not saying that C isn't elegant). Regular expressions are a real plus checking validity of arguments. The library's available for perl make it extremely powerful. Since the memory allocation, arrays and types are relaxed it makes it very flexible to do all sorts of data input from the web, etc. Output wise, its very easy to make a perl script read from a source file and substitute dynamic content into a page via regular expression substitution.
Other scripting languages - (sh, csh, ksh, bash, etc.) Pretty much as powerful as Perl. Problem is many times they can be difficult to program and understand for non-shell scripters. Also, chances are if you are on a UNIX box (or any other for that matter) you can use perl if you don't have it already. My opinon is take the time and invest in learning/installing/using perl.
C or C++- performance oriented, but one must weigh it because things like sh, ksh, bash, perl are very fast (csh is sluggish for those who don't know) I'm sure there are reg. exp. libraries for them so they can be decent in terms of value checking/substitution. Both are a bit more structured than the previous scripting languages so the code might not be as messy. I'm not sure, but I'd assume there are more C/C++ proficient programmers than perl, sh, ksh, etc. ones. If so, one could argue that the code might be more maintainable. Another problem is the code is non-interpreted so their might be compatibility issues and there is the ever famous memory leakage problems...
Servlets- One of my personal favorites. Java is a solid OO language so its a bit easier (I find) to do OO development in Java than in something like Perl and C++ (not saying C++ isn't solid but I don't feel it is as solid). The server offers a lot of features like session tracking, object persistance, threading across requests etc. making it much easier to make use of these features than in another language. Tack on the regex library and set it to perl and you have all the power of Perl regular expression listed above. (or sh, or ksh if thats what one's comfortable with). Java has a diverse set of support classes so its good for lots of different tasks. Problems are again its interpreted, but it seems to run fairly fast. Because of Write Once Run Nowhere, it can become a pain to do system specific things... (changing file permissions to something specific (at least in 1.1 of JDK))
Cold Fusion - I'm torn on this one. It's a relatively easy language to use, offers much of the power in servlets and is extendible by using custom CFM tags. My problem with it is that you end up coding with HTML-like tags (CFM tags actual); a somewhat bizzarre feat if you haven't tried it, but not impossible. Last time I checked it only ran on NT or Solaris (about a year ago) and custom tag development was limited to C++ only. Haven't used it much, but after starting with servlets I felt that I could get all the power I wanted out of the servlet and it was a much more natural language for a programmer/developer like myself. Maybe CF is better for non-IT types?
JSP- Another technology I have limited experience with, but have been impressed with it so far. Basically offers all the power of servlets and separates the business logic from the presentation layer. A little weird like Cold Fusion in that you are coding around an HTML page, but the code constructs are actual Java code at least rather than if, while, and sql tags. Another side benefit is that your business code typically resides in a Java Bean. As a result if you wanted to build other presentation layers on top of it you could fairly easy (command line, applet, VB/VC++ through CORBA?)
So in summary, in my opinion for what I've seen:
I like servlets and JSP best (haven't done a lot of JSP though yet so I may end up eating those words). They're powerful development architectures when hooked with the server. Performance wise they are decent. With the regex library they have a lot of the power of Perl (oh yeah and they're portable) Not to mention I feel they fair best in developing growing systems or very large systems. Perl is my number two choice. Extremely powerful but lacks some of the support that servlet servers have built into them (threading, sessions, etc.) which means extra work for the developer. Not to mention, although I am very good with Perl, I have seen some real ugly looking perl systems that would send many spinning. Finally all the rest. Cold Fusion is not right for me, but for somebody else it might be good. C/C++ you need to justify the perfomance requirement or other reason for using it. Other scripting languages, justify why not use perl.
What's the Deal? (Score:2)
I find it quite interesting that despite the article title "Which CGI Language For Which Purpose?", many of the comments I'm reading are all big arguments over which language is easier, which language has better OOP, which has better flexibility, etc.
I think they were looking for more along the lines of "Which language would best be for serving an auction site?" or "Which setup might best serve a bulletin board news system with more than 5k users and 10k hits?"
All I know is that I have been developing web sites for the last 4 years. Recently I got into Perl with the help of a few friends of mine.
The major project I assist now is on an OpenBSD box running Apache without mod_perl. Now, yes, I realize that without mod_perl I'm losing quite a bit of speed, but I have no choice as far as configuration. It's not my box.
Which is another point that I'd like to bring up. Many of the benefits of certain languages are completely dependent on the configuration of the server. A great deal of people have no choice of configuration because they are either too broke (me) or because their management is ignorant, etc.
To conclude, I'd just like to say that for what I use it for, Perl works rather well. It serves my pages reliably, tells me when I've screwed up, and lets me do a lot of things as far as functionality that I didn't think were possible until I tried. I can load pages dynamically using a main layout file, and track hits to each of the sites and track individual users to see what kind of people are viewing the site and where they're visiting from.
For that, the benefits outweigh any side issues that may arise from the flaws in Perl's design.
So before you start posting any highly biased this-language-is-better-than-that-one posts, consider what the point of this Ask Slashdot was and try to find a reasonable answer for the question.
Macintosh Servers and CGI (Score:3)
In the case of a Mac server, you have two rather esoteric options:
1. Applescript CGI. There's a good tutorial on this here [embl-heidelberg.de]. And I recommend Applescript for Dummies [amazon.com], which, despite its title, is a pretty good foundation in the language. (And about the only thing still in print on the subject, which is odd.)
2. RealBasic CGI. RealBasic [realbasic.com] is a version of VB for the Mac, produced by a company in Texas (IIRC). It's a solid little package, and someone out there has written module [sentman.com] for RB to allow CGI functions...
about Zope (Score:2)
Tcl/Expect CGI (Score:2)
Expect extensions to the Tcl language by Don
Libes.
For those of you who are unfamiliar with Expect,
it provides Tcl commands for scripting
interactive processes like telnet, ftp, or other
terminal driven apps. It's standard on most
UNIX installations(man expect).
Nice for webifiying those pecular terminal driven
tasks like telneting in to some machine and
pulling down info to be displayed in an actual
human readable format.
Check out the Expect Home Page [nist.gov]. I know there's
a CGI tutorial floating around somewhere but
if you know Tcl it should be pretty obvious
KidSock
I recommend VBScript! (Score:5)
Oh, where was I?--oh yeah, back to how powerful this scripting tool is. It's really powerful, and I seriously recommend it! (In fact, my boss said that when I come back to work after my 10 years in the "big house" it will be even more powerful than it is today.)
--
like choosing a language for any project (Score:2)
1. portability
2. experience of your developers with the language
3. language strengths/weaknesses for a particular task
I'm sure there's others...
I'm a big fan of perl, but I guess that is mostly because of #2...
Re:CGI and ASP (Score:2)
Re:CGI is the most improperly-used term on earth. (Score:2)
ASP is not a language (Score:2)
Even Microsoft recommends that you move as much code out of your asp pages as possible. Use compiled components. These too can be written in a variety of languages, C++, VB, and Java being the most common. The asp's themselves should be doing little more than reading form or querystring input and passing that along to the components. When the components are finished processing the input, they feed it back to the server and output can be written. In asp you have some choices whether to output everything all at once or just little chunks at a time, via buffering.
I agree with the poster who urged people to separate HTML from code as much as possible. ASP lets you do this. Proper asp coding can result in highly scalable sites that perform as well as anything out there. Its easy to use and its from Microsoft, so there are lots of crappy/slow asp pages as well.
Given that it is not a language in itself, I think its model is a good one for web development and I'd like to see more language independent methods like this in Apache. Has anyone tried Apache::ASP and seen how well it works?
Another LISP run site. (Score:2)
Another LISP site.
The http://Shop.Goto.Com/ [goto.com] Instant Search Categories runs using LISP. It's based on a theorem prover written in LISP:)
Check out how fast the InstantResults get updated as you narrow down your requirements. For an example try http://Shop.Goto.Com/ce/dcameras/ [goto.com]
LISP is sweet :) You know you can change a function definition in the middle of a running program, don't you :) ? Patch in a bugfix without taking down the site ?
Winton
Re:The list (Score:2)
It's a scripting implementation of a visual implementation of a language that Microsoft stole from someone else who should have had it terminated while it was still in the womb.
Let's look at the basics:
1) It's dot-syntax, in a way that it's far more like JavaScript than Java. dot-syntax languages make sense until you get about five levels down, then it's just confusing. (parent.frameA.location.form['a'].options.index.g
2) There's about five ways to do everything (like Perl) except none of them work (unlike Perl). I spent about three hours trying to figure out how to do a query back in Visual InterDev 1.0. I tried the online help example. I tried the other online help example. I tried the example out of the book. I tried the example online. I tried an example out of a newsgroup. None of them work! Finally I wrote my own using an average of one line from each example. That worked. But only for 'select' statements.
3) The tool (Visual InterDev) sucks. And it's expensive.
4) The operating system (Windows NT) sucks. And it's expensive.
5) The webserver (IIS) sucks. And calling for tech support is expensive.
But out of all of these, one reason stands out:
6) THERE ARE BETTER SOLUTIONS!!
</rant>
Alakaboo
Re:CGI and ASP (Score:2)
The ASP idea is the next logical step after CGI. Until I had to use it in a big project, I thought ASP on IIS was a good idea. Alas, like most M$ products, it turns flakey with continued use.
On the Linux side of things, I have experimented with PHP and JServ (JAVA) and find them to be welcome alternatives. They both follow the ASP philosophy. As far as server-side Perl is concerned, I haven't used it, but I'm sure a lot of Slashdotters have.
Re:PHP -- more versatile, but not as free as it wa (Score:2)
Re:Like Perl and Java Servlets--Love PHP (Score:2)
I run a site with 10 trillion requests per day with ncsa httpd and a 386 dx 40.