Language barriers

I’m currently suffering something of a dilemma as regards choice of programming language for website development. For those of you who aren’t of a particularly geeky bent, this is probably going to seem incredibly tedious, so you probably want to skip on this entry. I suspect, however, that there aren’t many non-geeks reading my blog, so here goes. Ok, so the situation is as follows (you probably already know this, but it bumps up my word count and makes me seem intelligent):

Web pages are made up from HTML (text files), CSS (text files), JavaScript (text files, hopefully kept to an absolute minimum) and various imagery gubbins (binary files). There also exist various bits of chrome such as Flash, but we don’t talk about them. Hence dynamic page generation can consist of any language which takes a set of parameters (the HTTP GET or POST parameters which, by the joys of URL rewriting, can be inferred from the request address) and spits out some HTML code. In theory, this allows a developer to use just about any programming language they like, from the low-level hackery of C to the mathematical incomprehensibility of ML (it’s a Cambridge thing).

Practically, however, many languages just aren’t suitable or useful for spitting out web pages – for example, having an arbitrary C process sitting around on your web server will probably end up having a memory leak, or performing a fandango on core, with rather horrible results. On the other end of the spectrum, something as strange as ML, Haskell or LISP just isn’t very well suited to producing a web page.

So what does that leave?

Well, it pretty much leaves (in rough order of hackishness) Perl, PHP, Python, JSP, and “this .NET lark”. These languages, however, all seem to have certain flaws:

From this hideously long ramble, I draw four conclusions:

Until next time.

11 Responses to “Language barriers”

    •  Gravatar for Jonty
    • From Jonty
    • Wednesday 15 December 2004 at 15:37

    It’s time like this when you realise you really having nothing to worry about compared to the troubles of others πŸ˜‰

    •  Gravatar for Ben
    • From Ben
    • Wednesday 15 December 2004 at 22:23

    Tsk, getting lazy with your use of <abbr /> and <acronym /> boy – PHP getting special treatment over JSP?

    I’m still bemused by your comments on JavaScript though. Sure, over the years it’s been abused for producing vital page content, but when used for its actual purpose (adding dynamic behaviour) and ensuring that said behaviour is not mandatory to the accessibility of the page, I really don’t see what the big deal against it is.

    Dunstan implemented an excellent ‘display author after blockquote’ script on 1976 when he last redesigned (a trick I’ve implemented on Resin‘s website). It lists the name/url of the author after the block and adds a hyperlink around it if the cite attribute is a hyperlink. While CSS can be used to extract the attribute and display that using the :after pseudo-element, that denies the user of inserting HTML for linking. Add to this the fact that more people have access to JS than CSS2 and it strikes me that if you are weighing up presenting an optional nicety feature or not providing it at all how can it be wrong to use JS for the purpose?

    Oh, and I’m not convinced by the accuracy of your Chrome definition. Consider that the entire XUL content of Mozilla browsers is globally referred to as the ‘chrome’. “Showy features added to attract users but contributing little or nothing to the power of a system.” doesn’t seem an accurate description of Firefox’s back button. ;p

    On Topic: Web Dev is certainly an interesting field though with the choice of languages available. Something else you could look into (which I’ve not, as yet) would be PHP’s ability to call Java (and .NET, for that matter). You could have your more complex, type safe vital code written in Java and call it from within a PHP XHTML template.

    •  Gravatar for Fatty
    • From Fatty
    • Wednesday 15 December 2004 at 23:49

    That definition of ‘chrome’ is the Mozilla Foundation’s definition of chrome – it’s what they’ve chosen to name it. That doesn’t mean that the accepted use of ‘chrome’ is inaccurate. If I decided to call my blog a radish, this wouldn’t change what the accepted definition of ‘radish’ was (extreme example, but you get my point).

    •  Gravatar for Ben
    • From Ben
    • Thursday 16 December 2004 at 00:42

    I suppose if I was a Linux user, then the back button would be chrome wouldn’t it?

    I can accept that such a definition exists, I’m just not convinced that it’s necessarily a good one to use in a time when major pieces of software have evolved the usage. Unless it’s a W3C standard that I’ve missed, of course πŸ˜‰

    I have a feeling that I should probably do some Python learning myself really, at least to try it for a week or two to compare to PHP and ASP.NET. I reckon that this page on integrating Python development into Eclipse is probably a useful one to offer about now…

    (P.S. I’m mortally offended your spam filter taking offence at 1976 design… πŸ˜‰ Well, maybe not mortally.)

    •  Gravatar for Fatty
    • From Fatty
    • Thursday 16 December 2004 at 09:51

    I think the spam filter just took offence at you having several links in your post – due to the recent glut of comment-spam I’ve been receiving, I’ve given my spam filter quite an itchy trigger finger.

    •  Gravatar for Ben
    • From Ben
    • Thursday 16 December 2004 at 10:25

    Aye – I gave two links rather to the same domain, which would seem like a pretty good condition to match on, though I’d be inclined to set that to 3/4 rather than 2 given the content of all the comment spam I’ve ever seen.

    •  Gravatar for Jo
    • From Jo
    • Thursday 16 December 2004 at 10:35

    I’m not a geek, and I read your blog :) I even understood parts of that… Oh, and your link to Ben’s blog is broked.

    •  Gravatar for Jonty
    • From Jonty
    • Thursday 16 December 2004 at 15:02

    I have to agree with Ben, I don’t mind Javascript when used properly (which, admittedly, for a long time it hasn’t been). I don’t think I’d ever build a site which relied on it (I have in the past, but that’s another story) but given that much of it is now standardised, I think adding a few frills is fine (a la Dunstan).

    Take, for example, Google whose new Google Suggest and Gmail really show off the power of Javascript. Secondly, I don’t think I’ve ever met someone who hasn’t been impressed by Youngpup’s menus.

    As for acronyms and abbreviations (yes, I know I’m preaching to the converted) but check out Saila’s article on the matter, very good indeed. Now all we need is IE to support <abbr /> with the use of hacks and/or IE7 and we’d be laughging :)

    Kind Regards


  1. Which web development language you go for depends very heavily on what you want to do with it. PHP is perfect for projects like WordPress because it’s widely supported by hosting services; if WordPress used Python it would be far less popular.

    I find it hard to say nice things about Perl because the syntax gives me nightmares, but if what you want to do is a little out of the ordinary but is already covered by some CPAN modules then it could be a really good choice.

    I haven’t used Java or ASP.NET for web stuff, but every time I’ve programmed in Java I’ve found myself taking far longer to produce anything because all of that syntax (the type stuff and everything-must-be-in-a-class) mean I spend more time thinking about the language than the actual problem! As for ASP.NET, some of the key things it has baked in to it (like every-page-is-a-form, and big ugly state-saving hidden variables) just give me the willies. It’s possible to develop around them, but it really puts me off the whole platform.

    As you mentioned, PHP may be an excellent web development environment but it’s a pretty poorly designed programming language – the lack of modules or namespaces alone is enough to make building large PHP systems a lot harder than it should be.

    That leaves two options: Python and Ruby. Both are very well designed languages, and both have good web support. Ruby on Rails is certainly getting a lot of well deserved interest these days, and mod_python and mod_ruby put paid to performance problems involved with running scripts as CGIs. I stick with Python because I know it and it has a larger community, hence there’s more stuff going on with it – but Ruby is certainly worth investigating.

    •  Gravatar for Fatty
    • From Fatty
    • Saturday 18 December 2004 at 23:34

    While it’s true that wide server support is important in how suitable a language is, it’s also true that it’s rather transient. If a language is good for the purpose, then people will badger their hosting providers to provide support for it. If no-one’s really using a language, then providers may well remove support. All assuming, of course, that supporting that language is technically feasible (e.g. mod_perl, mod_python etc). It’s something of a positive feedback loop, but a sufficiently large difference in the quality of programming languages can shift it one way or another.

    I definitely agree with you that Java is just about the saltiest and most verbose language known to man, although I haven’t yet decided how much of a good or bad thing this may or may not be. I think it’s pretty indisputable, however, that having every page as a big momma form is a Bad Thingβ„’.

  2. People have been badgering their hosting providers for support for mod_perl for years, but there are some pretty big technical reasons going against them. Because of the way mod_perl integrates with Apache it’s possible for a badly written mod_perl script to completely hose the whole Apache setup, which in a shared hosting environment is lethal. Also, both mod_perl and mod_python really need the ability to edit the httpd.conf file to be useful – another thing that shared hosts are very cautious of.