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

I have been working on and off for 16 months on a book about Semantic Web (or Linked Data) application programming using the AllegroGraph product. I have decided to substantially increase the scope of this applications/tutorial style book to also include support for Sesame. The figure on the left shows the software architecture road map for the book using JVM languages.

I am splitting the book into two volumes, and using Latex makes this really easy to share small amounts of common material so both books stand on their own. Latex also makes it easy to combine both books into one all-inclusive book, eliminating the duplicated parts. The two volumes are:

• Volume I: will cover the use of both AllegroGraph and Sesame using JVM languages: Java, Scala, JRuby, and Clojure. I am working on a common wrapper written in Java that supplies my own (rather simple) API to both AllegroGraph and Sesame. My wrapper implements Sesame support for geolocation and free text indexing and search so the wrapper is adequate to run all of the book examples using either AllegroGraph or Sesame "back ends."
• Volume II: will cover only AllegroGraph using both the embedded and client Lisp APIs.

Both AllegroGraph and Sesame are great development tools, but fill different needs. On projects that can support a several thousand dollar a year per server license fee, I would choose Common Lisp + AllegroGraph for development. AllegroGraph is very scalable and the Lisp APIs are really nice to work with. For Java (or other JVM languages) applications, I would still choose AllegroGraph for the scalability and support if a project can support the license costs. The good thing is that for most small to medium size projects, the free version of AllegroGraph or the open source Sesame project both are good choices, so as a developer you have some real flexibility. There are also other good RDF data store platforms like Jena, Joseki, Kowari, Redland, 4store, Swi-Prolog Semantic Web library, Talis, Virtuoso, etc. but I have relatively little (or in some cases no) experience with these. I use AllegroGraph and Sesame so that is what I write about.

Labels: Clojure, Java, JRuby, Latex, Lisp, RDF, Scala, 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 have been playing with Scala for a while - playing is the correct word to use since I am waiting to see how popular the language becomes. I think that Scala will possibly end up being 'the better Java' for the JVM, but for my business I prefer not learning and using another language that is not main stream (my almost 25 years of using Lisp professionally has sometimes been a hassle because of the unavailability of other skilled Lisp developers and a smaller ecosystem, and I don't want to devote a lot of time to mastering another language that may end up being "on the fringe").

That said, Scala is a very nice language that has two non-language things going for it: very efficient runtime performance with OK memory use and that it runs on the JVM. Scala looks to be a good language for AI development and its interactive console adds some of the advantages of interactive bottom up development - a style I like to use when working in Lisp, Ruby, or Python.

Until this morning I have only read about the Scala Lift web framework, but after reading Vivek Pandey's blog about running Lift I gave it a try this morning. The maven setup and default web application construction was all very smooth, and the generated code was interesting to read. I also like the way Scala unit tests work and the debug modes supporting both an interactive Scala console and running with an embedded jetty web server. Everything works very well together and the entire system has a polished feel to it.

Labels: Scala, web applications