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

I wrote about Sun's Lively Kernel web browser based programming environment last month and watched this excellent Lively Kernel talk by Dan Ingalls this morning. I especially liked one point that he made: with the right architectural decisions systems can be fairly simple and still be general.

The demonstration on the video is both impressive and serves as documentation if you want to experiment with the Lively Kernel yourself. As it is, the Lively Kernel is a good prototype but if the performance is improved a bit and the programming environment and IDE (which is like Squeak Smalltalk, only for Javascript) continues to improve, then Lively Kernel is on my (personal) radar for something that I will use in the future.

I remember getting a Xerox 1108 Lisp Machine in 1982 and I also wanted the optional Smalltalk environment which was not in the budget. However, a sales engineer at Xerox did let me use Smalltalk for a month on a trial basis. It is amusing to be able to get a smalltalk like programming environment like Lively Kernel for free that is hosted in a web browser. Something about Moore's Law and also about free software projects...

Off course, by far the best free Smalltalk experience is Squeak but Lively Kernel is still very cool, if only for its possible future use of quickly writing web interfaces using existing web services, etc.

Labels: Javascript, Smalltalk

Good news: Apple is supporting Ruby 1.9 using the Objective C runtime. This mainly to support building native Mac applications but this will eventually be good for other more general purpose Ruby development on Macs. Very cool since both Objective C and Ruby have their roots in Smalltalk.

Labels: Ruby, Smalltalk

I am sure that most developers who have tried DabbleDB have experimented with the web framework Seaside that DabbleDB is built with. I have worked through Seaside tutorials several times in the last couple of years and last month I wanted to deploy a tiny Seaside based experiment to one of my leased Linux servers. It took a short while to get it deployed because I didn't get it right the first time, so here are the simple steps that I eventually used:

• Get your Seaside application running interactively in Squeak; make sure the WAKom service is running on a desired port number with:
  WAKom startOn: 9090
  and save image and quit Squeak. Do not stop WAKom before saving your image and quitting Squeak.
• ZIP up your image and source changes:
  zip -9 -r seaside_running_image.zip Squeak3.9-final-7067.*
  copy to your Linux server, and unzip in your Linux Squeak directory.
• Run Squeak in headless mode:
  nohup squeak -headless Squeak3.9-final-7067.image &
  

OK, maybe that was more than 3 steps. If you should ever need to do a scalable deployment Ramon Leon's directions look good but I have not tried them.

Labels: Seaside, Smalltalk, Squeak

Compact languages and libraries have the advantage that one person can understand most of an implementation. Two of the most elegant programming languages, Squeak Smalltalk and Ruby, have sufficiently compact implementations to understand, given some effort. And this effort is worthwhile - a lesson I learned in the 1970s when I worked as a systems programmer: I kept listings of key parts of the PrimeOS (Multics based) operating system and for the Lisp and FORTRAN implementations handy at home and in my office. Time spent reading through the code paid huge dividends whenever I had to do any systems level programming. Reading the code helps create a mental map of whatever software that you are using.

The implementation of Ruby and the standard Ruby libraries is compact, basically divided into the C implementation of Ruby itself and the Ruby code for the standard libraries. If you are going to be working much with Ruby then consider creating at least a project (using Eclipse, IntelliJ, TextMate, etc.) with the library source code. Good for library reference, looking up APIs, and for just reading code.

I would make the same suggestion to developers who use Squeak Smalltalk (or other implementations): you have the source code to the standard libraries: read it!

I also enjoy and am very productive using the Java and Common Lisp frameworks, but these languages with their standard libraries are so huge that I would personally never attempt to dive in and understand their implementations. Not having a mental road map of the implementations of Common Lisp and Java reduces the effectiveness of these platforms.

Labels: Ruby, Smalltalk

Although most of my work is in AI development and general web services, I greatly enjoy writing user interfaces - this interest started in 1982 when SAIC bought me a Xerox 1108 Lisp Machine - the windowing system and general development tools were so good that they make most recent software development environments look weak.

Google Web Toolkit (GWT) and Squeak Smalltalk based Seaside are pleasant exceptions. Just like using Rails, GWT and Seaside provide that pleasant "everything just works" experience and great interactive development environments.

Last night I used GWT and IntelliJ to prototype some web UI ideas. If you have not tried working with the GWT Development Shell, give it a try: changes to client side resources (style sheets and HTML) and to Java client side source code (automatically compiled to Javascript during development) are immediately reflected in the test web app. I don't have any current tasks dealing with Java web applications right now, but the next time I do, GWT looks like a very good framework choice.

Seaside also supports the same fluid interactive development style: changes made in a Squeak Smalltalk source browser are immediately reflected in running web application. Seaside uses continuations to provide a more linear programming model. Blocks of code are used instead of URLs; inside a code block, you can call another code block - after a "return", you continue where you left off in the first code block. There is a performance penalty for using continuations, but it looks straight forward to run multiple Squeak processes behind Apache so it look like Seaside scales the same way that Rails scales. DabbleDB is written using Seaside - a great proof of concept for scaling.

Labels: Java, Smalltalk

The Subtext programming system has been getting some buzz, and I think that this is worth while if it makes us think about the disconnect between thinking about problems and writing software to solve these problems.

While state of the art IDEs like IntelliJ for Java and VisualStudio for .Net languages provide a comfortable working environment, I must say that both Java and the .Net languages are poor choices for many programming tasks.

Scripting languages like Ruby and Python help this thinking vs. programming disconnect in one important way: for small programming tasks, very short programs are sufficient and we can keep track of both problem task thinking and programming.

What about large projects? There are two good alternatives in programming languages: Common Lisp and Smalltalk:

Common Lisp lends itself really well to growing your own application specific language (using macros if you like, and functions). Once you build up an application specific language, a lot of the complexity of even complex programs goes away. Even more importantly, domain specific languages should help close the gap between thinking about problem solutions and programming these solutions.

The downside of Common Lisp is that while Emacs based IDEs are effective environments, even with add on code browsers, I find exploring large Common Lisp software projects to be tedious.

Smalltalk implementations generally have great code browsers because the simplicity and regularity of the language make it easier to automatically process the structure and semantics of code. Smalltalk blocks and closures, like in Ruby, allow many concise coding tricks - shorter programs are easier to understand and modify.

Labels: IT, knowledge management, Lisp, Smalltalk

For the last year most of my work has been using dynamic programming languages (Ruby and Common Lisp). I have written about this before but given that programmers are properly trained/educated, dynamic languages simply are more efficient when measured against programmer time. I think that the reason is fairly simple: dynamic programming, meta object protocol, Ruby's missing method, etc. all make it possible to solve some difficult problems with relatively few lines of code.

I have made a good living using the Java platform (starting with Java 1.0 beta) but I think that it is time to move on. Sure, I am still likely to take on interesting work even if it has to be done in Java, but I think that both Java and the .Net platform languages missed the boat on programmer productivity.

I have a few comments on Ruby vs. Common Lisp also: the beauty of Ruby is that it is a simple language to learn and to master. It is difficult to find programmers who are willing to make the effort to master Common Lisp and CLOS. Too bad, but that is the way it is. Personally, I still like Common Lisp a lot because I have already invested decades (part time) learning Lisp and Common Lisp blows Ruby away performance wise. BTW, my positive comments on Ruby and Common Lisp largely also apply to Smalltalk.

Labels: Lisp, Ruby, Smalltalk