anyways. I have some reasons for my strong dislike of Java: a) checked exceptions, b) no method pointers or something similar and c) lots of the code produced by the community out there (and in the standard library itself) is full of FactoryFactoryFactories and other typing intensive, mind-bending and ultimately useless abstractions (most of them not DRY at all either).

Back in 2004 I did strongly consider Java though, but ultimately, I didn't have time to implement this web application AND learn a new library (learning the language is easy. learning the library is what makes you slow in the beginning).

As a side note: Said web application also accesses locally connected barcode scanners over the local serial port. Unfortunately the only way to do this (aside of a locally installed client) is still using a Java Applet which I've also written back in 2004. So I do have the Java experience to know that I don't quite like it :-)

Indeed, this whole thread's reminding me of:

"Combining the sanity of threads with the robustness of web development" http://wearehugh.com/public/2010/08/html5-web-workers/

The stigma that Java has too many checked exceptions is no longer true with modern Java code. Everyone is using unchecked children of RuntimeException almost exclusively. Of course, there is still plenty of legacy code out there using outdated checked exception paradigms.

So what? Why does the code produced by others in "the community" affect your perception of the language and/or tools, if you aren't using their code?

If you're one guy off in a corner, write however you want. But if you're not, you have to take the culture into consideration. And if you are one guy in a corner, why are you using Java?

Java has a very strong culture around it. I worked in academia and startups previously and I didn't realize that there is a huge number Java programmers who do nothing but program in Java. They aren't interested in learning new languages and will only grudgingly learn a new framework. Their biggest concern making sure the lowest common denominator can still maintain the (unmaintainable) code.

An example is unit testing. Our current "unit" tests start up a JBoss instance, connect to the development databases, and take ~5 minutes to run just one test. But I've been told not to waste my time working on anything more modular and that if I'm going to put in any time working on unit tests, I should contribute to the framework everyone else is already using.

It can be quite soul crushing.

Always remember: "It's easier to ask for forgiveness than for permission."

If you want to do better than the cultural norm demands, nothing's keeping you. What's the worst that can happen?

I think that "one of the biggest financial companies in the world" would be just as conservative and anxious about the tiniest technology changes with any language: Ruby, Perl, or Fortran.

The attitude you describe sounds like it has more to do with being a large financial institution and the type of place where software development is a "cost center", not a profit maker.

Ask for forgiveness after you do something...

The other way to go about it is to 'gingerly' find the single ally, and build on that.

He tells me horror stories of code he refactors at work written by people in his own office, or worse, outsourced companies, and it's bad. It seems to me that that kind of code is more representative of the community.

When you're going to join a project, you have a better chance of encountering code not sucking if the overall culture of that language is better.

[1]: http://www.youtube.com/results?search_query=eclipse+sorcery [2]: http://theoatmeal.com/comics/literally

but I hate. No. HATE PHP's type conversions with its == operator.

    0 == 'foobar'

    true == 'foobar' && 0 == false

    true == false ?

Yeah. I know === exists. But if you have to compare strings and numbers, why is the default conversion method you do the lossy one? If you compare a number to a string, why can't you convert the number into a string and compare the two strings? Why convert the string into a number which will be lossy in most cases?

http://stackoverflow.com/questions/359494/javascript-vs

It's not that hard to get your head around, and at least one other major language does it this way.

And if you know something could return 0 (which is not empty), you should know to do a type-sensitive check). You are trading off HAVING to set types with HAVING to check types when needed (I think the latter is better).

I hate this as well, but, I love dynamic typing. They aren't the same thing.

In PHP 5.3 you'd just pass the function (which of course will pass a pointer to that function) and in earlier versions you'd hack something with eval or variable-variables which, while bad, is still better than either writing half a screen full of empty methods or inheriting an inner class from some meaninglessly named class that only exists for you not to have a screenful of empty methods.

Having said that I wonder if missing the 'beauty' of async I/O etc has more to do with the projects people take than the language. Would a python or ruby developer who focuses on creating web apps have any more familiarity with those concepts than a PHP developer?

One of the reasons for this is because PHP was designed to quickly handle single HTTP requests. The scaling is ment to be done on the app-server side and that single request that your script is serving at a given time will take as long as it will take anyways.

So you don't really need the async I/O (in theory).

Python and Javascript (and to some degree ruby) rely on their own web servers implemented in their own language, in many cases with no or bad (GIL) concurrency at which point it gets more interesting to move into an event based model where it becomes imperative that operations don't block.

There async I/O becomes important.

So: PHP: concurrency by firing off another apache/fastcgi process or thread. Don't worry about blocking on I/O.

node.js and some python/ruby frameworks: concurrency by using an event based system. Because one operation blocks the whole server, they need to be quick. async I/O becomes important.

Of course the evented model has huge advantages too: You worry much less about races, you get huge performance with a simple architecture and you can potentially handle much more concurrency (because each thread/process consumes resources that your one evented process does only once).

Both paradigms are interesting, but having first-class functions certainly makes an evented model more convenient to work with.

EDIT: I don't hold that view because of the things I mentioned but I am pretty sure a lot of programmers do.

I will have to agree with you that PHP is perceived as a web language. Hopefully with more articles like these that perception will change.

They are a bad idea, in general. PHP is designed for a very specific purpose: Very quickly building web pages in a CGI or mod_php environment and spitting them out. Everything else is an afterthought, and it shows.

For example, if you try to manipulate the filesystem extensively using PHP you will eventually trip over its "stat cache". PHP caches the result of stat() calls, presumably assuming that, hey, it is more important to avoid redundantly calling stat() during the time-sensitive rendering of your web page than it is to actually return correct information about the state of the filesystem. I mean, how often do symlinks change or files get moved during the rendering of a typical web page? And how much web-page-rendering code really depends on being able to read a link, then read the link again after the link has changed on disk? You can afford to ignore that stuff at the language level, if you're PHP.

The result is that you have to learn about the stat cache and remember to call clearstatcache() all the time when manipulating the filesystem in PHP.

That's just one example of why it's better to use Ruby or Perl to write command-line scripts. These languages were designed with command-line scripting in mind. Indeed, this is the flip side of the reason why PHP eventually drove out Perl as a web development language: Perl was originally designed for command-line scripting, and PHP was originally designed for the web. Use tools for their proper purpose.

Java was originally designed for programming embedded devices. Python was originally designed as a teaching language. One anecdote suggests that Lisp's original designers always intended to add syntax to the language.

Perhaps a decade after a language's invention it's possible to discuss its current suitability and design for specific tasks more than its original design intent.

(I consider PHP's relative ease of deployment over everything else far more explanatory of its ubiquity than any original design intent.)

Things like "stat cache" and "memory leaks" are what I watch out for when I write command line scripts in PHP. Also, I do not run my scripts as a daemon and I make sure that they do not run for more than a set maximum execution time.

So yeah, it may not be the most perfect choice but, it beats : having to learn another language when I know what to look out for when I write a command line script in PHP.

JavaScript. Sure, in theory you can use it on the server for other things. Have you seen that happen lately?

Running on v8, it has an edge in terms of execution speed over other scripting languages. And the javascript syntax and semantics is something most of the developers are familiar with.

If you don't like writing nested closures, you have coffeescript which makes the code pretty, and also brings in some new features viz. list comprehensions, splats, satement modifiers etc.

FYI, JavaScript programmers use asynchronous I/O all the time. That's what the 'A' in AJAX stands for...