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:
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.
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:
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.
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.