Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
IBM comparison of web development languages

By Dacta in MLP
Thu Sep 21, 2000 at 08:09:41 AM EST
Tags: Software (all tags)
Software

IBM has an article on their website comparing "five prominent scripting tools (Perl, PHP, Python, Tcl, and Java servlets)". One of the most popular web scripting languages (ASP/VBScript) is not included, however.


The article shows how each language performs each of several common website tasks:

  • Get and format the time/date
  • Put form field data into variables: receive 2 HTML form field variables
  • Search and replace
  • File writing: write the two values, along with the transaction date and time as a comma-separated string to a CSV text file (CSV = comma-separated values, such as: one, two, three)
  • File reading: read and present all the records of said CSV file
  • Split comma-delimited line into variables: split the last, just submitted, record back into individual fields for processing, in this case simply echoing back to the browser

I'd like to have seen comparisons of their database connectivity as well. I think the author could also have mentioned alternative ways of managing websites (n-tier architectures and XML/XSL). All the same, it is a worthwhile article to read if you don't already have a favourite language and need to choose what to learn.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
What's your favourite website scripting language
o Perl 31%
o PHP 30%
o Python 12%
o Tcl 2%
o Java 4%
o ASP 2%
o XML/XSL 2%
o A custom combination of Makefiles, Bash, Lisp and a language I made up. 12%

Votes: 141
Results | Other Polls

Related Links
o article
o Also by Dacta


Display: Sort:
IBM comparison of web development languages | 29 comments (28 topical, 1 editorial, 0 hidden)
(3.90 / 10) (#2)
by ramses0 on Thu Sep 21, 2000 at 02:43:47 AM EST

Gaack! I read that whole article hoping for them to say: "Yes, $YOUR_FAVORITE_LANGUAGE is best" ... but noooo, they take the easy way out and just flat out say: "Your favorite language is best."

Anyway, I can't complain. They did a great job explaining the difference in methodologies so that developers can make their own decisions.

I'd just have to add that if you're choosing a language for a project, don't discount the task of finding talent to code in the language you choose.

Perl has the advantage because it's just the default, but it just freaks me out as a language... I envision maintainability nightmares.

JSP's look cool because Java is great for complicated projects, and code re-use. But if you don't need that, it's probably tough to -want- to code in Java.

My personal fave is PHP, which is basically C/C++ for the web, except it's got lots of time-saving functions like "in_array(), array_sort()", etc..., as well as tons of hooks to traditional C function calls, like opening sockets, files, etc... The freakiest thing I've seen is http://webnap.sourceforge.net, a freaking napster client written in PHP. Ugh.

TCL is cool because aolserver will run your TCL code internally, meaning no modules, no forking, no nothing. The webserver runs your code as it spits out the page. Plus philg likes it. ;^)=

Python looks nice, but it's functional in nature. A good thing, IMHO, but *DIFFERENT* from procedural programming. I know it'd take me at least a month to mentally context-switch from procedural to functional.

...and ASP/VBScript. *shudder*. Imagine writing a website in QBasic. Basic is o.k. for quick stuff. Basic with objects is just weird, and is a bastardization of Basic. Add to that your typical Microsoft-product aura, and I didn't like it too much. However, I -think- it's the only one of the products which features an on-the-fly debugger/code-stepper/ide that's worth a damn. Supposedly it integrates quite nicely with MS Visual Studio.

Eh. Too much typing, time to stop ;^)=

--Robert
[ rate all comments , for great justice | sell.com ]

Re: IDEs (1.80 / 5) (#5)
by mdxi on Thu Sep 21, 2000 at 06:55:30 AM EST

Just to comment on compiler/stepper/debugger IDEs: The only one I've ever liked was CodeWarrior from MetroWerks. I always thought it was very nicely done, clean and simple, and easy to understand the function of all the parts. The only time I ever used VisualStudio (first day of my first CS class; I asked for permission to use gcc on the SPARCs after that), it just looked like a big jumble of windows piled up on screen, all the same. P.S. It was really funny watching the rest of the class try to make "hello world" work in VS++. It took most of them 30 minutes just to get the concept of a project file figured out. P.P.S. This comment refers to the Mac OS version of CodeWarrior. I've never used any of the other variants.

--
SYN SYN NAK
[ Parent ]
Re: IDEs (1.00 / 2) (#7)
by mdxi on Thu Sep 21, 2000 at 06:58:17 AM EST

Oops. That should have been plaintext instead of HTML.

Mea culpa.


--
SYN SYN NAK
[ Parent ]
Python isn't a functional language! (3.83 / 6) (#10)
by Dacta on Thu Sep 21, 2000 at 08:36:33 AM EST

Python isn't a functional language.

From the comp.lang.functional FAQ:

Functional programming is a style of programming that emphasizes the evaluation of expressions, rather than execution of commands. The expressions in these language are formed by using functions to combine basic values. A functional language is a language that supports and encourages programming in a functional style.

Python is an interpreted, interactive, object-oriented programming language. It is often compared to Tcl, Perl, Scheme or Java. (From the Python summary)

You can find some more ( probably biased ;-) comparisons at http://www.python.org/doc/Comparisons.html



[ Parent ]
Re: Python isn't a functional language! (3.66 / 3) (#14)
by ramses0 on Thu Sep 21, 2000 at 12:05:56 PM EST

I'm sorry, you're right. It's just that it -supports- functional programming, and that's one of the major distinctions (and benefits) of the language, IMHO.

...you can't tell me that a language with anonymous functions and map, head, and tail isn't functional ;^)=

I've been trying to think of a good project so that I can play with python (and put my two books on it to use)... perhaps writing a nice little console browser to play my MP3's? Any suggestions on how to pick up experience with python?

--Robert
[ rate all comments , for great justice | sell.com ]
[ Parent ]

Re: Python isn't a functional language! (1.66 / 3) (#16)
by ordermaster on Thu Sep 21, 2000 at 05:42:01 PM EST

Ive been thinking about picking up some experience in python also. In fact I was thinking about some sort of db backed mp3 jukebox. My only objection to this would be that it is not an origianl idea. We would just be reimplenting something that has already been done.

[ Parent ]
Re: Python isn't a functional language! (3.00 / 3) (#17)
by ramses0 on Thu Sep 21, 2000 at 06:24:51 PM EST

I saw a nice description of a perl script that did something like:

$ play_all *pumpkins*

... which would play anything with the word pumpkin in it, based on your MP3 heirarchy. Very convenient, and it would be good to learn how to handle filenames, directory names, open/close, etc... in python.

Besides, there's no shame in re-writing something that has already been written before (especially for learning). I mean, the only applications I use on my computer are: word-alike, web-browser, vim, email, newsgroups, encode/play mp3's, and corel-draw for drawing.

There's no need to artificially create some application just to avoid doing what other people have done before, IMHO.

The only thing my mp3-playing PHP script needs to do now is log what songs are requested, queue up songs that are clicked all in a row, and print statistics to see what people like to listen to.

The other mp3-PHP scripts I wrote must have gotten eaten when I upgraded from php3 to php4. Eh. Good excuse to rewrite them ;^)=

If you come up with a good idea, post a message somewhere.

--Robert
[ rate all comments , for great justice | sell.com ]
[ Parent ]

Re: Python isn't a functional language! (3.50 / 4) (#18)
by Michael Leuchtenburg on Thu Sep 21, 2000 at 08:17:34 PM EST

I've actually implemented such a script in Python. You actually don't need to learn the things you mentioned ("filenames, directory names, open/close") to do so. Well, okay, you need to do some file input. The easiest way to implement it, that I saw, was to use find to do my indexing. Why should I do it by hand? Sure, it might be more flexible, but I'm not doing a hierarchical index yet anyways (and probably never will; the next step needs a database). Then just take that index, read it in, and run regular expressions on it. Python has a fully Perl-regular-expression compatible regex engine (and 2.0 is fully Unicode compliant, I believe). Simple as that. Of course, this being my first python project, it's mostly crap, though I did have some interesting ideas about command-line argument parsing. Pythons getopt is, well, rather crappy, in it's base form. It needed another layer of abstraction to become really useful.

[ #k5: dyfrgi ]
[ TINK5C ]
[ Parent ]
reinventing unix? (3.00 / 2) (#25)
by saucepan on Fri Sep 22, 2000 at 08:46:57 PM EST

> $ play_all *pumpkins*

Why do you need perl (or any programming language) for this? I couldn't get to your webpage so it may be that you have special requirements I'm missing... however, if all you need to do is run a command on a bunch of files one at a time you should be able to just type something like:

$ find . | grep -i pumpkins | xargs -n1 play

and it'll run the play commands one by one:

play big_pumpkins.mp3
play small_pumpkins.mp3
play bands/smashing_pumpkins/everlasting_gaze.mp3

If it's OK to run the command once, with all the matches as a big long argument list, you can (depending on your shell) just use backticks on their own:

bash$ enqueue_songs `find . | grep -i pumpkins`

Reinventing the wheel to learn how it works is fine, as long as you are aware you are doing so. :)


[ Parent ]
Re: reinventing unix? (none / 0) (#27)
by Lionfire on Tue Sep 26, 2000 at 05:06:45 AM EST

Oo... I'd forgotten all about xargs :)

Although, you can make that a tiny bit simpler by using:

find . -iname '*pumpkins*' | xargs -n1 play

or

enqueue_songs `find . -iname '*pumpkins*'`


(okay.. I think it's simpler, anyway... one less pipe :)

[ blog | cute ]
[ Parent ]
Re: reinventing unix? (none / 0) (#28)
by robin on Tue Sep 26, 2000 at 11:00:19 AM EST

Um, why do you need xargs at all? How about:

find . -type f -iname '*pumpkins*' -exec play {}\;

(If I remember my find syntax correctly, that is?) No pipe at all, and as an added bonus no attempting to play the pumpkins directory...
--
W.A.S.T.E. (do not antagonise the Horn)
[ Parent ]
I am telling you it is not functional (1.66 / 3) (#20)
by BTilly on Thu Sep 21, 2000 at 09:15:04 PM EST

Gimme closures!

Oops, Python doesn't support that. And that is extremely basic for a functional language.

Cheers,
Ben

[ Parent ]

Re: (2.75 / 4) (#11)
by tzanger on Thu Sep 21, 2000 at 09:51:17 AM EST

Perl has the advantage because it's just the default, but it just freaks me out as a language... I envision maintainability nightmares.

Way back when I was a fledgling<sp> Perl hacker I worried about this too. The language is freaky to newcomers. However maintainability is a (potential) problem in any language. I've seen very badly written Basic, C, C++ (working on this right now actually!), Perl, PHP... you name it. Perl makes it easier to write bad code because people tend to get caught up in the ego inflating "what, you can't read that? chuckle chuckle" kind of mentality.

I was on the PHP/Perl fence for a long time. I like PHP, but I liked the fact that Perl is installed on almost every system and that I can write modules and use them in places other than my web stuff. That was the final decision. Perl and PHP have very similar speed ratings and the inconvenience of having to keep up on two more languages was a pain.

For me, Perl was better. I'm no expert Perl hacker but it's a not as scary as it was. :-)



[ Parent ]
Re: perl is unmaintainable? (none / 0) (#29)
by mstevens on Fri Sep 29, 2000 at 09:48:53 AM EST

Perl can be unmaintainable, if you write bad perl code.

But you can write bad code in any language, and end up with something unmaintainable.

I've worked on 20,000+ line projects written entirely in perl. No more maintainability issues than any other language, because the code was well written.

Perl perhaps makes it slightly easier to write bad code than other languages - but there's no real problem with perl. It's perl programmers that are usually the problem.

Michael.

[ Parent ]
ASP? Popular? (3.50 / 6) (#3)
by adamsc on Thu Sep 21, 2000 at 03:55:18 AM EST

I don't know that I'd describe ASP as popular. Widely used, yes but I'm a professional web developer and I've yet to meet anyone who really enjoys it.

<BIGOT TYPE="LANGUAGE"> PHP, on the other hand, is a real joy to use. </BIGOT>

ASP? I _hate_ it! (1.50 / 4) (#4)
by guppie on Thu Sep 21, 2000 at 04:16:08 AM EST

Right on. I've been exposed to ASP, had to do some work with it when I was new in my company. As soon as I had the possibility, I pressured the work onto someone less fortunate, because I deeply, passionately HATE the language...

(And I admit beeing a PHP supporter also, or more generally an anything-but-MS supporter.)

What? The land of the free? Whoever told you that is your enemy.
-Zack de la Rocha
[ Parent ]
Re: ASP? Popular? (3.00 / 3) (#8)
by Aquarius on Thu Sep 21, 2000 at 07:05:29 AM EST

I'm a professional web developer, and I both code in and enjoy coding in VBScript[1]. Personally, I think that Basic is a useful language for the sorts of things that people are doing on the web. VBScript 5 now has regexps, for example, which was one of its big losses; given regexps, you can do pretty much any text processing you want, and that, in my experience, is one of the major parts of web back-end processing. The other major part is database access, and I find that considerably easier in VBScript than I do in either Perl or Python.[2] The actual work is done by the object model, and possibly it's that that you're objecting to; I partially agree with you on this, because things like the FileSystemObject seem a nasty OO bag hung on the side of an otherwise good model.
The error handling in VBScript is pitiful, though; I can see that being somehow fixed in upcoming versions.

Aq.

[1] Just a note for pedantry's sake: Active Server Pages of and for themselves are nothing to do with VBScript; you can host any language in them which can be handled by the Windows Scripting Host, so you can have ASPs with Perl code, with Python, with JavaScript, etc etc. However, I do take your point that "ASP" alone generally is taken as referring to "VBScript in ASPs".
[2] Python, of these, is my language of choice, and it's what I use outside work for coding CGIs and other web development; this is partially because I like it, and partially because there is no Open Source or otherwise free-as-in-beer implementation of VBScript for Linux. (...although Gnome Basic looks quite promising...)
"The grand plan that is Aquarius proceeds apace" -- Ronin, Frank Miller
[ Parent ]
Re: ASP? Popular? (2.00 / 1) (#15)
by adamsc on Thu Sep 21, 2000 at 03:07:01 PM EST

I'm kind of opposed to Visual Basic, not because I don't like Basic (I enjoyed PowerBASIC) but because it didn't look like they'd really thought much about how the language should work; at times it felt like they'd collected all of the features they wanted and relied on huge quantities of expoxy and strapping tape to hold them together. In contrast, PHP has always felt quite natural for me, but obviously YMMV.

That said, my biggest complaint about VBScript is that it's a fairly limited language and thus you end up needing to use COM so often and that's just not as convenient as using built-in features in a more expansive language, particularly if you don't already have a large library of COM objects. I'm also particularly disgusted with the quality of the ASP documentation - on the last large ASP project I worked on, I found less than a 50% success rate for the documentation matching the actual behaviour.

[ Parent ]

Re: ASP? Popular? (none / 0) (#23)
by Aquarius on Fri Sep 22, 2000 at 11:04:49 AM EST

my biggest complaint about VBScript is that it's a fairly limited language and thus you end up needing to use COM so often and that's just not as convenient as using built-in features in a more expansive language, particularly if you don't already have a large library of COM objects

There, I fear, we differ. I think that the fact that there is little built-in functionality in VBScript is a good thing; if most of the functions get hived off to COM objects, then it doesn't matter which language you code in, as long as it can access the objects. This means that you can avoid holy wars of the "MFTL does this, while YFTL doesn't" sort, by saying "here is an object that implements it; call it from VBScript, or Perl, or Python, or JavaScript, or C, or whatever you want."
I think Microsoft have done a very good job there with the Windows Scripting Host and the ScriptEngine in IE/IIS. Batch files not powerful enough? Control Windows from VBScript! Don't like VBScript because "BASIC isn't powerful or useful enough"? Do it from Perl!

Aq.


"The grand plan that is Aquarius proceeds apace" -- Ronin, Frank Miller
[ Parent ]
Slightly off topic, slightly. (2.85 / 7) (#6)
by IoaPetraka on Thu Sep 21, 2000 at 06:57:32 AM EST

I see that Perl and PHP are leading in the micro-poll.

GO PERL

Okay, any way. I came across this paper the other night that would be a nice companion read to this link. It is written by Lutz Prechelt. The download gives you a postscript file, so you'll need ghostview or something to view it.

It is a little research done into the major scripting languages and non-scripting languages such as C, and Java. I was pretty suprised by the results!

.:.
Ioa Aqualine Petra'ka

PDF Version (none / 0) (#26)
by bigbird on Sat Sep 23, 2000 at 04:33:32 PM EST

There is a PDF version available . For those of us without Ghostview.
For I am not ashamed of the gospel of Christ: for it is the power of God unto salvation to every one that believeth; to the Jew first, and also to the Greek. Rom 1:16
[ Parent ]
Not so surprising that ASP isn't included (3.83 / 6) (#9)
by Mobbsy on Thu Sep 21, 2000 at 08:31:30 AM EST

One of the most popular web scripting languages (ASP/VBScript) is not included, however.

Stop me if I'm mistaken, but could that be because the section the article is in (which is at the top of the page), is
IBM : developerWorks : Linux library | Web architecture library

...and I wasn't aware of ASP/VBScript being especially popular on Linux platforms.

Re: Not so surprising that ASP isn't included (2.75 / 4) (#12)
by mr.peabody on Thu Sep 21, 2000 at 09:55:51 AM EST

It may not be popular, but there is a version of ASP for linux.
It was developed by Chili!Soft before they were bought out by Cobalt.
I think Cobalt now sells it bundled with their Cube servers or
something like that. It would have been interesting to see how it
stacked up.

- Mr. Peabody

[ Parent ]
The Perl examples are dangerous (3.83 / 6) (#13)
by BTilly on Thu Sep 21, 2000 at 10:10:09 AM EST

This is what I wrote as a response:

The Perl examples are really bad. First of all in scalar context localtime in Perl gives you a formatted date. "my $date = localtime()". So it is in both camps.

Secondly telling people to parse their own CGI input is simply stupid, asking for stuff to break. Just "use CGI;" then go from there.

Thirdly showing people how to open a file in Perl without also showing them how to check for errors is bad. (open(FH, ">>$file") or die "Cannot append to $file: $!";) THIS IS IMPORTANT!!!!

File reading, in Perl you could just print <IN>; Writing explicit loops etc is counterproductive unless you want to avoid implicitly reading the whole file in which case "print while <IN>" works.

Your split example in Perl failed to include the third argument which you really want in this case. Try "perldoc -f split" for details.

Oh yes, and if you are going to mention data tainting you should mention the -T flag in Perl to check that you are. Perhaps other standard goodies like strict and warnings and...

Regards,
Ben Tilly

Re: The Perl examples are dangerous (4.66 / 3) (#19)
by YellowBook on Thu Sep 21, 2000 at 08:35:50 PM EST

The Perl examples are really bad

Yes, they are. I thought the 'parse CGI POST data manually' was notably bad. Even if the CGI module is too much for what you're doing, I'm pretty sure there's a widely-used 'minicgi' or somesuch that does pretty much the same thing as the python cgi module. I'm a pythonist, but I thought at least that bit was unfair to Perl <wink>

The Python examples are not quite as bad, but are definately very out of date. For instance:

data = regsub.gsub("cat", "dog", data)

Would now use the re module, and be written as:

data = re.sub("cat", "dog", data)

The same goes for:

a,b,c,d = splitfields(lines[-1], ',')

would now be:

a,b,c,d = string.split(lines[-1], ',')

or

a,b,c,d = re.split(',', lines[-1])

or in Python 2.0 (now in beta):

a,b,c,d = lines[-1].split(',')

Thirdly showing people how to open a file in Perl without also showing them how to check for errors is bad. (open(FH, ">>$file") or die "Cannot append to $file: $!";) THIS IS IMPORTANT!!!!

In Python this kind of error checking isn't always necessary. In this case, open() failing would raise an IOError exception, which would either get caught by your program (possibly doing something nice like generating an HTML error page), or go uncaught, causing a stack trace (which in this case would go into the httpd error log).



[ Parent ]
Re: The Perl examples are dangerous (4.00 / 1) (#21)
by ramses0 on Fri Sep 22, 2000 at 01:57:18 AM EST

Damn that's smooth error handling. If I had one wish, it would be that more languages would support error/exception handling. If you are concerned about an error, check for it. If you aren't, then just ignore the possiblity, and hope for the best. But either way, exceptions let you know that an error occured.

I hate that errors might be silently swallowed in other languages, and you just have to hope that they don't happen, or put "if( 0> function() )" calls all over the place.

That has to be one of my favorite features of Java.

--Robert
[ rate all comments , for great justice | sell.com ]
[ Parent ]

(Slightly OT) Exception handling in perl (4.00 / 2) (#22)
by szap on Fri Sep 22, 2000 at 04:34:45 AM EST

This is not as widely known as I would like (or fully rebutt your statement -- perl doesn't throw exceptions by default):

In perl, (die, eval) is equivalent to many languages' (throw, catch):

eval {
    open(FH, ">>$file") or die "Cannot append to $file: $!"
};
if ($@ =~ /^Cannot append to /) {
    # Error handling
}

See perldoc -f die for more info

P.S. Writing code examples in scoop is a PITA!



[ Parent ]
A bit shallow... (2.00 / 1) (#24)
by dragosani on Fri Sep 22, 2000 at 04:51:19 PM EST

...but an interesting read. Wonder why he neglected to mention Lincoln Stein's CGI module in regards to Perl. No one in their right mind parses query strings by hand anymore. Would have been more interesting instead, I think, to do something differrent than comparing boring old CGI techniques but looking at JSP, PHP, Mason, etc., and how they compare.

IBM comparison of web development languages | 29 comments (28 topical, 1 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!