Mark Watson's opinions on Java, Ruby, Lisp, AI, and the Semantic Web

For my own research (not for consulting work, at least for now) I need to speed up machine learning runs and other experiments. I have "4 cores" to work with (and I hope that my next server purchase for my home office has many more than that) so I have been playing around with different programming languages that support concurrency without a lot of effort.

Haskell has impressive run time and memory performance; for example: comparing Haskell and Scala. I have been reading an online version of "Real World Haskell" and recently ordered a print-copy of the book.

I usually do most of my exploratory/research programming in Scheme or Common Lisp so using a different language is fun. Gambit-C Scheme does have the Termite package for concurrency but something more main-stream like Scala or Haskell seemed like a better idea. I invested some learning time in Erlang about a year ago but I think that Erlang is more optimized for concurrency over different computers on the same LAN rather than using many cores in a single server.

Labels: Erlang, Haskell, Lisp, Scala, Scheme

I bought Joe Armstrong's new Erlang book as a beta PDF early this year and have been enjoying the material (the book is now in print). Erlang definitely has a lot of hacker mindshare but I have been unable to convince my customers to use it (so far). This may be a generalization, but those of us who love to program in Prolog are very likely to also enjoy working with Erlang. Erlang is certainly a great tool but I think it is unlikely to be very popular for two reasons: it does not provide instant gratification like Ruby on Rails and there is no large company promoting it (e.g., like Sun, IBM, etc. promote Java). That said, Erlang has a great open source community behind it and learning Erlang is very worthwhile if you occasionally need scalable applications. A comparison with Java is interesting: Java (especially with the new concurrency support in JDK 6) scales well on single servers with large numbers of cores while Erlang probably has the advantage when scaling to multiple servers.

Labels: Erlang, Prolog

Based on experience with consulting jobs developing web applications using several Java frameworks, Ruby on Rails, and Portable AllegroServe with WebActions (open source Common Lisp frameworks), I believe that choice of framework is less important than:

• Programming language: choose a language that both fits the application domain and has good library support for your application
• Data modeling: while I believe in interactive bottom up development, spending time up front getting object models 'right' makes development easier
• Object persistence: there are lots of good choices (prevalence, object relational mapping for relational databases, distributed memory only, etc.) but choose a scheme that makes sense both for development and deployment

I think that these 3 issues are all more important than choosing a web UI framework.

I have been investing a fair amount of time learning Erlang this year and the ErlyWeb framework (that uses the high performance Yaws Erlang web server) looks very good for both interactive development and distributed deployment. For web applications that map well to Erlang, ErlyWeb allows Erlang to be the development language of choice, but again the important choice is programming language selection rather than web framework.

Labels: Erlang, Java, Lisp, Ruby, web applications