Hacker News Reader

Comment by papaf | Hacker News Reader

Last year I needed to do a small project to run on a web server with only Apache available. Rather than go to the pain of requesting some new web stack installed I wrote a single CGI script in perl 5 - just as I used to many years ago.

I did it the old-school way with no fancy framework, just CGI.pm. I made fun of myself to my collegues saying it was great to live in the 90s again. But actually, after a few hours coding it became clear that we haven't progressed very far.

It was a single script and it just worked. It was also much more fun than persuading a web framework to do what I wanted because I was actually programming and not configuring.

View on HN

It's a similar experience in Java-land when you throw out the frameworks and all the servlet container bullshit and just start up an embedded Jetty. It's easy, lightweight, fast, you can do anything you want without crapping out mountains of XML configuration, or layer upon layer upon layer of introspecting, byte-code engineering, dynamic code-rewriting-where-the-hell-did-THIS-code-come-from annotations. You have control, in the place where it matters - the source code. You can write end-to-end tests that developers will actually run, because they don't need to spin up JBoss for 5 minutes before they're ready to go.

Frameworks have got a lot to answer for; it's very rare that a large project actually gets to use the flexibility that a modern framework provides. Who the hell actually swaps out their ORM or their database for a different one in a production system? Sure, the lead architect was sold on the idea that they wouldn't be tied to a particular implementation, but when the shit hits the fan the business will deem it "too risky - find another solution".

Thus we advance to the third level of professional software development, the Sarcophagus model - wherein it's simply too risky to actually CHANGE any part of a (now-legacy) production system, but we CAN build a sarcophagus around the toxic core such that no more careers need be sacrificed to trying to maintain it. I have some great examples of this, but professionalism forbids me from relating them. Perhaps when I finally decide that keeping sheep on a remote island is preferable to being a software "engineer", I'll start writing about them.

So right. Just spin the damn jetty, put the postgre driver and off you go. Most of the infrastructure is done in a day or two, and if not enough you can always revisit it later. And it runs fast. So fast that it feels like dynamic language. And even with the modern apps, where most of the action is on the client (and the server is interface to the DB most of the time) you even don't need to restart your server that often.

I think that whoever says that Java is not good language for development either have seen only j2ee or never did looked around. (as a prime example the stupid bean convention and tools which operate on it)

I know my reason for not wanting to develop in Java is that since for the most part the speed difference doesn't matter for my needs, it boils down to how easily I can transcribe/translate my concepts into code.

The conceptual impedance of Java is just higher for me. I think most of the code I write (the non-algorithm complex stuff) that boils down to stuff like "take the subset of the collection of orders with a total over 100, and sort by number of items." In Perl, that may be as simple as:

    my @large_orders = sort { $a->{items} <=> $b->{items} } grep { $_->{total} } @orders;

I think allowing me to express myself easily and succinctly like this saves time, reduces errors and allows me to concentrate my time and attention on the more complex portions of the code.

I also think succinctness (where idiomatic for the language, so it's not confusing) is useful in it's own right. The more of the current (or related) function and program state that's obvious on the screen when I'm coding, the less likely I am to have to break off from what I'm doing to go look up a detail I need.

Not a great advert for Perl, that, since it doesn't implement the quoted action correctly...

D'oh! You're totally right, I forgot the greater than filter in the grep.

    my @large_orders = sort { $a->{items} <=> $b->{items} } grep { $_->{total} > 100 } @orders;

Embarrassing.

Because `> 100` is missing from the condition? Other than an example of poor copy-pasting of code, how do you conclude that it is "[n]ot a great advert for Perl"?

For the record, this would be the code with missing part included:

    my @large_orders = sort { $a->{items} <=> $b->{items} } grep { $_->{total} > 100 } @orders;

It might lead someone to conclude that Perl users were slapdash in their approach and prone to tossing off untested code. Possibly unreasonably, possibly not.

More often than not, I am wondering just how much complexity one could spare themselves from if they would just use tomcat and postgres/mysql/some-nosql instead of a full-blown oracle-enterprise DB and a serious-business "application server" - both of which said applications are using maybe 10% the features of and basically never any of the really cool features that make them so expensive in licensing.

I know exactly what you mean. I banged out emacsformacosx.com in a weekend and wrote a real quick CGI program in Perl just so I didn't have to keep typing "make" or something while I was writing the site (since I was using Template::Toolkit). I fully intended to move it to "something good" once it was done--there's no way CGI can work on a site with more than 10 users, right?

Well, after 3 years it's still plain perl CGI. Every web request, forks, compiles the perl code, compiles the template code, stat()s over 3000 Emacs builds and then renders the page. There is no caching. It's wrong my almost every measure of modern web code design. And yet, it's still fast enough for the amount of traffic it gets.

Oh, and it's still hosted by a computer in my house over my cable modem. Yes, it's a niche-y site, but it turns out that niche-y sites can still do a lot with a little, even on today's web.

You would love Go and using its "net/http" package.

Reply on news.ycombinator.com