One of the things I hated about Java, besides how often I seemed to have an int when I needed an Integer or vice versa, was how hard it was (how much keyboard typing it took) to do something simple like instantiate an object.

FactoryConfigurator factoryConfigurator = (FactoryConfigurator) ConfigurationEnvironment.getFactoryConfigurator;
factoryConfigurator.configure(configurationObject);
DesiredObjectFactory desiredObjectFactory = factoryConfigurator.getDesiredObjectFactory;
DesiredObject desiredObject = (DesiredObject)factoryConfigurator.getInstance();

But in a way, this isn’t Java’s fault. This is a problem caused by someone who decided that whether or not you needed a factory, or a configurable factory, or some system-wide abstraction for resources defining configuration, those were exactly what you were getting. That’s the problem. Looking back, why couldn’t I just type DesiredObject.new(); if that’s all I wanted? All the crap above could get implemented in some other class method if I really wanted it.

When I wasted a year of my life trying to hack a J2EE application together, I cursed the way all the application frameworks were desined to so that everything had to be typed three times, twice in code and once again in XML, and how even when I didn’t have a layer for something, I had to create a phantom layer that did nothing but relay messages across the void. But again, is this horrible verbosity Java’s fault, or is it a failure of imagination on the part of the framework designers?

I have to say, though, that I’m not going back to Java any time soon.

But I do see a better way to do things that I’ve tried and failed in the past…. I knew I was struggling with things that were over my head– and SICP is the only resource I’ve yet found that can actually train you to tackle “hard” stuff. It is packed with terminology and techniques that help you break apart difficult things into beautiful solutions.

Since I’m working in Smalltalk I’m also wondering “What classes should I create?” According to Message-Oriented Programming, what Alan Kay would’ve preferred to call it instead of OOP, each class will basically have its own language semantics via. messages. It can use the same language, but it may interpret it differently.

Something embedded languages emphasize is knowledge of the problem domain. From looking at Smalltalk code I noticed it’s sometimes hard for me to understand what’s going on because I’m not familiar with the domain perspective that the original developer was coming from. I’d have to steep myself in the domain to understand what they were talking about. This is probably no different than looking at just traditional code. Even though the terminology would be pretty familiar (the language itself, like C, C++, etc.) I wouldn’t understand what was going on unless I understood the domain, anyway.