A.I.

A friend of mine, also a long time Lisp hacker, stated the opinion about 15 years ago that object oriented might be the "last great programming paradigm". A good thought, but object representation is just one way to think about and manipulate data. I admit that my favorite style of programming is with an object oriented language with transparent object relational mapping (e.g., Java with Prevayler, Ruby with ActiveRecord, or Lisp with something like AllegroCache).

The ability to write programs (preferably quickly :-) allows us to experiment with data representations. The point I am making here is that different software tools can not only help solve different problems with different levels of effort, but the tools that we choose inform us and change the way we think.

Sometimes a relational data model just works best, both for efficient access (not letting an object relational mapping system build an entire object in memory when you are only interested in a few columns in a table) or for thinking about and browsing data.

When there are too many attributes characterizing data that you need to explore or use, then faceted browsing helps a lot: pick the most important attribute, then the second, etc., eliminating large parts of a data space.

For some problems graphs are the best data representation and languages like Lisp and Prolog that allow list data structures to be cut up and put back together are most effective.

Pardon me for playing with the title of Edsger Dijkstra's famous paper, but as a Java developer I am starting to believe that arrays should be seldom used, given Java generics and the revised collection classes. I started thinking about this while reading someone else's code and noticing some artificial looking conversions between arrays and collections. Then for fun, I did some measurement and noticed over 15% of processing time was spent in toArray() methods.

The big cost in IT is usually in development and maintenance, not in deployment costs. Most projects are small, not Amazon size deployments so I believe that unless you are sure that you are building a very large scale system, it is best to optimize development to reduce costs for small and medium size systems. Smaller code size means smaller costs. Java programs should be as short and concise as possible and generics and use of collections helps a lot. Sometimes when I read the source for Java programs it looks like the authors were paid by line of code :-)

I am using Franz's AllegroGraph for two proof of concept projects for a customer: one using the Java APIs (free version) and one using the Lisp version that is unlimited in the size of stored data. RDF storage and querying is not easy technology to use (at least for me) but looks very promising.

The thing that I find interesting about using AllegroGraph is that you are dealing with disk-based persistent data, but not dealing with objects - not dealing with object relational mapping, etc. Instead, you work with graph data structures that are stored on disk, with parts cached in memory. Interesting stuff.

Still, dealing with RDF is not optimal, compared to dealing with graphs in memory. As an example: I used to work a lot with Rete networks using Lisp (hacking Charles Forgy's Lisp code) and dealing with graph data structures built up with Lisp lists, cons, etc. is just easier to do. In memory graphs, semantic networks, etc. are just easier for me to wrap my thoughts around. However, approaches like AllegroGraph have the advantage of scalability.

Check it out on DevX.

In this article I write about why a Java developer might want to also use Ruby and I cover a few cool Ruby features.

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.