Interesting comment about Google Go
kplug at davidb.org
Sun Nov 15 00:05:20 PST 2009
On Sat, Nov 14, 2009 at 11:36:55PM -0800, chris at seberino.org wrote:
>On Sat, Nov 14, 2009 at 09:10:05PM -0800, David Brown wrote:
>>> At this point, I will no longer create anything large in Python
>>> anymore. I would eat the learning curve and switch to Clojure.
>> I'm going to second this recommendation.
>Why is Clojure suddenly the best language for large apps for you?
>What happened to Scheme, Common Lisp, Haskell, Go and Ruby?
Don't forget, I learn languages, constantly. To do that, I have to
use them enough to write something significant in them.
I'll go through your list:
- Scheme. Basically, the language definition is too small. I found
that all of them implementations had various drawbacks and pieces
missing. There are also some aspects of scheme that seem to be
done out of "purity" rather than practicality. For example,
call-cc can make reliably cleaning up things like file-descriptors
Scheme also has too small of a community that there's not enough
other code to use. It's also a problem that anything beyond
very carefully written code isn't going to work on more than a
- Common Lisp. I like Common Lisp, but it has a lot of baggage. A
lot of the language design was decided when things like compiling
an entire file were slow. Common lisp also wants too much to be a
platform, which was probably fine 15-20 years ago, but I need
programs that work _with_ the other programs on my computer, not
live in their own little world.
- Haskell. Haskell is brilliant. Haskell is also one of the most
difficult languages I've successfully learned. It doesn't really
get easier, either. There's also some serious problems that even
GHC people realize are problems, but they just can't figure out
how to address. For example, there's no portable way to create a
global that is associated with IO. The standard library has a
bunch, since they're kind of necessary. It ends up becoming this
cumbersome mess to pass state around, and when that gets too hard,
wrap it in a Monad that is fragile when the design changes
Basically, Haskell is too hard to program practically in, and the
resulting code too difficult to practically refactor. Also, the
type system kind of falls on the severely-strict end of the
static/dynamic spectrum, which isn't necessarily pragmatic.
- Go. I've not actually really been interested in Go. I'm sure
it'll go on and be as wonderfully successfully as Plan 9 has been.
- Ruby, see below. Definitely still my favorite scripting language.
But, I also use Python, especially at work, since there are more
people that know it.
- You missed Scala. I think Scala is good, but I like Clojure
better. Scala avoids the dynamic side of programming (it's type
system is almost as strict as Haskell's), which makes it more
cumbersome to prototype and do quick things on. Clojure also has
a better interactive environment (Scala's strong type system hurts
iterative development, mostly because the compiler is about an
order of magnitude slower).
>Last I heard you liked Ruby especially.
I do like ruby. I get the sense you're still thinking you're going to
fine the one perfect langauge that will be appropriate for all
Keep in mind I've only been programming in Clojure for about a month,
but so far, it seems to strike a surprisingly good balance of language
- A good pragmatic balance of a type system. It doesn't hide from
the JVM's type model, e.g., it's Strings are Java Strings,
although it does have it's own Map/Set/Vector types that are
immutable, the present interfaces so they interact well with Java.
I can start writing code using keyword-indexed hash maps. Later,
when this starts to get difficult to track, I can create actual
structs/types, and use them in almost exactly the same way (use is
the same, creation differs slightly). The improvements Rich is
making actually make 'deftypes' directly map to JVM classes with
- A good understanding of what aspects of OO are the good parts, and
which parts are making things worse. OO tends to conflate
multiple langauge problems into one messy solution. Inheritance
is invaluable for polymorphic types. But a lot of my code doesn't
fit this kind of picture. Namespace management, encapsulation,
and even method inheritance have better ways of handling them than
through class inheritance. Clojure brings a lot of this together
in a clear and quite simply way.
- The language is simple. When I first looked at the spec I wasn't
even convince that it was sufficiently finished to do practical
programming. By having so many consistent interfaces, the library
of functions/macros to learn is much smaller. This is one of the
hardest parts of Common Lisp.
- The people working on it really seem to know what they are doing.
- It runs on the JVM. Just having such a large amount of code that
mostly just works is valuable.
More information about the KPLUG-List