ronin

Gilad Bracha: So why not get rid of constructors and have a class declaration create a factory object instead? Well, Smalltalk did just that a generation ago. Every time you define a class, you define the factory object for its instances. I won’t explain the Smalltalk metaclass hierarchy here. Suffice to say that it is a thing of beauty, resolving a potential infinite regress with an elegant circularity.

This is a good article, and I’ve certainly hit the problems talked about with both Smalltalk and Java. I’m looking forward to some examples…

Found this blog entry by Rick DeNatale about improving Ruby, I pretty much agree with everything said there.

I was going to add my own 2 cents but being the careful person I am(not) I actually went and read the original article and a couple of the different entries to the competition.

I found that this article by Jamie Macey pretty much says everything I was going too. Simplify the syntax, simplify the libraries, add unicode.

If there was one thing further I would say it would be related to what Avi Bryant has said before. Rewrite all of the Ruby libraries in Ruby, and then make Ruby fast enough to run them. IMO this is a precursor to making Ruby run on more platforms, much like Squeak has a small amount of C to bootstrap it and then the rest is all Smalltalk.

Btw, the Smalltalk class, metaclass, object relationships that Rick DeNatale was talking about in his post are(I think) encapsulated in the diagram below(which I lifted from the Bluebook).

Elliotte Rusty Harold: Type Inference: Another Bad Idea for Java 7

Type inference actually makes some sense in languages like JavaScript and PHP that are built around this, and had this feature from day 1. It makes no sense in a language like Java that’s built around the opposite. It makes Java look weakly typed, but it isn’t. In fact, if anything this is now more strongly typed…

Good analysis of a bad idea. I really dislike the idea of adding more and more language features that require new syntax or something like described in the above article. It just makes it confusing. Either create a new Java which has all the old crap tidied up, or go ahead and write a new language that can run on a JVM which has all the features and language constructs you need.

This is why I really like Smalltalk. There are very few reserved words, and the language is highly extensible so you can go ahead and implement new ideas without breaking anything old, requiring arcane syntax, or making the language less usable. Ruby struggles in this area also due to all the different ways of doing something.

Simplicity has a lot going for it.

Avi Bryant on implementing all of Ruby in Ruby:

To me, one thing that’s wonderful about both Smalltalk and Java is that all of their libraries, including basic data structures like lists and hashtables, are implemented in, respectively, Smalltalk and Java.

When Ruby is fast enough to implement most of it’s standard library in Ruby then it might lose the scripting label which seems to be hanging around it’s neck. There seem to be a few other efforts going on to implement the language, incluing JRuby, and they can only contribute to making Ruby better.

Also efforts like this wiki are a good idea as well.

Blaine Buxton in Java VM Puts Shackles On Development Tools

…in 2007 with dynamic languages finally getting recognition that few people are screaming for the capabilities of a Smalltalk VM. The productivity of Smalltalk owes not only to its dynamic nature, but to its always running and lively IDE.

Developers coming from traditional environments just don’t have the exposure to that way of working. It probably never crosses their mind that an environment that is “alive” is more productive. The only way a Smalltalk like environment would happen for another language is if it is written by somebody coming from Smalltalk and wanting the same tools.

I for one would be all for a Ruby IDE that was essentially an image.

Steven Colebourne: Configuration in Java - It sure beats XML!

Is the Java community slowly remembering what’s good about Java? I’m talking about static typing.

I can’t count the number of times I’ve had this rant. The article is mostly inspired by being sick of editing XMl files which can become tiresome and error prone when they start getting large or numerous.

There are a few caveats that need to be made when thinking about configuration, in no particular order:

• When the configuration is about setting up how an application works, and it doesn’t change per environment then use the language you are writing your application in. If the language isn’t good enough to handle setting up some configuration, then maybe your using the wrong language? It’s a good idea to use a Fluent interface when thinking about configuration languages, in fact it’s good to think about them all the time.
• If a property can change per deployed environment then it’s better to externalise that from the code. As a commenter on Steven’s post pointed out, having to explode an EAR/WAR to change where some log files go isn’t very cool for somebody deploying a third party app. Often it pays to tokenise config files and then have an automated detokenisation process which provides the actual config values per environment. Deployers may not have the skills to go diving into a piece of code to change it, and it would be a PITA for them if they had too. Property files work well for them.
• Think hard about what values are really going to change, get this wrong and configuration can become a nightmare. Try and go with convention over configuration. Define your deployment environment and be firm about not adding extra configuration because “you might need to change this value in the future but we don’t really know”. If it’s going to change in the future then change it in the future. Obviously this doesn’t apply for things that will always change, e.g. IP Addresses.

As an aside to all this, I’ve recently gone through the experience of moving all of my current project’s configuration from xml/property files into a Configuration database. Now when an application starts up it registers itself with the configuration service, if it doesn’t have any configuration it will be given a copy of a default set of values. We have an admin console where users with appropriate privileges can edit and add new values, or reset values back to defaults and so on. This way we have zero(almost) configuration packaged with an application. Applications identify themselves, get given a configuration, and off they go without any help from us. If a new team comes along and needs to use one of our apps they just take the application and deploy it as is. We can see it in the admin console when it gets started and then edit, or give the appropriate priveleges to one of their administrators so they can, the config that they need.

Looking up the configuration is done through a common JNDI name which then points the application to the correct place, this can be overriden if necessary which is why the “almost zero” configuration per app, it’s totally optional and it works by convention if it can.

The configuration is also cached by a client framework so updated values will be available when the application next reads them. This is useful for log levels and the like where you might want to up the priority to debug to do some debugging for a while and then set it back to error when your done.

We created a basic taxonomy of Tags that an application can use to identify itself, these are inserted into the application during the build process. Examples of tags are:

• The application name
• Which type of appserver the application is going to run in

There are a few more specific to our domain, but you probably get the idea. In the admin console we can search for different Tags which allows us to find all instances of an application that are running. This will include developers machines, integration environments, test environments, and third party environments we have no control over.

Testing was something we didn’t really consider upfront, which was a mistake. It was soon obvious that we needed to be able to bootstrap a configuration into a Unit Test(The config framework itself did have unit tests). Luckily the interface wasn’t too bad and with a simple mock JNDI environment we were up and running. It adds some overhead to the setup of a test fixture but isn’t all that bad.

Another benefit to this approach was when an application registered itself it provided it’s manifest file as part of the identification process. We now have all the version information for each application running in all our environments. This becomes highly valuable when supporting deployments in third party environments which we have no access too.

Us: What version are you running?

Them: Not sure, how do I find out?

Us: Go to the filesystem, find the deployed application, open the manifest, tell us what value attribute X has.

Them: How do I log onto Unix?

Us: Err…

Now we just look in the admin console, find out which version they have and get started looking at the problem. Not having access to an environment can be a pain when trying to find out which version and configuration an application is using. Now we just don’t have that problem.

It’s no silver bullet that’s for sure, but it does ease the pain of having to configure for many many difference environments.

James Shell: Seaside, Rails, Helpers…

It’s not XML, YAML, An Array or list. It doesn’t get translated into any structure like that.

August 81 Byte article entitled “Design Principles behind Smalltalk”:

The purpose of the Smalltalk project is to provide computer support for the creative spirit in everyone.

Sounds like a good premise for a language. Link to full text.