Ted Neward evaluates 20 programming languages
blogs.tedneward.com
blogs.tedneward.com
Nevertheless, Ted is crazy smart and knows a ton of programming languages, and he has a fair number of insightful things to say about the comparisons here. Just go in knowing that he's not going to be recommending Lisp or Python for the enterprise.
(I haven't done a Clojure project, but I imagine it might be unpleasant dealing with the usual Java-isms in the libraries you'll have to use. But at least you'll be able to understand the code a few months after you've written it.)
Can we please finally just accept that ES is much more than just a browser extensibility tool? For most developers, this is their first exposure to a classless prototype-based object-oriented language, and unfortunately, most developers don't ever bother exploring it beyond "How do I make my web page do that floating image thing...?" Gah.
I'm writing Ruby code right now that generates X86 basic blocks to runtime patch Win32 PE images in memory as part of a scriptable debugger for a DMA-driven peripheral I'm reversing. You cannot get more systems-y than I am now. I'm using a REPL to test X86 code written as Ruby. It is the best thing ever.
People who talk about "scripting" languages are the 2008 equivalent of the people who stuck up for assembly language application development in the early '90s: an in-joke for the rest of us.
I am using both scripting (Lua), and Java for mobile development, and I can tell you that in large programs scripting languages start becoming a burden. If you are working on a small thing, or on something when only few people are involved (4 or less), scripting languages are great, but when it comes to larger applications it takes a very high level of disipline in the team, and higher calibre developers to produce bug free code. -- unfortunately not every company can afford high calibre developers, and have to settle with average programmers.
In scripting languages, team member X, and modify a shared component, and team member Y sudenly sees his part of the code doing wierd things, or even failing silently. It is easy to break things appart and introduce bugs in scripting langauges.
In java, if a method's signature get changed, you are going to see compilation errors allover the place that will force you to fix them.
Plus, there is the dynamic languages performance penalty, that will always be there.
I am not advocating Java, as I sweared my next job has to be "Java free", but as a static language (together with C#) it has good place. It allows average programmers to be somehow productive in large systems, where there are many people working at a code at the same time, something that is actually value creating.
I won't rehearse my "high performance systems" credentials here, but I have them, and this meme that the speed penalty for dynamic languages is a problem is a joke. Reread my previous comment: I'm getting in between the processor and the native instruction pipeline in Ruby, and it is, I believe I said, the greatest thing ever.
Belaboring the sentiment: the problem with the "fast systems language meme" is that it leaves you with the impression that the language is where speed comes from. No. It is trivially easy to write slow systems code in C: do everything off an interrupt, do 3 system calls per byte, demand-spawn a thread.
The answer to fast systems is to find the bottlenecks and fastpath them. It is much easier to fastpath a bottleneck when a hash table of digraph structures is 2 lines of code instead of a 1.5mb compiled library with template headers that take 3 minutes just to parse.
None of this is heresy. You can read it in "Expert C Programming: Deep C Secrets", which is the first C book lots of people ever read. Your design is where speed comes from. If method dispatch is a bottleneck, please don't waste time moving to C++: your design is fucked, and you are doing it wrong. Do it right.
My heresy is that static type checking is white elephant. I've been doing this kind of work for going on 15 years now, and I can count on 1 hand the number of head-scratching bugs I've had due to type safety, and that includes 100kloc+ components built entirely around void* closures. The things that really fuck you in large systems are object lifecycle and concurrency.
Actually, C++ is a terrible language for large system development. Far worse than Ruby. Then again, I'm not entirely convinced that Ruby is a great language for large system development, either: monkeypatching in a 50-developer project = teh evil. Of course, you can at least solve the worst problems with Ruby with coding standards. C++ problems are more fundamental.
> My heresy is that static type checking is white elephant. I've been doing this kind of work for going on 15 years now, and I can count on 1 hand the number of head-scratching bugs I've had due to type safety, and that includes 100kloc+ components built entirely around void* closures. The things that really fuck you in large systems are object lifecycle and concurrency.
If you use a powerful static type system (i.e. neither Java's nor C#'s) intelligently, you can sidestep whole categories of problems simply with proper type declarations -- for example, by using different types for escaped and unescaped string data from users.
In any case, the real reason that enterprises are more comfortable with Java and .Net than dynamic languages for major projects isn't speed, it's that the deployment and monitoring infrastructure is mature and well-understood. Obviously, many enormous websites have been deployed on dynamic languages, but enterprises have a much higher comfort level with the tools available for Java and .Net than the tools for doing this with Ruby, et alia. That's why you see a lot more enterprise traction for solutions like JRuby -- problem solved, as far as they're concerned.
They also have the advantage of interoperating with dynamic languages such as JRuby, IronPython, and others to allow you to deploy a mixed static/dynamic solution and optimize for which language style is the best fit for particular parts of the solution.
The largest system built in Scala is probably pretty small at this point. But like I said if you had bothered to read the fucking post, the risks of moving to a new language when you can keep the rest of a deployment stack are relatively small. You're compiling to the same bytecode, running on the same VM, running on the same server, and so forth. Your IT department or hosting provider doesn't even need to know you switched languages.
Please, do me a favor. If you're going to respond to this and tell me that Ruby is the most proven language ever and you can't trust Scala to display hello world, could you try to read the post this time and make at least a passing attempt to respond to the substance of it?
I'm sorry, but the fact that neither Scala nor F# have ever been successfully used in a well-known large-scale project is a substantive argument. Address it! I'm not a fan of C++ either, but guess what? It has a better track record than Scala.
The idea that I'm going to pick Scala over Java "because they run on the same VM" is as silly as the idea of me trying to sell management on building their next product in ObjC, because, after all, they're both generating the same native X86 code. Of course, the real costs and risks have to do with training, maintenance, community, and support, which is why we still use Java.
I'm not sure if you noticed like 4 comments above, but I'm a systems programmer; I have no idea why you think I care that something runs on the JVM. I do, however, sell to enterprises. The VM they care about isn't the JVM: it's VMWare ESX. You could write your app in SNOBOL and they won't care as long as they can plug it into their clusters.
On that topic, I'm interested in creating a something-not-evil to PHP compiler in the style of Fog Creek's Wasabi (not that the language would be an extended version of VB like Wasabi is). Is anyone else interested in working on something like that?