Smalltalk Tidbits, Industry Rants

Tim Bray on JavaOne talk:

After saying some nice things about Rich, Jonathan proposed that they do a Q&A, with Jonathan asking the questions, saying a “I’ll simulate a developer”. His first question was “So Rich, are you going to open-source Java?” Rich started with “Well, why not?”

Here's a "why not" for Sun to ponder: If you OSS Java (and never mind the compatibility issues Tim mentions later in the post), then the license revenue Java does bring in dries up. Sun already destroyed the value of Solaris by open sourcing that - by open sourcing Java, the (admittedly paltry) revenues from that will dry up and blow away.

At that point, someone is going to have to go into the exec offices and ask exactly what the value of Java is to Sun. It speeded the commoditization of Solaris and SPARC - once money makers for Sun. The guy who takes over Sun after Schwartz drives it into the ground is going to have very little of value left to sell - either to customers or parties interested in acquiring the remnants. As Forbes says:

What pieces could Sun sell? The three most valuable assets are the Sparc chip line, the Solaris software and the hardware that uses both. The three would be hard to sell independently because they're designed to be tightly integrated. But the chips, once the clear choice for high-performance computing, are no longer on the cutting edge. And Sun cut the value of Solaris steeply by turning it into an open-source operating system. StorageTek, a tape-drive maker Sun acquired last year for $3 billion net of cash, could be sold, but there isn't exactly a line going out the door of people who want to buy tape-drive companies. Sun's Java software language generates lots of goodwill among programmers but not much revenue. Kariithi estimates it brings in only $10 million a year.

Somewhere, the folks at IBM who actually do make money on Java are laughing, a lot.

In a thread in comp.lang.smalltalk, Eliot answers why Store was developed:

While Jim Robertson's financial info on ENVY and VisualWorks is fine that's not the reason that Glenn Krasner as VP of engineering and I as technical lead had for ditching ENVY.

First,. ENVY essentially dictated the architecture of the development environment, including things like what constituted a valid package. Once a new version of VW would come out we would have to wait about 6 months for the corresponding ENVY to come out. That gave VAST a 6 month time-to-market advantage and meant that whatever ParcPlace engineering did to enhance the programming experience was essentially irrelevant because it would be overlaid by whatever ENVY deemed appropriate.

When we came to do VisualWorks 3.0, which introduced Parcels, this was intolerable. First parcels had features ENVY couldn't model:

Parcels do "partial loading". One can maintain a large logical component in a single parcel and load it in a system that is missing some prerequisites. Any code that can't be loaded is held back until subsequent code loads make it installable.

For example let's imagine you build a distributed programming system that allows helper methods on classes to control distribution semantics for different kinds of objects. Let's say you have several loadable applications such as a multi-user drawing editor and a dungeons and dragons game which you make distributed with the system. With parcels you can put all distribution code, including helper methods, in a single file. If you try and load it into a base system that is missing the drawing editor and the d-n-d game the parcel will still load. The extension methods and subclasses get squirreled- away for a subsequent load. When you load the drawing editor the distribution methods and subclasses get added.

In ENVY and other code loading systems in Smalltalk and other languages you must subdivide the distribution package into a code set of facilities and separate fragments.

This is a real advantage when you try and break up a system into components. Partial loading means you don't have to visit all other components splitting them up whenever you extract some base functionality into a component.

Essentially it avoids a polynomial explosion in the number of components in a componentised system.

Parcels support overrides, the ability to redefine classes and/or methods on load. So a parcel can override an existing base method, which is essential if you want to add or modify kernel behaviour on load. The overridden code is remembered so that if you unload a parcel the system reverts to its previous state, allowing one to unload code, which allows one more freedom in trying components out.

We needed the facilities to make 3.0 a componentised system within the limited resources we have and these features have proved their usefulness over the years, but ENVY could not support them and we would have had to wait for years for it to do so. So we provided Store as a team programming tool that supported the new parcel concepts and facilities.

Second, we wanted to bring programmers a rich VisualWorks programming experience immediately, and not wait for ENVY to get around to doing the work. We believed (and still believe) we can do a better job than ENVY in the context of VisualWorks. By moving away from Store we have gained control of the programming environment and you can see the improvements made in recent years. Vassili would have had his hands tightly tied had we not moved out from under ENVY.

Third, Parcels allow one to add single methods, including methods defining types or external calls in external interfaces. ENVY requires an entire ExternalInterface class to be in a single package.

Fourth, and quite importantly, ENVY's model is that one is always attached to the repository. Store allows one to detach, developing in ones' own image, reconnecting to the repository when appropriate. great for plane trips.

Fifth, ENVY's versioning scheme is old-fashioned, based on ascending version numbers. Store separates the version tree from code quality. There is no implication in Store that a later version is more correct. In Store one has "blessing levels" which declare whether a given version is production quality, development quality, blue sky, etc, etc. So components can go through natural cycles of development, productization, experimentation, development and productization for version 2, etc.

So we had very strong compelling technical reasons that were the real driving factor. We had to risk pissing-off customers who were wedded to ENVY and even risk losing some of our most important accounts. But in then end VisualWorks is much better because of it.

Add in the business reasons mentioned here, and it all makes a lot of sense - and doesn't involve politics.

Dave Winer on Web 2.0:

Now, will there be a bubble? Yes, of course, read the VC blogs, they're basically telling you they're running out of deals they're willing to fund. And who doesn't think the growth of Google is going to slow at some point? Don't we all know that web advertising is a scam? A friend who writes for a very big news site said the other day that he had never clicked on an advertising link. Even people whose salaries are paid by the advertising industry think it's a scam. And scam is just another word for bubble.

I agree that there's a bubble, but it doesn't seem to be as big (or as silly) as the initial one. The advertising thing is slightly different though, I think. Advertisers and content producers have been lying to each other about the efficacy of the eyeball (or eardrum) model of advertising since the golden age of radio. The issue has always been one of imperfect personalization - advertisers know that they are wasting money, but have not been able to figure out how to effectively narrow the audience down - to be able to deliver a message to the person who wants it.

That should be possible with the web, but it will require a lot more tracking of behavior than some people will like. Not to mention that - like supermarket affinity programs - the tracking will really only be used to go after the high end consumer. The advertisers really want to find the 20% of their intended audience who spend 80% of the money, and deliver a message that has real interest to them. That's no easy task.

The slashdot crowd will have a meltdown, but the WSJ's Mark Golden is right: Linux on the desktop just isn't ready for most people. Heck, I've come to the conclusion that most people can't safely run Windows on the desktop, due to the constant need to play sys-admin. The answer isn't Linux though; it's Apple. The problem is the level of effort required:

What I found was that for some people, Linux systems may do just fine. But they still are largely more appealing to computer hobbyists who would like to see Microsoft face more competition. Specifically, while the installation and simple functions worked well enough, the systems couldn't handle all the multimedia applications I needed. And getting some of the systems to work required more time and effort than I was willing to exert.

The last sentence is the kicker. It's not that you can't get various things working on Linux as they do on Windows - it's that it takes more effort (and expertise) than most people are willing (or able) to expend. The sad truth is that the same thing is true of Windows, but not in the same way. Everything "just works" out of the box, but things aren't safe. I've yet to encounter a non-technical person running Windows whose machine wasn't infected - often with multiple things.

You can run Windows or Linux quite well if you're a technical user, and willing to play sysadmin. If you aren't, then a Mac is almost certainly your best bet. The premium you pay up front will be more than made up for by the lack of "wtf??" moments you'll end up having.

In a small bit from The Register about the new book "Prefactoring", Smalltalk (and Cincom Smalltalk in particular) gets a mention.

BusinessWeek lets itself be a front for another round of "the internet is falling":

Every day, it seems, a new service pops up offering to send you video over the Internet. "Desperate Housewives," Stephen Colbert heckling the president, clips of bad dancers at wedding parties: It's all there.

You may be up for it, but is the Internet?

The answer from the major Internet service providers, the telephone and cable companies, is "no." Small clips are fine, but TV-quality and especially high-definition programming could make the Internet choke.

Over the last 10 years, I can't remember how many things have been about to make the internet choke. At one point, I think the mere existence of broadband on a large scale was going to do it.

Chicken Little, meet your local ISP. Just make sure to hold on to your wallet.

Scoble from Middle America:

So, I've been thinking about what it'll take to get these folks to try something new. Hey, the iPod still hasn't gotten here, so don't even ask about podcasting, RSS, or tagging. Interestingly enough, blogging has been heard about here. One older lady who visited my mom saw that I was blogging and she said "oh, blogs are the things that's keeping the media honest."

Heh. The things that get heard here in a small town in middle America.

Two things come to mind reading that. First, the condescension for "fly over" country. I don't think it's even a conscious thing for Scoble, but there it is. I rather expect that if he headed on over to the local high school, he'd find a more tech savvy audience.

Second, he could come and ask the parents of my daughter's girl scout troop about tagging, podcasting, RSS (et. al.). We live 30 miles from Washington DC, in the heart of "bi-coastal" America. And believe me, none of them would have any more awareness of that stuff than the people out there in Montana.

The funny thing is, the "keeping the media honest" thing is more relevant than any of the other stuff Scoble mentioned. It has more of an impact on day to day life for most people. There's a huge bubble all right - and way too many people on the two coasts live smack in the middle of it.

Now here's the definitive site for LOTR language geeks - a complete compendium of the languages of Arda.

That old song may end up having more poignancy than anyone would have guessed. New Scientist reports that we may have out-clevered ourselves:

Virtually all bananas traded internationally are of a single variety, the Cavendish, the genetic roots of which lie in India. Three years ago, New Scientist revealed that the world Cavendish crop was threatened by pandemics of diseases such as that caused by the black sigatoka fungus. The main hope for survival of the Cavendish lies in developing new hybrids resistant to the fungus, but this is a difficult and time-consuming task because the seedless modern fruit does not reproduce sexually and has to be bred from cuttings.

For all the talk about monocultures in software (i.e., Windows), this looks like it might be the real deal.

"A Peace to End All Peace", by David Fromkin, is a book about a forgotten theater of WWI - the Middle East. It's primarily focused on the efforts of the British government, and that was a huge muddle. The Egyptian Office, the Home Office, and the India Office all worked at cross purposes, with the "Arabists" of Lord Kitchener mostly coming out on top. If we weren't still living with the legacy of what they did, this book would be comical - the misinformation they basd their policy decisions on is just sad. I'd recommend this book to anyone who wants some background on how the modern middle east came to be.

Almost seems to count for a lot with "Duke Nukem Forever" as well. Here's piece of a Game Daily interview:

Miller: We've put about $7.5 million into that and we've been working on it since late 1998. So it really hasn't been that much of an investment. And once it comes out, if it's as successful as we think it'll be, we'll make that money back in the first day or two of sales.

THR: 1998? You've been working on it for eight years?

Miller: I know, I know. It's embarrassing.

THR: Maybe you can explain to readers who don't know the games industry why it should take that long to make a game.

Miller: It shouldn't. And I'm dumbfounded myself. A huge part of the problem is that it's really hard hiring good developers to come to Dallas. This place used to be a hotbed of game development. But, nowadays, people seem to want to go to Austin instead.

Hmm. Sounds odd to me. Aren't most game developers young and more easily relocatable? In any event, that game is the industry version of Waiting for Godot.

Well, the level of BottomFeeder downloads hasn't dropped after the slashdotting - they hung steady at a rate of 170 per day. The details:

Platform	BottomFeeder Downloads
Windows	455
Update	153
Linux x86	145
Mac X	121
CE ARM	82
Mac 8/9	58
HPUX	48
Solaris	34
AIX	34
Linux Sparc	20
Sources	16
Windows98/ME	11
Linux PPC	6
SGI	4
ADUX	2
CE x86	1

The real story will be in the HTML pages accesses - that will have dropped off since last week. The details on that:

Tool	Percentage of Accesses
Mozilla	66.4%
Internet Explorer	24.7%
Other	4.2%
MSN Bot	2.7%
Opera	1%
Megite	1%

The number of unique readers is still up for the week, so I guess some of them stuck around. On to the RSS:

Tool	Percentage of Accesses
Mozilla	26.5%
BottomFeeder	14.9%
Net News Wire	9.1%
Other	8%
BlogLines	8.5%
Internet Explorer	6.1%
Safari RSS	4.6%
Google Feed Fetcher	3.5%
BlogSearch	2.4%
NewsGator	2.4%
RSS Bandit	1.7%
SharpReader	1.6%
Planet Smalltalk	1.5%
JetBrains	1.2%
Liferea	1%
News Fire	1%
MSN Bot	1%
Java	1%
Attensa	1%
Everest/Vulcan	1%
Lilina	1%
Feed Reader	1%

The subscriber count jumped up as well, so it definitely looks like I got some new readers. Welcome!

It's starting to look like a board game renaissance. Can Smalltalk be far behind :)

One of the things a lot of people get wrong is user spikes. Whether it's spike in downloads of a product, or a spike in traffic, a lot of people will tout the sudden increase as if it matters. In reality, as this post makes clear, it usually doesn't:

Josh Kopelman has a perfect post up today called 53,651. This is the number of RSS subscribers to Michael Arrington’s great TechCruch blog, and is exactly at the core of the “first 25,000 user” issue. Since there are 53,651 RSS subscribers of TechCrunch (at least as of 5/12/06) , if something gets reviewed there, it’s likely to get 5,000 to 10,000 users in the next 24 hours “just to try it out.” As so many traffic graphs of these “TechCrunched” products show, there is a huge spike in use for a day or two, and then it goes right back down to where things were before they were TechCrunched.

There's a nice chart that goes with that; follow the first link to see it. As most of you know, a post I made last week hit Digg, Reddit, and Slashdot - and gave me a sudden flood of traffic. That flood didn't last - it's not as if every reader of those sites suddenly became fascinated by Smalltalk :) I know plenty of marketing people who would make sure to include that spike in a report on traffic averages thoug, in order to make themselves look better. It's no more real than the initial spike in users described above.

If you're trying to build a new business, those mentions help, but they won't put you into "lie on the couch and wait for the orders" mode...

It's often the case that management - and in particular, VC management - spend way too much time focused on irrelevant details. For instance, Thomas Gagne writes:

Too many potential investors spent too much time looking at the technology. The answer was always the same: lots of scalability, too little system documentation. The technical due diligence reports would often comment about the Smalltalk in the "risks" section something like, "Using Smalltalk may make it difficult to find programmers, but by using it they won't need many anyway."

Why is the worry about technology use irrelevant? Either the startup being funded has a good product or they don't. If they engage in a long effort to rewrite it in an "approved" language, they'll almost certainly miss whatever market window they are going after. The phrase Thomas used next is very telling:

Many of those VCs don't exist anymore.

I rather expect that a lot of them "managed" their startups into oblivion by asking them to do stupid things. To follow the story:

When we finally found some real investors I was surprised they didn't seem too interested in the technology. They wanted to know it worked. They wanted to know it balanced. They wanted to know the president had confidence in it and me. After they understood the business plan and what the company was preparing to do I really don't think it mattered much to them what the code was written in. They weren't buying into language marketing or hype, they were buying into a commercial finance revolution. The system could have been written in 16-bit Fortran-IV and they wouldn't have cared as long as it was supportable, scalable and correct.

Couldn't have said it better myself. This reminds me of something that came up many years ago, back before Java was around. I was teaching a Smalltalk class with Russ Pencin, who is one of the two best instructors I've ever met. We had a C programmer in the class who really, really wanted to know how strings were implemented at the VM level. Russ' answer was brilliant:

Why do you care?

Why indeed? If the system performs well, what difference does it make? The same goes for funding, really - training developers in a language they don't know already isn't that hard. If it was, C++, Java, and C# never would have succeeded. Sure, the syntax is similar - but they don't really work like C. If it was that hard to train developers, we would all still be using Cobol and Fortran, for that matter.

Thomas also quotes Paul Graham - and this is one of the smartest things I've ever read:

"In a big company, you can do what all the other big companies are doing. But a startup can't do what all the other startups do. I don't think a lot of people realize this, even in startups."

If all you strive for is mediocrity, then sure - hire cheap developers and use what everyone else is using. If you want the chance to do better, you have to be different.

Brad Wilson on starting the day:

I don't know about you, but I sure don't read the newspaper any more. It's a stale version of information compared to what I can get 24 hours a day from the web. And, letting someone else pick my comics? Never!

I start my morning with a bowl of cereal and my comics. On the web, of course!

heh. I go the extra step here - I created scrapers for the various comics I like that don't show easily via RSS, and create local (i.e., on my HD) RSS feeds for them. I have a BottomFeeder plugin that periodically runs the scripts, and each day I have all the comics I want, right there in my aggregator.

James Governor likes the usage numbers being reported for Sun's app server software:

Go buy some stock? The evidence is coming together in some interesting ways.... and if Sun's Java Enterprise System app server has momentum, anything can happen.

In the accompanying data, Sun's market share has jumped up to almost 20%, which does look good. However, that may not mean much revenue:

Download a complete enterprise-class solution -- Solaris 10, Java Enterprise System, development tools, desktop infrastructure and N1 management software -- at no cost, no kidding.

You only pay if you want support. There was an article on the uptake of support licenses for JBoss awhile back, and it wasn't encouraging:

Problem is, most people just take the free stuff and run. Only 3% to 5% of JBoss customers buy support contracts.

Which is one of the reasons that JBoss ended up selling out to RedHat - the ongoing development costs simply weren't being met by those paltry incomes. So let's look at the app server and OS for Sun, shall we? Schwartz has made Solaris free and open source, and championed it running on x86. So even if I decide to run Solaris instead of Linux, I still don't need to pay Sun a nickel. The same goes for the app server. This is the ideology of free masquearding as a business plan, and I doubt that it will end up happier for Sun than it did for JBoss.

If you give it all away for free, you can't make it up in volume.

In the same vein as the last post, I thought it might be valuable to go over the way Smalltalkers normally construct new execution at runtime. One way, as I covered in my last post, is to compile code from a string. All by itself, that gives you a fair bit of power - you can compile anything, including new classes. You can add new instance variables to existing classes, and have all the subclasses get recompiled for you - at runtime. When I do live updates of this server, I'm often doing just that.

So a few examples - say I wanted to add a new instance variable to an existing class. I could do that a couple of ways. I could recompile the class definition. Here's my class in the browser before that step:

Now, I execute the code below:

 
 

Compiler evaluate: 'Smalltalk defineClass: #Foo
	superclass: #{Core.Object}
	indexedType: #none
	private: false
	instanceVariableNames: ''var1 var2 ''
	classInstanceVariableNames: ''''
	imports: ''''
	category: ''test''' 

The double quotes are to tell the compiler that the things wrapped that way are strings, not the end of the string being defined. Executing that yields:

You can also tell the class to add an instance variable, rather than recompiling the class:

 
 

Foo addInstVarName: 'var2'.

In Smalltalk, all your objects - including the classes - are live at runtime. They aren't dead text lying in the version control system, and they can all be manipulated. You can insert new methods into a class in much the same way:

 
 

Foo compile: 'initialize
var1 := 1.
var2 := 2'.

Which adds the #initialize method to class Foo. You can inject new code into a class at runtime this way - so if you have a code generator for some reason (database interfacing, whatever) - you could have the code dynamically generated and added all at once.

You can also dynamically create message sends that didn't exist at deployment time via #perform. Say you have a variety of API methods, all similarly named, but their use depends on a base selection (in the post tool I'm using, that's how code fires, based on whether the tool is set for my API, the MetaWebLog API, the MT API, or the Blogger API.

So how does that happen? Here's an example. I have the following message send:

 

^self performForAPI: 'GetAllItems'

And that code looks like:

 

performForAPI: messageString
	^self performForAPI: messageString with: #()


performForAPI: messageString with: arguments
	| prefix msg |
	prefix := self perform: self apiToUse.
	msg := (prefix, messageString) asSymbol.
	^msg isKeyword
	       ifTrue: [self perform: msg withArguments: arguments]
	       ifFalse: [self perform: msg]

The message is created by appending strings, turning that into a symbol, and then firing it. This is not a completely great idea in all circumstances (it makes it hard to trace senders, for instance) - and I wouldn't write the post tool that way were I to do it now. It's a nice capability, and very valuable when you need it - but you really need to be sure you need it.

In any case, that shows some of the more dynamic features of Smalltalk.IMHO, they are far less baroque than what C# is adding, because Smalltalk was created with this kind of thing in mind. C# wasn't, and it shows.

Wired has a column that wistfully looks back at the days of powerful unions, and dreams of a unionized Microsoft. Towards the end of the column, there's this:

So, will we ever see a unionized Microsoft? With his own union working on the Redmond behemoth, Courtney certainly won't rule it out.

"WashTech has been actively trying to build the union at the company. (It's been) recently reported how wages at the company have been stagnant while profits are soaring, and that the review process has become an unfair management tool. These are core issues that a union can address."

Microsoft needs to become more agile, not less. Right now, they suffer from the same kind of rigidity that cost IBM so much money back in the mid to late 80's. What if the work force there joined a union? Well, they would see work rules and process - just like now - only from the employee side, rather than from the management side. I fail to see how that would help the company in the long run. It might help a few people in the short term, but I rather expect that it would drive the company toward an Eastern Airlines sort of ending.

What MS needs is more people like Scoble, who are willing to shake the rafters and try to create positive change. Unions, like management, are conservative forces that fight change. That's not what MS needs.

Update: Stephen Pair gives a parse tree example in the comments.

Don Box has another post up showing how to create lambdas in C#. The syntax for all that looks pretty baroque to me. In any event, Don asked in the comments to my last post on this for the Smalltalk equivalent. I'm not going to generate a list and compile that, as he does with Scheme and C# - in Smalltalk, we'd have a string, and just evaluate that at runtime. Same idea, just not the same machinery. So the way I'd approach his problem in Smalltalk:

" Creates the function that adds one to the input value "
func1 := [:a | a + 1].

" String for the same function "
func2String := '[:a | a + 1]'.

" Print that to the Transcript window "
Transcript show: func2String.

"This will raise a MessageNotUnderstood: #value "
func2String value: 4

" Have the compiler evaluate the string, which gives us the function "
func2 := Compiler evaluate: func2String.

"Now execute that, which gives us the desired answer of 5 "
func2 value: 4

If you were really hung up on creating a List, you could do that with MessageSend objects, and then hack the compiler a bit to get it to deal with lists instead of strings. That's not how Smalltalk works though (it's kind of cool that you could make it work that way - I've had University students tell me about projects to implement that in Smalltalk). The Compiler is just another object that you can subclass and/or extend - the IDL compiler for CORBA and the DLLCC parser for our foreign language interface are both implemented that way. In general, you can tell any class which compiler to use (allowing you to easily create domain specific languages).

The bottom line is, creating code whose execution is deferred until later is easy in Smalltalk - and is still easy if you want to create that code on the fly by generating the code and then compiling it at runtime.

Over the last few days, there was a flood of spam to the CST Wiki. That was causing two problems:

• I had to constantly promote the good pages over the spam pages
• The wiki implementation keeps all versions of all pages in memory - so it was getting bigger

To solve the first problem, I added a simple blacklist. The spam that hits the Wiki seems to come in waves, against a bunch of pages, and all of the same kind. So adding a specific filter to the blacklist solves the problem. The second problem was something I suspected, but didn't verify until this evening. After loading all pages into memory, the system was running right into the (system imposed) limits on memory. So that meant that it was getting into thrashing - it always needed more memory, but the internal limits wouldn't allow it to.

As it happens, that's easy to fix in Cincom Smalltalk. First, you can raise the upper bounds on memory, at runtime, like this:

ObjectMemory currentMemoryPolicy memoryUpperBound: someDesirableNumberHere.

That solves part of the problem. The other part is ensuring that the system has big enough memory zones right at startup, so that it doesn't have to thrash to get there. That's accomplished by sending a message like this:

ObjectMemory sizesAtStartup: #("array of seven numbers goes here")

The documentation for that method is probably called for here:

"Sets the suggested initial sizes of various memory spaces for future snapshots. The spaces whose sizes can be set are as follows:

1. Eden
2. SurvivorSpace
3. LargeSpace
4. StackSpace
5. CompiledCodeCache
6. OldSpaceHeadroom
7. FixedSpaceHeadroom

These sizes are suggestions only, the virtual machine may have to deviate from these settings in order to successfully load an image. In general, the sizes are specified as a multiple of the platform-dependent default value for each space. In other words, if the first element of arrayOfSizes is 1.5, then Eden's suggested size will be 1.5 times the default size of Eden on the platform that the system is being started up on. A value of 1.0, on the other hand, will result in the default value being used. A value of nil in a particular slot of the arrayOfSizes, will have no effect on the current setting for that particular space. Fails if the arrayOfSizes is not as large as the number of spaces whose initial sizes can be specified or if the values in the arrayOfSizes are not either nils or Floats that are greater than or equal to zero and less than or equal to 1000. Returns the receiver."

The important one in the case of the Wiki was number 6 - old space. Any runtime objects that survive initial GC end up in old space, so making it bigger solved the thrashing problem. Of course, you could argue that the Wiki shouldn't cache everything in memory, and you would probably be right. That's the way the current codebase works though, and mucking with memory settings lets me keep it running while I have a look at the base problem.

A few years ago, we had some issues with hosting the Cincom Smalltalk Non-Commercial downloads - the server they were on didn't have sufficient disk space to hold everything, so we got a new one. In order to keep things running, I hacked together a"temporary" application that would keep the downloads flowing.

Well, that temporary application is still running, nearly 4 years later. It was never written to be permanent, and the way data was being stored made duplicate entries pretty much inevitable. Well, today I finally got around to weeding those dupes out - on the live server. If you tried to login or register for the NC in the last little while, you might have gotten an "application maintenance" screen. That's done now, and things are cleaned up.

The lesson? No application is every temporary. Does that mean that you need to do the whole enterprisey design up front and set it to scale to the hilltops? No, but it does mean that you shouldn't have delusions of temporariness, either :)

Don Box points to the new support for lambda expressions in C#:

Expression<Func<int, int>> expr = a => a + 3; 
Console.WriteLine(expr); // prints "a => Add(a, 3)" 
Func<int, int> 
func = expr.Compile(); // LCG's an MSIL method from the expr Console.WriteLine(func(4)); // prints "7" 

Yes, it's nice that Microsoft has added this to C# - it gets them up to Lisp and Smalltalk levels of technology, only a few decades late :)

Personally, I find the following easier to look at:

expression := [:input | input + 3].
Transcript show: expression method getSource; cr.
Transcript show: (expression value: 4) printString; cr.

You don't have the separate compile step, because of the way Smalltalk works. What's also neat is this:

That's the block expression being inspected, with the bytecode highlighted. In Smalltalk, it's turtles all the way down.

Lee Gomes of the WSJ reports on the TopCoder contest, and comes to this conclusion:

The results have been carefully tabulated by a computer and, thus, are beyond dispute: Of the 48 best computer programmers in the world, only four of them are Americans. But what that bit of data says about the state of the U.S. education system is open to debate.

Hmm. So Lee, if I set up an online survey, can I take those results as representative? What you have here is a self selecting pool of respondents. You simply can't make the jump from a self selected pool to any kind of general conclusion.

Once you have a DVR, it becomes irresistible. In fact, getting a second (or more) suddenly seems reasonable. We now have 4 devices recording various things for us:

• 2 ReplayTV devices
• 1 Media Center PC
• 1 HD capable DVR from the cable company

Decadent as that sounds, they come in handy. There are nights when multiple things we watch air at the same time, and we have them picked up by one of those devices. The Replay TVs are the nicest ones; we can stream between rooms, and skipping ads is much more pleasant with 30 second skip. The cable box DVR is truly annoying, but it allows recording of HD content, which neither the Media Center nor the Replays can do. And yes, I know that Media Center PC's can stream - but then I'd need one in the family room, and the fan is loud - the ReplayTV is quiet. Maybe when Apple has a full solution a new mini will be an answer.

At this point, I don't even know what day most of the shows I watch actually air. This kind of behavior explains the attempts by the industry to create what Doc Searls calls value subtracting solutions. The idea of disabling channel surfing during ads is just too brain dead for words - never mind us DVR using folks, the entire population of TV viewers would barf at that. The bottom line is, the advertising model for TV has never worked that well - DVRs simply bring the long simmering worries about it straight to the surface. Like the RIAA with DRM, the industry is fighting tooth and nail to hold onto the old model, but it's not going to work - for the simple reason that the advertisers are starting to understand the problem. I expect to see more and more subscription models (moving down from cable to individual shows).

Doc Searls:

The future of local newspapers is local bloggers. Simple as that. Call them "stringers" if you like. But if you're going to build a bridge from the past to the future of journalism, you'll need bloggers to help build it.

It's not because their bloggers, either - the people that local papers need are bloggers because that's the easiest way for anyone interested in local affairs to publicize them now. John Dvorak was onto something when he coupled the decline of newspapers to the decline in local reporting.

James Governor on Smalltalk:

One thing to remember about Long Tail effects- is that something out in the tail can, in the right circumstances, reemerge as a fully fledged mainstream hit. The Touching the Void, Into Thin Air effect.

While I am certainly not about to make the argument that smalltalk is set to come back and displace .NET, Eclipse and whatever scripting framework du jours is oh so hot with the cool kids, there are some interesting green shoots around the platform worth noting.

Dabble DB has the blogosphere going brock wild (nice take here on Dabble and other situated online databases). Reviews for this database, targeted at the Read/Write , Programmable Web have been pretty much uniformly positive. Dabble DB is written in smalltalk running on the seaside web apps framework. Dabble, if it does break out into the mainstream, will surely drag some smalltalk developer adoption with it.

With the long tail, there's space for everything. The Enterprisey people and the agile folks can all do their own thing. I think Java was the last "big thing" to hit software development - from here on out, there are going to be bunches of small things, all appealing to different niches.

Via Dare, I found Rakesh Agrawal talking about GMail as a work tool. I mostly use GMail that way myself, so I had a look. One quibble on the downsides:

No offline access: I guess this isn't true because you can always use Gmail's POP support to download messages into an offline client, but then I'd lose that notion of having one single email box for everything. And I guess I also haven't felt the pain as much on this as of late because I haven't been traveling quite as much as I have in the past.

Well, not exactly. I use the POP interface so that I have normal client interaction, but I still have everything archived by Google. So I get the benefits of both - if I've aged off my mailboxes here on the client, I can still go to GMail and search.

Forbes cites Sega's VP of marketing to say that the Wii will retail for under $200. Digg has flagged the story as possibly inaccurate, so take this with a grain of salt.

I've grown tired of having to promote 5-10 pages out of the spam jail on the CST Wiki every day, so I went ahead and added some simple spam checking to it. We'll see how it goes - I'm sure I'll have to monitor the system over time.

Either McGovern can't read, or he's an elaborate hoax:

Mr Petrilli starts to attack James Robertson by referring to him as a servile self-seeker. In the past he has also commented with passion on several of my postings. He is now going after Robert McIlree for his views on EA. Of course, within his posting he does some chest-pounding about how he designed interoperable PKI systems for governments before most folks even heard of PKI. I wonder if we were to look at his past work, would we think it was of high quality?

If you actually read Chris' blog - which McGovern didn't link to - maybe he's with Gillmor and Goldstein on this "links are bad for you" thing - you would find that it was McIlree who described me as a sycophant of Chris. If you were present for any of our knock down, drag out arguments over politics (usually in a private channel on the Smalltalk IRC), you would know just how amusing that is. I think it's safe to say that we both march to our own drummer.

So the question remains: Is McGovern's site an elaborate hoax, or is he really that clueless?

Dave Buck shows you how to find the code you need to look at, even though you might be only minimally familiar with it. Once again, the capabilities of Cincom Smalltalk shine through.

James McGovern gives some advice to me:

Minimally consider becoming an advocate of all developer tools to become 100% free of charge. This has happened in several other communities where developer seats are now free but the charge remains for production server implementations. This positions Smalltalk and similar tools that still have legacy models behind them to now be learned by folks in countries such as India where they can gain critical mass in order to support large enterprises who may consider developing with the tools.

Well, it turns out that Cincom Smalltalk is free for non-commercial use already - it's only when you deploy it that you need to pay for a license. Simply download it from our site, and use the online tutorials. He mentioned open source first; I'll point out that Java is not open source, and has spread quite widely. When you grab Cincom Smalltalk, all the sources are available. For commercial users, that includes the VM.

Figure out a way to get the folks over at RedMonk and other analyst firms to change their perception that Smalltalk is dead or has been delegated to minor-league status within the enterprise. Start first by adding influential industry analysts to your blogroll. I would suggest starting with Brenda Michelson and James Governor.

Actually, I read (and link to) James Governor fairly often. I don't always agree with him, but I like his take on things. As to this:

While you are adding folks to your blogroll, consider also adding several enterprise architects from Fortune enterprises. Don't attack them and instead engage in a meaningful dialog with them. Never alienate potential customers.

Well, maybe it's a personality flaw. I call things the way I see them. When I see stuff I like, I say nice things about them. When I see stuff I don't like, I say not so nice things. A suggestion back, though: you'll note that I don't do politics here. There's a reason for that; it's because I figure that people with different worldviews still have money to spend. Those pictures McGovern uses on his blog? They create a perception problem.

I'm with Mark Bernstein - links are neither currency nor attention destroyers, and asserting, as Seth Goldstein does, that "strong web bloggers no longer link" is just nonsense. There have been people who've raged against punctuation too, and they were every bit as silly. When I read a long missive that references someone else, a link to the source is proper web punctuation. Omitting it means that I have to waste time with Google instead, which is just stupid - and impolite.

Meanwhile, Gillmor is proving every day that listening too him actively destroys brain cells:

As for links being dead, Nick [ed: Carr] demurs with an "I don't really get what you're trying to say Steve." Amanda Congdon does. Dave Winer does. What's not to get? Links produce economic ripples that keep incumbents in charge; removing links puts users in charge. Clicking on a link does not pay the author; it pays the signaller (in this case the aggregator, publisher, or arbitrager of the link's "value.") The author of the content is paid in link credits, which tether him or her to the tyranny of the mediocrity of broadcast economics.

I can't get straight to Carr's comments, because Gillmor has some asinine notion that not linking to him empowers me (the reader). Here's a tip, Steve - if that's empowerment, I want a whole lot less of it. He's pushing the idea of what he calls a gesture bank, where we all share meta data in some kind of vast xml ocean. Sure, sure. While you go about building that, the rest of us will just follow the links. Those don't take any effort to create, while the whol gestire sea thing will require lots of buy in, as well as a new tool infrastructure. Given human nature, I won't hold my breath.

Gillmor continues with this:

That's the problem with links: We're all waitresses on this gig. We're waiting on the Big Day when we hit the Big Show, when Mike Arrington or Doc Searls or Dave Winer bestows the Big Link on us that gets us another 10,000 in ValleyWag bucks. Some of my best friends are linkers. Don't forget to tip your linkers. Don't want to link? What, and give up show business?

Umm, no. Links are mostly akin to footnotes in a book, except that they are a hell of lot easier to follow. Steve just doesn't get it. He's out there thinking that we all consider links a desperate bid for attention from the so called A-Listers. No Steve - we mostly think they're a way to get more information about a particular subject. Attention? Heck, I wish Gillmor would start paying attention...

Sony has gone public with details of their pricing for the PS3 - and it looks like the guesswork about how much money they are willing to lose per unit haasn't been far off. They are going $100 up from the XBox, at $499 and $599. That's pretty steep, IMHO - we'll see if my notions about game system price points hold water. The details:

The 20GB HDD version will retail for $499, and the 60GB HDD version will go for $599. They promise 4 million launch units by December 31st. Update: 05/09 03:57 GMT by Z : Apparently, not only does the $499 system have a smaller harddrive, but it has fewer features as well.

Now it's down to how many units actually sell, and who's right about what the market will bear.

Update: Meanwhile, Engadget has a rumor about pricing for the Nintendo Wii.

Sadly, this could be me :)

Bob Congdon isn't sure about the new Mac ads:

The Mac is a young guy in casual clothes with a boyish stubble. In contrast, the PC is a middle-aged, suited business man. Do these two look familiar? It's no coicidence that the Mac looks like Steve Jobs circa 1975 while the PC is an overstuffed caricature of Bill Gates.

The ads may be entertaining but are they effective at getting users to switch? I'm not so sure. By relying on tired stereotypes Apple runs the risk of alienating and insulting the audience it's trying to convert.

I just saw this for the first time last night, and I thought it worked. The "what apps come bundled" thing was truly funny (although, to be fair, most PCs you buy from a vendor will come with some variant of Office pre-loaded). I don't think these ads will alienate anyone, but we'll have to wait and see whether they are effective.

Cincom's Helge Nowak sends along news of two upcoming events in Europe, both with a call for presentations/papers out:

There are two conferences coming up in Germany that would be very nice platforms to present Smalltalk with interesting talks as an up-to-date hot technology. While they are held in Germany both of them are interesting for international presenters and audience:

• Net.ObjectDays is a framework for a lot of interesting international sub conferences: http://www.netobjectdays.org/en/index.html
• these are the call for papers: http://www.netobjectdays.org/en/news/news.html
• iX Conference: the well recognised German IT magazine iX (http://www.heise.de/ix/) organises a conference on "Better Software!"
• this is the call for papers: http://www.ix-konferenz.de/

If it fits your plans, these are good shows - I've attended the first one before

Gee - what a shocker. OPML, yet another underspecified format that Dave Winer created, isn't as interoperable as people would like. As is par for the course, everyone is gushing about how great an idea the OPML sharing thing is, while tip toeing around the suckage:

First, I exported the group of feeds (the channel) from FeedDemon. That created an OPML file. Yet when I tried to upload it to Share Your OPML, I got an error that the file contained no feeds. I looked and it did - all the feeds were there.

So I then opened that OPML file in Dave Winer’s OPML Editor, did a ’save as…’ and then looked at that file. It had one thing the original didn’t - the <opml version="1.1"> container as the very first line. Uploading that new file to Share Your OPML worked without error.

So yeah, as I've said before, OPML just sucks. If the idea behind "Share Your OPML" takes off, I fully expect the following to happen:

• Various XML experts will start to notice the suckage, and point out what needs to be fixed
• As with RSS, Dave Winer will champion the suckage as a feature
• Various stupid work-arounds will be created by implementors, all of which will vary slightly
• Finally, a new format will be proposed to fix the problems
• Dave Winer will act stunned, and take it as some kind of betrayal.
• Meanwhile, his various enablers will refuse to call BS on him

Gee, it's almost like I've seen the movie before.

Demonstrating just how enterprisey he can be, Robert McIlree takes a shot at Chris Petrilli and me:

I got a 'visit' from self-proclaimed enterprise architect debunker Christopher Petrilli, and later, as it appears customary in posts by EA-types, from his sycophant James Robinson. Before I deconstruct their commentary, I'd like to thank both guys for the huge traffic they directed to my blog today. To those of you coming here from their links or a feed for the first time, welcome. Take the time to read my posts, judge for yourself where I'm coming from, and comments, whether you agree or disagree on anything I've written about, are welcomed.

So ask yourself - how reliable is a *cough* enterprise architect *cough* going to be when he can't get the spelling of one of his critics names right? It's not like my name is hard - it's right there at the top of my blog.

I can see it now: "ESB? Gosh, I'm sorry, I had it down as EJB..."

I should be 2 inches taller, given the location of the smoke detector in the bedroom. Here's the ladder set up to get there - believe me, I wasn't happy up near the top, changing the battery out:

This one gives you some idea of where the ceiling is:

So if I were 2 inches taller, I wouldn't need to be so close to the top of the ladder. My dad is over 6 feet tall; I could have used some of that :/

Dave Buck's excellent screencast demonstrating Smalltalk has hit reddit - go and give it some up points so more people see it.

Don Box asks a couple of Ruby questions:

• What's the performance penalty for passing/calling a block vs. executing the code "directly" on the current frame?  Does the cost go up/down if the block doesn't reference any symbols in the enclosing frame?  I know the answers for the CLR and C#, but I'm not sure my intuitions from that environment apply here.
• Do people wind up using blocks to model simple CPS-like idioms and if so, how does the runtime's stack management hold up?

I can't answer specifically for Ruby, but I can give my impression from its close cousin, Smalltalk. I created a simple class that ran one of two tests:

testDirect: n
	| val |
	val := Time millisecondsToRun: [n timesRepeat: [1000 factorial]].
	Transcript show: 'Direct for ', n printString, ' repetitions: ', val printString; cr


testBlock: n
	| val |
	val := Time millisecondsToRun: [n timesRepeat: [myBlock value]].
	Transcript show: 'Direct for ', n printString, ' repetitions: ', val printString; cr

Then I ran each test 1000 times, to get something representative. Over 1000 runs, I got 3100 ms for the direct run, and 3300 for the block (with a variance of about 100 ms per run). Upping that to 10,000 repetitions each, the difference between the two dropped to an irrelevant 60 ms (i.e., noise). So in Smalltalk at least, there aren't performance reasons to avoid blocks.

Which leaves it to being a "does it make sense from a design standpoint". Blocks are used quite frequently in Smalltalk in places where other languages have built in operators (i.e., various iteration methods in the Collection hierarchy). It's never caused an issue with the runtime stack that I know of - and the fact that Seaside (which carries full blown context stacks around) holds up tells me that there shouldn't be a problem.

That may not help for Ruby, but it does point out that a system using Blocks can be implemented efficiently.