This is very biased toward the considerations of an enterprise datacenter, and thus against languages like Ruby, Python, et alia, that run in their own interpreters, which makes them harder for enterprise datacenters to manage than languages that run in the JVM and CLR, for which tons of monitoring tools and such exist.
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.
And interestingly, he forgot Clojure. It's a decent Lisp, and your ops folks (or clients) can deploy to the existing JVM environment. A pretty good compromise, if you ask me. Oh, and it runs pretty fast.
(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.)
There are also implementations of CL and Scheme for the JVM and maybe the CLR. I know that brlewis is using Kawa Scheme in a large financial company of some sort.
Probably on the "if we ignore it, maybe it'll go away" list.
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?
I've been wrestling with "what to learn next" recently and had kind of narrowed it down to learning Javascript (probably using Rhino) more fully and trying Erlang as my first functional language. I think this nudged me towards Javascript. Even if I stick with Ruby for most of my server-side work down the road--I don't deal with data center integration--it can't make me worse at client side stuff.
Here I stopped reading: Scripting languages have a purpose, and that purpose is generally different from what general-purpose languages do. C# really doesn't need a REPL--don't fall into the trap of trying to make it into Lisp.
That there's a fundamental difference between "scripting" languages and "application" languages? That if there is, Lisp is on the scripting side? That a REPL would be useless to an application developer, or even a systems developer?
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.
"'90s: an in-joke for the rest of us." -- Or maybe you are the VB equivalent of the 90s? Easy to use, and fast, but try to do anything large scale and it becomes a kludge.
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 "large system" credentials here, but I have them, and this meme that C++ and Java are somehow safer for large teams to work in is a joke. I've done large projects in Tcl (!) and in C++ (!$&#) and there are more ways to shoot your teammates in the feet with C++ than in Tcl; they just aren't first-class elements of the language. And C++ is universally regarded as a language for large system development.
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.
> C++ is universally regarded as a language for large system development.
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.
So, the answer to our problems is neither C++, nor Java, nor C#, but rather an unnammed (let me guess: Haskell) statically typed language that no large system has ever been built in.
Actually, I think Scala and F# are good incremental solutions that can use existing infrastructure and approaches to scaling. The risks of moving to a language that can perform better static checks but retain the rest of an existing deployment stack are actually quite low.
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.
Congratulations on spotting a single keyword and otherwise failing to read the entire post! Throwing your fucking "credentials" around and writing your own assembler out of Ruby or whatever doesn't excuse you from exercising some basic fucking reading comprehension.
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?
You went from reasonable-but-wrong to very-angry in the span of just one comment. Why are you taking this personally?
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.
Actually, it's a pretty good C book. I'm just surprised you knew many people who used it for their first book. I would have thought its popularity as a first book paled in comparison with K&R.
he _nails_ javascript (referred to as ES in quote):
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.
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.
reply