(1) Erlang, Ocaml, Common Lisp, Scheme, and Haskell can all, with relatively mundane code, parse a TCP/IP packet in 4 lines, nicely formatted, and some of them gets it type-correct at the same time. The problem isn't that you cannot do it in C, the problem is that you are wasting your time doing it. When it is reasonably fast as well, there is no excuse.
(2) Indeed.
(3) JIT and tricks from Self will not make the code faster than a well-implemented Ocaml. Also, the complexity of said implementations leaves much to be desired. If you know how little optimization the Ocaml compiler does when compiling to native code you are pretty amazed that it is so damn fast.
The point here is: will $LANG scale along the speed axis? Currently (it may change) Python doesn't. It scales up to a point at which you go write your code in C/C++. JSON decoders/encoders that are fast happens to be a nice example. Contrast that with Haskell, Ocaml, Common Lisp where you can improve your program and scale it far more on the speed axis before you have to succumb to Fortran77 for your libatlas ;)
For most problems, this scalability is not that important. But then again, there are some where it is crucial you can get that extra speed.
Personally, I program in both Ocaml and Python at work. We have most web-stuff written in Python whereas some backend parts, where correctness and speed matters, are written in Ocaml. We could have used C/C++ at the backend, but our development time is much lower in ML with a fraction of the effort required.
On the other hand, the Pylons framework does wonders for the web-frontend. We don't need the type-correctness as much there, the speed doesn't matter that much either as long as we can serve pages up quickly enough. I would be sorry using Ocaml there as it would hamper the development speed and take more time.
You're right of course. I was also considering showing off the loop macro. That one actually wouldn't have been cheating, since it shows off macros (A pretty nifty and central feature of Lisp)
(loop for x from 1 to 10
as x-sqr = (* x x)
collect x-sqr)
(2) Indeed.
(3) JIT and tricks from Self will not make the code faster than a well-implemented Ocaml. Also, the complexity of said implementations leaves much to be desired. If you know how little optimization the Ocaml compiler does when compiling to native code you are pretty amazed that it is so damn fast.
The point here is: will $LANG scale along the speed axis? Currently (it may change) Python doesn't. It scales up to a point at which you go write your code in C/C++. JSON decoders/encoders that are fast happens to be a nice example. Contrast that with Haskell, Ocaml, Common Lisp where you can improve your program and scale it far more on the speed axis before you have to succumb to Fortran77 for your libatlas ;)
For most problems, this scalability is not that important. But then again, there are some where it is crucial you can get that extra speed.
Personally, I program in both Ocaml and Python at work. We have most web-stuff written in Python whereas some backend parts, where correctness and speed matters, are written in Ocaml. We could have used C/C++ at the backend, but our development time is much lower in ML with a fraction of the effort required.
On the other hand, the Pylons framework does wonders for the web-frontend. We don't need the type-correctness as much there, the speed doesn't matter that much either as long as we can serve pages up quickly enough. I would be sorry using Ocaml there as it would hamper the development speed and take more time.
Bottom line: I dual-wield!