Cincom Smalltalk Stuff

There seems to be a great deal of fun going on in the Java community over JDO, EJB, and the like. JDO is an OO database influenced spec that's been moving in the direction of handling O/R persitence as well. I always had some issues with the way they approached things, but they were in the realm of legitimate technical differences. But it was always EJB that had the real mindshare, even though technically it was a disaster area. Now it appears that Oracle (i.e. TOPLink) and an open source product called Hibernate with a similar sort of architecture are abandoning efforts to work with JDO and instead have managed to influence the direction of EJB 3.0 towards a much lighter-weight persistence mechanism.

It's all very interesting, looking in from the outside, and there's lots of entertaining name-calling. Most of what I saw was in a thread on theserverside.com, but alas that thread seems to have expired or been purged while I was off sick.

Anyway, I think things will get interesting in that world. I don't know why Oracle and Hibernate chose to go with EJB. I know that there were some tensions with the JDO approach, but tensions doesn't begin to describe the problems with EJB. On the other hand, EJB's persistence has by now failed spectacularly enough that the committee seems willing to admit the previous two approaches were a bad idea and do a complete rewrite listening to someone who knows something. So perhaps they'll come out with something reasonable (but of course, also backward compatible with the previous two). Given my expriences with that group, I'm doubtful. Fortunately, it doesn't really affect me one way or the other.

Code speaks louder than words, so having a bit of time free late on a Saturday afternoon I implemented the (most basic imaginable) version of the repository crawler and google search of the public repository that I mentioned earlier. I've put it up here. The google search part doesn't really work yet, presumably because we have to wait for google to actually index those pages. But hey, it's free and easy to do.

The only restriction I could figure out for google was to restrict it to a particular domain. I really wanted to restrict it to just those pages, so I put in a PackageDescription as a default entry in the search field, figuring that was a fairly unusual word that occurs on all of these pages, so it ought to serve as a restriction.

It would be easy to make the HTML nicer (it's really, really, really basic), and to add in additional interesting information (e.g. when it was last published, by whom, possibly some of the interesting package properties). The code is published in StoreForGlorp, as the RepositoryCrawler class (all 15 methods of it).

This is all quite reminiscent of SmalltalkDoc, which Mark Roberts and Rich Demers have been working on, although that's more targeted at being a sort of PythonDoc equivalent for looking up API's rather than a repository search mechanism. Having a very limited amount of information there to search can actually be a plus for that.

Eric Winger, for his very first blog entry, talks about possible utilities for the public Store repository.

At one point he says "it's just a chunk of unorganized files". No, it's not. It's a bunch of records in a database, which is an entirely different thing, and much easier to manipulate, at least in theory.

Among the possible improvements, he mentions

• A description field for packages/bundles. Well, there already is one, it's called the comment. The biggest problem with utilities that use it is that the public store uses postgresql, and the VW postgresql driver stores long strings by base 64 encoding them. This makes it rather difficult to do queries against them. I've talked about this with Bruce Badger, and he agrees it was a mistake to do it that way, but changing it, unless done very cleverly, would break older clients, so it's a big deal. One possibly easier way to approach this would be to have something crawl the database (like SmalltalkDoc), write out the comments, and then use the google api to search amongst the comments. This would also have the benefit of giving you a powerful search without having to try and discover much structure in the comments. Generating the pages would be easy. I don't know what's involved in hooking to google or the like.

• "Change the Package/Bundle browser to allow packages that are inside other bundles to not be displayed." That's doable, although it does slow down the initial query against a large database some (e.g. to get the otherwise unfiltered list from the public repository it's about 10s instead of 1s. Against the internal Cincom DB it's about 13s instead of 5s). It's also not always quite what you want, because if anyone ever puts something inside a bundle then it will remove that thing from the filtered list forever. But it certainly helps. If you've used the StoreForGlorpReplication stuff coming in 7.2.1 you'll notice that's there as a checkbox. It would be relatively simple for anyone good at GUI's to make something more like a published items list/repository browser using the same mechanisms.

• A couple of comments about splitting the repository based on date updated, type of package, etc. I don't think that's a good idea. Better to be able to filter on fairly arbitrary criteria

After a drought, I seem to have stumbled into a high-blogging period.

One of the things people use as a reason not to use Smalltalk is that they "can't find developers". I find it odd that we can simultaneously have developers who can't find Smalltalk jobs and Smalltalk jobs that can't find developers, but even leaving this aside, I've never seen this as a huge issue. My point of view is that the hard skill is programming, and if someone is actually a good programmer they can pick up Smalltalk fairly easily. People talk about these very long learning curves, but my experience from projects I've been on is that good people can pick things up much faster than you'd expect.

Bob Lewis of InfoWorld agrees with me here. The relevant quote is right at the end...

Which is the same thing I tell hiring managers who insist on experience with a specific programming language: A competent programmer can learn a new language quickly. An incompetent programmer who knows a language will remain incompetent forever.

A few times lately I've seen Alan Kay's maxim that "Simple things should be simple. Complex things should be possible" quoted. I'm actually not sure I agree with that, or at least I don't think it goes far enough.

Now, I should say that it's a start, and it's a real shame that so few products can live up to it. For example, Gosling apparently admitted this about J2EE recently . The problem is that if you follow this maxim with what I'll call the "wrong attitude" you can end up with "Microsoft usability". What I mean by that is that the underlying product is hideously complicated, but you have pretty bits to handle the really simple cases. So simple things, at least a few of them, are simple because you have wizards to generate them for you. Anything beyond that counts as complex. It's possible, but it sure won't be easy.

Part of the problem is the discontinuity between the simple and the complex. One of the nice things in Smalltalk is that the barriers in "dropping down a level" are relatively small. Simple things are simple, but simple things are also incremental steps towards complex things. Another way of putting this is that magic should be avoided. If the underlying system can do something, the user ought to be able to do it, as easily as possible.

I certainly wouldn't claim that VisualWorks, or Smalltalk in general is somehow the ultimate in this regard. We have lots of excessively complicated or just bad. One thing that helps Smalltalk though is the aesthetic of simplicity. It's by no means universal, but code being complicated is considered a valid criticism and there's just that much more pressure to simplify.

And in the end we get that much closer to the ultimate goal, which is after all the point of software. "Simple things should be simple. Complex things should also be simple"

Some people were working on updating the Glorp Smalltalk/X port last weekend, and had a request for the ability to file out real old-style chunk format from VisualWorks. I've had people request that before. Fortunately, that ability does exist, you just need to load the FileOut30 parcel, which clearly isn't well enough advertised. In addition, that parcel adds the ability to read and write "ENVY" chunk format for both VW/ENVY and VisualAge, and to read and write Dolphin fileouts. In both those cases it should do a reasonable job of maintaining application/package structure and method categories, although when loading methods with more than one category it will arbitrarily pick the first one.

A good part of that was actually written for, or at least because of, Glorp. At Camp Smalltalk in Essen it seemed like we every person was working in a different dialect and we spent far too much time translating code back and forth. So I extended the FileOut30 goodie to be able to handle these other formats, and got it pushed into the release. This is also the basis for producing Glorp ports. The GlorpUtilities package has a very simple UI that knows enough to file out the Glorp code for various different dialects into different directories. It's crude, but it works. (For VA there's an additional script that you can use to file in, version with matching version numbers and export to a .DAT).

My talk for Smalltalk Solutions was a tutorial called Using Glorp. In contrast to some of the previous talks I've done, this one concentrates more on how to use Glorp and less on how it works internally or the rationale for design decisions. It was tricky, as you might expect from something with hands-on exercises that requires everyone to have a database. I was hoping we might be able to use wireless access and give people access to postgresql running on my laptop, but that didn't seem to work out.

In the end, enough people were able to get going using Access on the Windows machines. That had a few entertaining aspects. I had to hand-wave a bit - "Let us assume that a real database would not cause an error if you did a read before starting the transaction, and just do it afterwards".

I also had to go fairly quickly through some of the later material. I wasn't sure how fast things would move, so I had some extras, and also people asked a lot of fairly advanced questions in some of the early sections. So the ordering was interesting, but I was pretty happy with the amount we got covered.

The slides are available here and the exercises are here . I note that the code in the exercises is VW-specific, it includes a (very minimal) GUI. The slides and such are PDF.