Gilad Bracha has announced that Newspeak will be released under an open source license (Apache). It should be interesting to learn more at StS 2008.

Technorati Tags: smalltalk

Sounds like Gemstone is building a Ruby environment? InfoQ has the scoop.

Technorati Tags: ruby, gemstone, smalltalk

I was driving to my daughter's school, listening to my iPod, set to shuffle my music, and "Code Monkey" came up. Imagine my surprise when I had a sudden epiphany on a longstanding bug in the blog server.

I had noticed that whenever I pushed a new post up, if I wanted the category specific feed to update, I needed to manually force that to happen. This was irritating, but I hadn't figured out why it was happening - the order (update the cache, then update the feed) looked right. What I hadn't done was delve into the process of cache updating. Here's what that looked like:

	...

	self categoryCache add: category.
	[self cache cacheForCategorySearch: aBlog] 
		forkAt: Processor userBackgroundPriority.

	...

You might see the problem - the cache update code is forked, and at a lower priority than the active thread. Given the Smalltalk Process Model's operation, that thread is guaranteed to not run before the main thread does - which meant that the category specific feed was getting dropped before the cache got updated. I just made sure that the feed gets dropped within that fork, after the cache update - which solves the problem.

So what does it say about me that I came up with this during that song :)

Technorati Tags: smalltalk

Google has announced their application platform, and their hook to get you started is that it's free up to a certain level of usage - that usage level is restricted for the beta period (first 10,000 signups). Here's the detail on that:

Google's App Engine initially will have limits of 500MB of storage, 10GB of daily data transfer bandwidth, and 200 million daily cycles of processor use. That should be enough to power a Web site with about 5 million page views per month, Koomen said.

Once they get out of beta, that usage level will be free, with anything beyond that charged on a pay as you go basis. The interesting thing is this: the development environment for it is Python. So much for Sun's theory about what you need to scale in the Enterprise.

That provides an interesting counterpoint to what Amazon is offering though. With Google, small scale use is free, but your toolset is limited. With Amazon, you pay as you go from the start (not a lot), but you can use whatever tools you want.

Bottom line, developers just got more choices for building out web apps.

Technorati Tags: cloud computing

I love those Java guys at Sun - they're kind of cute when they try to talk smack:

Java also enjoys a 10-times performance advantage over interpreted scripting languages like JavaScript, Perl and Python, he said. "The scripting languages aren't JIT-ted yet," he said.

Scripting languages are ideal for smaller programs but Java is the choice for larger programs, he said. "As your program grows in size, the lack of strong typing basically kills your ability to handle a very large program and so you don't find the million-line Perl program," he said. One-million-line Java programs are plentiful, Click said. Strong typing refers to the capability of knowing the type of memory objects.

First, most million line programs are a mistake. The fact that Java has lots of them says nothing good about the language; the fact that it takes that much code to achieve something useful says something else entirely. Second, most of the large applications they are talking about are database bound - meaning that the raw execution speed of the code is mostly irrelevant.

Take a live example of a big app written in one of the languages these guys are throwing rocks at - Twitter. Everyone knows they had initial scaling problems, but those have gone away - and the app is still written in Ruby. Gee, why do you suppose that is? Could it be that they went and tuned the database layer, and got their load balancing situation under control? I Rather suspect that a Twitter on J2EE wouldn't exist yet, because some of the million lines of code required would still be being written.

Here's another small clue for those guys - most of the containers floating around the planet are shipped with Smalltalk code. A large proportion (possibly a majority) of the chips being built are in factories controlled in large measure by Smalltalk systems. A ton of the more profitable trading on Wall Street, by one of the most prestigious (and successful) firms there is done in Smalltalk. The firms that haven't been able to catch them? Yeah, those guys use J2EE, mores the pity.

Micro-benchmarks are pretty irrelevant, and you would think Sun's big honchos would know that. However, when you realize that J2EE is a huge pile of steaming manure weighing down the people unfortunate enough to be using it, I guess it makes sense to shout "but our arithmetic is really fast!".

Technorati Tags: java, j2ee, smalltalk, scripting languages, ruby

As it happens, I ran across a situation requiring a "monkey patch" just this morning. A BottomFeeder user reported an issue reading this feed:

http://community.devexpress.com/blogs/alansplace/rss.aspx

I fired up an image, and tried this code, to make sure that the problem wasn't some silly thing I was doing in my own code:

HttpClient new get: 'http://community.devexpress.com/blogs/alansplace/rss.aspx'

Sure enough, there was a problem in the base network code in the system - something about parsing headers. Now, the correct answer here would be to go to the root of the problem, figure out the parsing error, and fix that. I could also just decide this - in the world of feed readers, cookies simply aren't that critical. So, I overrode the inherited method and did this (and yes, it's a hack):

parse: rfc822Stream
"Override to handle errors"

	self source: rfc822Stream asStream.
	value := [self doParse: rfc822Stream]
		on: Error
		do: [:ex | nil].

However, from a patching perspective, even a full fix by me would still be a patch on library code. Either way, I have to deliver a work-around to deployed clients. So what would the purist suggest in this case? Tell people in the field that they have to wait? Derive a secondary network library in order to avoid patching system code? My solution seems more pragmatic, especially since it's versioned in its own package, and - like other such patches in the past - will disappear as soon as a proper update comes from Cincom engineering.

Technorati Tags: code overrides, smalltalk, dynamic language, monkey patching

Gilad Bracha on extending system code:

One way of achieving this would be to actually go and add the necessary methods to the class Symbol, so that symbols could behave like parsers. I know otherwise intelligent people who are prepared to argue for this approach. As I said, Smalltalkers would call these additions extension methods, but I find the more informal term monkey patching conveys a better intuition.

Typically, one wants to deliver a set of such methods as a unit, to be installed when a certain class or library gets loaded. So these changes are often provided as a patch that is applied dynamically. Not a problem in Smalltalk or Ruby or Python (though I gathered from the Pythoners in Krakow that they, to their credit, frown on the practice).

Apparently, there is a need to explain why monkey patching is a really bad idea. For starters, the methods in one monkey’s patch might conflict with those in some other monkey’s patch. In our example, the sequencing operator for parsers conflicts with that for symbols.

Hmm. First, version control systems exist partly for that reason - to let developers look at exactly those kinds of conflicts. Second, would Bracha rather see developers in Smalltalk (et. al.) use the same kind of "support class" nonsense that Java developers have been locked into for years?

Sure, you can get in trouble with conflicting extensions - in BottomFeeder, I ran into exactly that problem when I started using Antony Blakey's improved Look and Feel policy. Here's the thing though: I spoke to Antony, and, after we talked a bit, we dealt with the problem. So let me see: my solution involved more and better communication between developers. Bracha's involves "just say no".

Call me crazy, but I think my approach seems far more practical in the real world. At the end of the day, his approach comes from the school of thought I like to call "the library developer is god".

Hat tip Patrick Logan

Technorati Tags: monkey patching, smalltalk

Patrick Logan makes a good point: dynamic languages are productive, but they are even more so if you have good tools. Adding class extensions stop being "monkeypatching" if you have tools that support the idea:

People developing large systems in dynamic languages, and people providing dynamic languages being used to build large systems have to also realize this:

You are no longer working with a "scripting" language. You need to demand and provide really good tools. Examples can be found on the internets, read about the Smalltalk and Lisp environments from way back when. Someday you can become as smug as we are, or maybe as brilliant as the people who made them for us.

Technorati Tags: dynamic languages, smalltalk