
Ted Neward evaluates 20 programming languages - pchristensen
http://blogs.tedneward.com/2008/04/29/Groovy+Or+JRuby.aspx
======
wanorris
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.

~~~
jrockway
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.)

~~~
Zak
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.

------
jrnewton
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._

------
tptacek
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._

~~~
michael_dorfman
You disagree? How so?

~~~
tptacek
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.

~~~
ardit33
"'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.

~~~
tptacek
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.

~~~
wanorris
> 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.

~~~
tptacek
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.

~~~
wanorris
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.

~~~
tptacek
And the largest system built in Scala would be...?

~~~
wanorris
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?

~~~
tptacek
Wow, that struck a nerve, didn't it?

~~~
wanorris
Thanks for making it clear that you have nothing to contribute to the
substance of the matter except for snide remarks.

~~~
tptacek
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.

------
justindz
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.

------
ajbatac
Where's PHP?

~~~
Zak
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?

~~~
pchristensen
It's a brilliant idea for a project. I'm not sure if I'm up for it now but I'd
love to hear about how it progresses.

