Languages: worst case vs average
This is a pretty good take on Tim Bray vs Erlang. However, I'd like to focus on something said at the end:
The fact is, all languages optimize for particular problem domains and I don't think that a universal programming language exists that would perform well on all tasks. Bray rapidly found out that Erlang isn't optimized for doing line-oriented I/O and it's regex library sucks. So what? While those problems could be eliminated from Erlang, the fact that Ericsson has deployed large telecom gear without having to fix those issues means that Erlang is ideally suited to its original programming domain.
The problem is that learning new languages is difficult for many people. They're not going to bother starting from 0 with a new language if what they've got is only 10/20% worse than the other guys. For companies, developing expertise (and trying to maintain it) in lots of languages is probably less productive than picking a few (Google only has four: Java, Python, Javascript and C++, and they're not exactly lacking in brainpower or cash). This is why "the right tool for the right job" works for things like saws and hammers, but not for complicated, idiomatic things like programming languages.
Therefore, it's important that languages that aim to be widely used do lots of things pretty well, and try to avoid doing anything really badly. This is something I've always admired about Python, even if I don't use it anymore. It's a language that you can do a very wide variety of tasks with, and you can be sure there's probably some code out there already, and that Python will be ok for your task, even if it's not the best thing. Performance is a weak point compared to compiled languages, but even there, get the libraries right and things aren't so bad.
In any case, my point isn't to bash Erlang (which I like), or put Python on a pillar (I prefer Ruby and Tcl), but to say that a widely used programming language doesn't need to be the best at everything, but it should aim to make people comfortable using it, safe in the knowledge that they can probably do most things ok if needs be. That's a far better situation than being able to do one thing realy well, and perform poorly at many other tasks, forcing its users to look elsewhere for solutions to those tasks.
Personally, I think that for concurrency, Erlang is in a bit of a race right now - they're pretty far ahead in terms of concurrency (and also fault tolerance, but fewer people care about that), but behind in other areas (less library code). Other languages don't have as good a tools for concurrency, which isn't an easy problem. So, what will happen first - Erlang catches up elsewhere, other languages get "good enough" concurrency solutions, or a new language (like Scala) comes along and takes the lead?
Trackbacks
Use the following link to trackback from your own site:
http://journal.dedasys.com/trackbacks?article_id=1813
-
I've been following for quite some time now the various blogs and articles regarding Erlang. In general, the ones by David Welton I've found the most enjoyable. But one thing I've noticed whenever new languages are discussed are that one tends to...
about 3 hours later:
The problem is that often languages aren't 10-20% better/worse for a particular domain. Sometimes the difference is 50% or 2-3X.
Anyone who thinks it's difficult to learn a new language shouldn't be a computer programmer, if they have that little mental flexibility. All procedural languages implement the same basic constructs. All OO languages implement those basic constructs, then add other basic ones. If someone doesn't have the mental flexibility to be a language polyglot, then I'd rather not have them on my team.
about 3 hours later:
The problem isn't about polyglots or not - I have worked professionally with lots of languages, and written one of my own. I like them. However, it's not easy to swap back and forth between too many of them, so I think even if you are a polyglot, it's likely best to stick to a few that you learn well in any given period of time. By all means, learn some others for fun, but you have to keep some focus or risk serious messiness.
about 5 hours later:
I've always been a proponent of the "use the right tool for the right job" theory of programming language choice, but every time you add another language to a project, there's yet another impedance barrier that needs to be overcome. Unless your software is carefully kept as modular as possible, and communication is via a standard (ala the JSON APIs for CouchDB) you end up with layer after layer of bug-ridden compatibility code just to allow components to communicate. More often than not, it makes sense for individual projects/services/apps to allow at most two or three languages (for code, scripting, and configuration).
about 8 hours later:
In the areas where Erlang has been mostly used - telecoms, banking, etc. - libraries are not lacking, but rather quite excellent. For people e.g. used to programming in Win32, with fancy graphics, COM, ODBC, etc. - Erlang doesn't have much to brag about.
In general, it's easier to fix libraries than core aspects of the language, but there has to be enough momentum. In many languages, concurrency will continue to suck because there simply isn't enough motivation within the community to fix it (even if it were doable). It remains to be seen whether enough momentum builds within the Erlang community to improve library support and specific performance aspects for niches other than telecom.
about 17 hours later:
I'm curious as to why you don't use Python any more. As a former Tcl guy and occasional Ruby tinkerer, I'm wondering what you've gravitated to after Python.
about 21 hours later:
I still use Tcl actually. I also use Ruby a lot. Something about it appeals to me more than Python (which I actually haven't used for quite a while), but I won't argue that one is better, it's a matter of taste. Both languages have things they do better or worse than the other.