On Smalltalk

I’ve been working in Smallalk and Seaside for quite a while now, but something I haven’t quite gotten around to yet is trying to hook Squeak up to a database in a manner that I think could actually scale for a professional project. Now, I mean directly hook it up, so far, professionally, I’ve been using it against web services written in .Net against Microsoft SQL Server, which scales just fine, but leaves me still working in .Net, and I’d much rather work in pure Smalltalk.

Object Databases

I’ve tried several object databases, GOODS, Magma, and OmniBase, and while interesting experiences, I find them not quite acceptable for various reasons. OmniBase is file based, and has odd semantics that make hooking it up to multiple images and programming web apps against it difficult.

GOODS is very low level and bare bones, it works great, but you have to pre-index all your data, it has no query capabilities beyond what you provide in your object model, which can make performance quite horrible unless you know exactly what you’re doing and make very strict choices about how your data is stored. GOODS is also a one man show, so I’m not thrilled by the support I’d have available, were I trying to do something serious with it, though it works great for hobby and prototype programming.

Magma has queries, and is very similar to GOODS as far as ease of use goes but like GOODS, it’s a one man show, and I just wouldn’t feel comfortable doing anything truly serious on a one man show kind of database. This, for Squeak at least, seems to rule out object databases, for me anyway, though I hear Gemstone is going to support Seaside. I’m hopeful, for Gemstone is truly an enterprise ready object database, it’s just vaporware at this point, nothing production ready.

All of them seem rather slow when it comes to bulk inserts, and there are various solutions and workarounds depending on which version of Squeak you’re running, but a guy can only jump through so many hoops before he says “fuck it”. I’ve hit that point more than a few times when working with larger datasets and trying to do bulk inserts or queries.

Now, don’t get me wrong, Goods, Magma, and OmniBase are great products, and I’m sure have their uses, they’re just not something I’d throw up to my boss and say “hey, let’s use this for this big upcoming project”, because it’s hard enough throwing Squeak at them and having to support that decision over something like .Net which everyone already knows how to use, let alone taking away their familiar relational databases. I’d actually prefer something like Gemstone, time will tell if that preference pans out.

Relational Databases

So, on to relational databases. Squeak has ODBC support, but it’s single threaded and blocks the VM when querying, so while it works for demos and low traffic apps against pretty much any database, I wouldn’t try anything too big with it; it just can’t scale. Blocking the whole VM, every time you run a query, just leaves me feeling a bit dirty and not too proud of whatever I just wrote.

Squeak basically supports two popular relational databases that I know of, natively, MySQL and PostgreSQL. Now, I use MySql for this blog, so I have some experience managing it, and I’m just not a big fan, compared to Microsoft SQL Server, which I work with professionally daily, MySQL just sucks, but PostgreSQL is a different story, I’m quite impressed with the latest release, which looks and runs very nice on Windows servers and has a nice admin tool.

MySQL is IMHO not much better than Microsoft Access, it’s not an enterprise database. PostgreSQL, I think is much more comparable to SqlServer and Oracle and could be used for any size app. I have much more faith in its abilities and it has some cool features like table inheritance, which to an object bigot like myself, just makes me think relational databases aren’t totally void of innovation.

Now if I can just talk my DBA into giving up Sql Server, ummm… yea, not gonna happen, but I’ve got a side project coming up that’ll be totally green field development, no legacy database to worry about, hence my renewed interest in PostgreSQL, my new database of choice with Squeak.

Getting Started

So I installed the latest PostgreSQL, installed the PostgreSQL Client for Squeak from SqueakMap, then the GLORP port from SqueakMap, and gave it a shot.

I was immediately confronted with a nasty error that reminded me why I gave up last time I tried PostgreSQL. Something about the PostgreSQL driver’s state machine not being valid, luckily enough time had passed that a few minutes Googling turned up a simple answer this time, unlike the last.

PostgreSQL installs with MD5 connection encryption turned on, which Squeak doesn’t support out of the box. There are two fixes, either install the Cryptography package from SqueakMap, or turn encryption in PostgreSQL to “password” with a simple configuration change to the pg_hba.conf. I chose the latter, as its default install only accepts local connections anyway I’m not too concerned with encryption.

PostgreSQL fires up and runs without a problem, GLORP tests all run fine, so now I just have to learn GLORP and how to map my objects into PostgreSQL, but that, is going to have to be another story. I’m going to map the simple blog in Seaside into a PostgreSQL database to learn GLORP, and I’ll post that code once I figure it out. I’ve done a bit already, and so far, I’m quite happy with GLORP.

Tags: Databases, Programming, Seaside, Smalltalk, Sql

If you don’t have a sense of humor, stop reading now, go somewhere else, otherwise, continue reading this purposefully over the top rant. Keep in mind, I’m discussing VB, C#, and Java, not [insert your favorite language where these things don't apply].

On occasion, I’m forced to get into other peoples code, in Smalltalk, this is usually a pleasure and a chance to learn something. In other languages (VB, C#, and Java) where code isn’t of the general quality of the average Smalltalker, I continually run into the same things over and over again that drive me insane. Off the top of my head, here’s a few…

Inability To Grok Booleans

Using an if statement to evaluate a boolean, only to return a boolean…

if(someCondition)
    return true;
else return false;

Instead of…

return someCondition;

Comparing a boolean to true or false, as if it isn’t already one…

if(someCondition ==  true)
    doSomething();

Inability To Grok Assignment

I can’t tell you how many times I’ve seen this code…

ArrayList someItems = new ArrayList();
someItems = BuildSomeList();

when it’s so blindingly obvious that this is equivalent…

ArrayList someItems = BuildSomeList();

Seriously, I can’t imagine what mental defect makes people thing they have to create an ArrayList before the variable will allow an ArrayList to be assigned to it.

Ignorant Prefixing

From VB’ers, prefixing declared object variables with an “o”, as in oXml, to declare it an object, as if everything else somehow isn’t an object. In fact, Hungarian notation in general. Stop prefixing your damn code with type declarations. Booleans don’t need to start with b, strings don’t need to start with “str”, wake the hell up and join this decade people.

Single Exit Points

Constantly jumping through hoops and writing extra unnecessary code just to have a single return statement in a method…

string result = "";
if(someCondition)
    result = "foo";
else result = "bar";
return result;

Instead of…

if(someCondition)
    return "foo";
return "bar";

There’s not a shortage of return statements, use them liberally, exit early and often, it produces much cleaner and much less ambiguous code. Those old papers about structured programming that recommend this practice, no longer apply, we have garbage collection and your methods shouldn’t be that damn long to begin with.

1000 Line Methods

A method should be 7 to 10 lines of code, any longer than that and you start having to comment sections to explain them, which is what methods are for in the first place. There are exceptions, but they are exceedingly rare, on average, method should be short and simple and require little if any explanation beyond the method name itself. Seriously, I’m starting to think we should eliminate the scroll bar in code editors, when you hit the bottom, the computer should just start beeping at you like you’re an idiot for typing that much.

Declaring Variables At The Top Of A Method

In languages that allow it, you should always declare your variables and initialize them in the exact spot you want to use them. Don’t declare variables as if they’re somehow a limited resource and keep reusing the same one over and over in different sections of code. Declare your variables at the minimum level of scope necessary for them to be useful. If you only need a variable inside a loop, then declare it in the loop (optimizations aside), the code will be cleaner and more readable. This is another one of those mental quirks that seems to come from having a history in Basic. Stop it, please.

Too Many comments / Worthless Comments.

If I see more green than code, somethings wrong. This modern JavaDoc style stuff is ignorant, if you need to explain the code that much, it sucks, really. Comments should not replicate what the code says, they should augment what it can’t, things like “why” you made a design choice belong in comments. How, is for code, don’t repeat the how in the comments.

Don’t comment closing tags.

if(foo == bar){
    //bunch of code
    //bunch of code
    //bunch of code
    //bunch of code
    //bunch of code
    //bunch of code
    //bunch of code
    //bunch of code
    //bunch of code
    //bunch of code
    //bunch of code
    //bunch of code
    //bunch of code
} //end if(foo == bar)

this is beyond ignorant, you should be shot. If you can’t see the beginning of a tag on the same screen as the end of a tag, you need to learn how to factor. Break thing up into smaller methods. See 1000 line methods above, you have a disease, seek help.

Don’t comment sections of code to explain it, factor it into its own method and make the method name explain it. Then if necessary, comment the method explaining the “why”. Functions/Methods are the most basic building block of programs, they should be as small as bricks, not the size of entire freaking houses. You can’t compose solutions from a few giant functions, only from many many small ones. Giant functions aren’t reusable, maintainable, or acceptable, ever.

Still Using Error Codes

Stop using error codes and return values, use exceptions instead. To put it simply, use the Samurai Principle, a method either succeeds, or blows up with a suitable exception. Error codes are not acceptable in a modern language, it’s a dead technique.

Lack Of Consistency And Style

I might not like certain styles, but all too often I see code that lacks any style at all. Code should have a style, things like naming conventions, casing conventions, factoring conventions, something. Nothing bugs me more than code that clearly lacks any sort of style whatsoever. Don’t name thing haphazardly, sometimes uppercase, sometimes lowercase, sometimes abbreviated, sometimes long.

Pick a style for local variables, parameters, instance variables, method names, class names, package names, constructor names, and accessor names. If you haven’t actually thought out how you want to do these things, stop, take the time, it’ll allow you to think much less in the future and write code cleaner and faster. Go read Kent Beck’s Smalltalk Best Practice Patterns, steal his style until you develop your own. Pick a style, stick with it, don’t write schizophrenic random looking code, it’s maddening to people who read it later.

Still Using Switch Statements

Stop using them, period. There’s hardly any cases where polymorphism isn’t more appropriate. Use a class for each case, and break up these nightmare methods into separate pieces that can be worked on in isolation without fear of breaking the other cases. Your switch statements will be duplicated, eventually, so just start with classes and avoid the inevitable refactoring. There’s a reason Smalltalk has never had a case statement, think about it, HARD. If you think you can’t live without them, think harder, you’re wrong.

Obsessed With Simple Types

Though you can represent anything with a string, it’s ignorant to do so. Every program should not be expressed with only Strings, Chars, Booleans, Integers, Doubles, and Decimals. Build your own primitive types and use them as such. Things like Money, SocialSecurityNumber, Address, Contact, User, Name, Email, Url, Company, and OrderNumber can all be primitives as well.

Write your programs in the language of the domain, not in the language of existing primitive types that are native to your language. Stop passing around specially formated strings and validating them constantly, just stick them into a real object and use it instead. Pass around whole objects, not id’s to objects that you can look up later. Learn to override ToString/asString/to_string so that your object print well when you stick them into things like drop down lists and such.

Writing code with objects native to the domain in general, greatly reduces the amount of code necessary to express rules in that domain in large part because it greatly eliminates duplicate code.

XML Hell

Stop using XML as if it were an object model. Trees of objects are far superior to trees of strings loaded up into a generic DOM. Use a real object model, and then if you need XML, serialize the objects into XML for transport. Rarely should XML be built manually, use objects instead, they work better, are easier to force business rules onto, and are easily serialized into any format. XML is for configuration files and data transport, not for general purpose programming.

I’m sure there are more, but this post is getting a bit long. Anyone have any other major pet peeves they like to share?

Tags: General, Programming, Smalltalk

In my last post I built a simple blog, so I thought I’d do another short screencast showing how Squeakers package and share code. As with the first screencast, this one has no sound, it’s just video.

I create a package for the blog, save it to my package repository, which happens to be an ftp site on my server, but it could be a directory, an http repository, or quite a few others.

After saving the first version, I make a few changes and just bounce around Monticello a bit, to give you a general feeling of what we do and how we do it. I look at the latest version of Seaside, merge in the changes, change my mind, revert back to the old package, add a dependency to Seaside2 to my package, etc. Just watch it, you’ll get the general idea.

Once in the repository, packages are easily loaded into any image making sharing code trivial. I didn’t really show off everything Monticello can do, just the basics. Like most things in Smalltalk, you learn the most when you simply dive and start poking and prodding stuff to see what can be done, so if you want to see everything Monticello can do, you know where to start.

UPDATE: The screencast is now in Quicktime and only 7 megs thanks to a reader Manuel Blanc re-encoding it for me.

Tags: General, Programming, Seaside, Smalltalk

I’m always interested to see what someone new to Smalltalk has to say about it, always, but this takes the cake so far. I like what Dave had to say, but I’ll change it to “Languages of the Gods”, for Smalltalk is but one of a few. I personally give it up to both Smalltalk and Lisp, I think most other languages are derivatives of one of these two.

Languages like Smalltalk and Lisp (always got to give Lisp its props) are amplifiers. They make you more of whatever it is that you already are. If you’re a bad programmer, they’re going to make you worse, they’ll let you shoot your foot off in more interesting ways than you can imagine.

If you’re a great programmer, they’re going to make you that much greater, they’re going to let you become a God, and live entirely in a universe of your own abstractions. Anything you don’t like you can objectify or macro’fy and never have to think about it again.

These languages will never be mainstream, because the mainstream would never see the benefits they provide. The mainstream would kill themselves with such power. There’s a reason the mainstream likes manifest typing, procedural programming, and cut and paste methodologies, quite simply, it’s all they can handle.

Reflection is too deep in the bag of tricks for most mainstream programmers, let alone meta programming, or dynamically typed custom DSL’s in esoteric languages like Smalltalk and Lisp.

You have to appreciate beauty and elegance to appreciate Smalltalk and Lisp, and quite frankly, those just aren’t mainstream values. I think Dave’s right, the “Languages of the Gods” will never be mainstream, but you know, that’s not really such a bad thing. As long as the communities are large enough to support the work I do, I really don’t care about what the bandwagon is up to.

Tags: Lisp, Programming, Smalltalk