- Ruby (I'm quite fortunate that I'm getting to use this language for money right now)
- Lisp (I've never gotten paid to write Lisp, but would like to)
- Smalltalk (note that I've never done "real" Smalltalk development, but I know about its cool features)
- Groovy
- JavaScript
- Python
- Scala
- Java or C# (or any other mainstream statically typed language)
Interestingly enough, I think C# has the edge on language features (the new stuff they're adding for LINQ, and not doing stupid stuff like type erasure for generics) but the libraries are awful. Java the language is getting really crusty, but they have the best libraries and frameworks in the world (and the most of them too). If you could write C# code with Java libraries, you'd really have something. Of course, they are still statically typed, so you have to pay the static language productivity tax. - boo
- Haskell
- O'Caml
- Perl
- Language_whose_name_I_cant_write_here_because_all_filters_in_the_world_will_block_it
- Cobol (I've never done any real development here either, and don't plan to)
- assembler
- Jacquard Loom (whatever that language looks like)
- Flipping switches for 0's and 1's
- Universal Turing machine (infinite paper strip with a read/write head that moves forwards and backwards). It's just hard to find infinitely long paper strips these days.
Clearly, this represents my relatively recent evolution towards dynamically typed languages. They are simply much more productive if you assume that you write tests for everything, which I always do. Notably absent from the list is Delphi, which is so yesterday's news to me. It became deprecated as soon as C# grew all of its good features and left it behind.
This doesn't mean that I think that Ruby embodies the perfect language (haven't seen one of those yet). But, given the landscape, it feels pretty good, and I keep learning cool new stuff about it.
10 comments:
"static language productivity tax"!!! I love it!
I'm not sure if this was a lovely and intentional poke at the "continuous tax" thingy that Cédric Beust wrote about recently. I had responded to his original post, in which he replied:
(http://beust.com/weblog/archives/000463.html)
I had summed up my thoughts here (http://emphaticsolutions.com/index.php/2007/09/28/testing-static-vs-dynamic-typing/), but you've coined my new favorite term for it!
cheers,
b
A spectrum implies a single dimension. Surely choice of language depends on the task at hand. Different tasks are better served by different languages. None of those you list are good for constraint programming, small devices, driving hardware, parallel programming or computationally intensive highly mathematical programming. Where is Prolog, Mercury, C, GLSL, Cg, NesC, Fortran, J or K, for example, all of which have their niches?
I found it interesting that on your spectrum you have two "pure" models of computation at different ends of the spectrum (LISP and Turing machine). Of course, LISP isn't really Lambda Calculus anymore, so it may be unfair. Still.
No Erlang? No Visual Basic 9? No "a language I've designed myself"?
Further, I gotta say - I'd flip 1s and 0s any day over "programming" the Loom - which would have involved manually punching holes in cards with 18th century tech.
I never implied that this is an overview of all the languages out there. These are just the ones that I would like to code in.
I'd be happy just to break out of the Delphi rut let alone actually use a dynamic language. I have C# experience and consider myself more than competent, but the PHBs in charge of hiring always discount me because I don't have direct experience in some particular nuance of .Net development (none of the criteria I've encountered during interviews are worth a crap).
I just may end up transitioning to my 3rd job in a row based primarily on a dead language I despise - Delphi.
Love your list and mostly agree, but I would swap Python and Ruby [I like python a lot!]
Just for the record, however, the loom is spelled Jacquard. If you're interested, this link gets you to a company that makes jacquard looms for hand weavers (a truly cool tool for us weavers if only the $'s were there (sigh))
And jacquard designs are done with one of several very nice CAD programs, so programming a jacquard is quite easy (no, you don't have to do it in the loom equivalent of assembly language)
Dale (who weaves when he gets a chance)
Thanks for the Jacquard correction. And, if I were going to program one, I'd go old school and not use any fancy CAD program!
If anyone is interested in a "Universal Programming
Language" concept please visit the URL below:
http://groups.google.com/group/universal-programming-language/
Great post, Neal.
As a language fan, it's fun to gaze on this list, but what really gets my attention is that you are _using_ Ruby.
That scores big props from me because you are dealing with real world issues: teams, installs, packaging, unit testing, etc.
As language amateurs (recall that amateur is, loosely, 'lover of' in French), it is easy to say 'oh language X would be a blast'. But often that is for home projects; it is seductively easy to ignore all the logistic details of a real project.
e.g. I have no idea how I would package a Lisp app. (I'm sure one can but usually I think of lambdas, not 'how do i deploy').
Mike
ps. Count me in the Python camp!
I have been a Java and C++ developer for more years than I would like to admit. A recent career move has led me into a .Net- only world. Your statement about Java as a language being crusty, C# is better, but Java has the best libraries, resonated with me. When you work exclusively in the .Net realm, the sense of open source community is essentially non-existent when compared with the Java community. Sure, you have codeplex and a few other MS sponsored efforts...but it's simply not the same.
However, in this situation you can have your cake and eat it too. Your statement "If you could write C# code with Java libraries, you'd really have something". Well, you can to a large degree with IKVM. It really does work, it's technically sound, and since Sun opened the Java runtime, it's even more practical. The efforts of the folks behind GNU Classpath made IKVM viable many years ago. Try IKVM out on your favorite Java library and I think you will be impressed.
Post a Comment