Smalltalk Tidbits, Industry Rants

I stumbled across an interesting point of view on why things like generics haven't caught on in Java:

I think that this view is a bit optimistic, it's been noted before that language features don't really catch on unless they're integrated into the language, e.g. Garbage Collection in C++. It's certainly possible to build a garbage collected system in C++, and there are commercial implementations (I think one prominent vendor is named Great Circle), but hardly anybody uses GC in C++. So the fact that hardly anybody's using third party extensions to Java isn't an indication that people don't want them; they either don't know they want them, or they don't want to use a third party extension. Especially given that Sun put so much effort into promoting "100% pure Java", it's not surprising that nobody's shown much interest in creating a "better Java". Sun's created a situation where their imprimatur is crucial for language features to be accepted by the wider audience of Java programmers. So development focuses on the platform, where extension is encouraged, rather than the syntax, where extension is discouraged.

The whole thing is here. I think this catches an interesting difference between the Smalltalk developer community and the developer communities for other systems - especially Java and MS based ones. It's not that developers don't ask Cincom (or IBM, or Object-Arts, etc.) for additional features; they do. It's that they don't sit around and wait for them. The entire Smalltalk culture is built around a more self reliant, do it yourself kind of credo, whereas the mainstreamers tend to sit back and wait for the promised delivery from the vendor. Maybe that's because Smalltalk is simpler, maybe that's because Smalltalk has always left itself more open to extension - no final classes or primitive data types here, for instance. Whatever it is, I think it makes for an overall smarter community of developers.

This story has Sun reviving the x86 port of Solaris. Sure, this is where Sun should be spending their dollars, competing on the commodity end with Linux and Dell. At the very least, I'll enjoy the additional drag this will give Sun.

Another Thanksgiving is just about here - and I am girding for guests again. My wife and I managed to arrange things such that we never travel for Thanksgiving or Christmas; our relatives come here. This is a decidely mixed blessing - I don't have to drive anywhere and fight horrible traffic and airport crowds, but I do have to help prepare the rather large volume of food. And then there's always the huge stack of dishes to clean up, not to mention the days of Turkey leftovers. Still and all, better than traveling on the holidays, I think.

We released BottomFeeder 2.5 today. We made a lot of enhancements to this version - including making the menus more logical and context driven. The major fix was in the handling of merging new items into the existing cache of items already received - with some internal feeds, some bugs in this code surfaced. Those are fixed now. Suggestions on what else BottomFeeder could use? Send me email

BottomFeeder 2.5 is just about ready to go - we are testing one or two more things before release. There's been a longstanding problem with the way it identifies new items coming in - and we think we finally have that problem nailed. Look for 2.5 shortly!

My wife and daughter headed out to a party on Saturday, so I had plenty of time to add features to BottomFeeder. We have a project member writing a user's guide - and his questions have helped a lot, pointing out areas of the application that were clear to me, but not necessarily to others. I did take some time to hop on the web and buy a new ReplayTV. The holidays and my wife's birthday are upon us, and it seems that we are sufficiently potato-like that the 40 hour unit wasn't enough. So, the 80 hour unit is now incoming, ready to be hooked up to the other TV and the house network. I have some trepidation about that; the A/V setup in my family room is already confusing, and now I'll have to wire in a new component. Meanwhile, I'm convinced that the remotes are up to something when I'm not looking - there's always more of them floating about....

I posted this on the Cincom Smalltalk Wiki. Don't settle for second rate - switch to Smalltalk

If you take a look at the presentation I'm giving in Brazil, you'll notice that I'm going more on the offensive than Smalltalkers normally do. Well, here's my rationale - being accomodating and merely talking about interoperability hasn't helped. Look at Apple's switcher campaign, for instance. They aren't apologizing. They aren't talking just about interop. They are touting all the reasons why they feel Apple is a better solution. This is what I think it's well past time that the Smalltalk world did. Interop is great, and necessary. But it's not a compelling reason to use Smalltalk. Heck, if all I cared about was interop, I'd just use Java. Instead, we need to point out how and why Smalltalk is better. Talk up the productivity, and demonstrate to doubters how Smalltalk is more productive. Start touting - as Apple does - that Smalltalk is a premium brand, while Java is the commodity. There are plenty of developers who are pleased as punch about using a premium brand option - just look at all the Apple notebooks you see now at trade shows. That's where Smalltalk needs to go, and we need to take it there. Don't apologize - explain.

Ok, I said I wanted comments on my draft presentation for the trade show I'm speaking at - so here's a link to my draft. any and all comments welcome!

Wireless connectivity at starbucks with my Mocha. mmmmmmmmmmmm

Unless I find a wireless connection later. I have to head down to Washington to get a visa for my Brazil trip next month. Starbucks says they have Wireless connectivity - I guess I'll find out.

We had some entertaining problems over the last few days, but I think we have worked through them. We have:

1. Added a search capability. You can now search for keywords in the feeds - titles and/or bodies
2. We got the feed images to show again. There was an oddball issue with accessing the widget in a subcanvas, which we addressed

Try it out, and if you are brave enough, try turning the Learning Menus on!

So now I can have it looked at for comments. I plan to talk about XP practices, and why they arose in Smalltalk (as opposed to, say, C++ or Java). In fact, I doubt that XP ever would have arisen in Java, and I don't think it can ever be optimal there...

I have been deep in the bowels of an object identity problem today, and trying to get my presentation for Brazil in December. Busy, busy....

Lex Spoon is back at it, with more excellent points: Lex's original post got this response:

"If a component offers a service/API to the "world", such service/API should be as reliable/explicit (and this is where static/manifest/explicit typing --and again, only with interfaces-- helps) and stable as possible for optimal client/provider relationships. Refactorings should, and are supposed to, improve the implementation without altering those public services/APIs. "

To which Lex then responded:

If anyone really thinks static typing makes modules so stable and reliable, they should think about all of the alternative OpenGL libraries for MS Windows. Think about (for anyone who remembers) all the winsock libraries for Windows 3.x. Even think about libc on Unix -- many programs that had been ported to several Unices had to be tweaked again when Linux came around with its slightly different libc. In all of these cases, people drop in modules that have typed, verified interfaces and which have been heavily tested in isolation; but wierd behaviors result anyway. Making reusable modules is already hard, and making *drop-in* reusable modules is much harder still. Static typing doesn't do much for this problem as far as I can see -- you need a ton of verification and validation work with or without the types, and just as with unit testing, the testing will test the types along the way of testing the functionality. If you want types, don't want them for reliability. They are good for documentation, for example.... But then, I'm not convinced that a responsible programming team couldn't manage to write documentation, anyway. Do you ever hear engineers talking about self-documenting bridges?

Lex Spoon wrote an excellent piece in cls on the static/dynamic conflict: I just had the culture shock of defending a Smalltalk-based research proposal to a group of professors who love static types. It was wierd that they really don't grok the way a "language" like Smalltalk works. That's not my point, however. After some reflection and some discussion with my advisor, an interesting way to cross the gap came up: focus on the special *environment* that Smalltalk has. The fact is, pretty much all static type systems around only work in systems where you every code change is followed by a re-compile and a re-start. In this kind of scenario, a type checker can start from scratch and just say "yay" or "nay". If it says "nay", the presumption is that the programmer edits the program and resubmits it. It is considered acceptible in such an environment to adamantly require entire programs to be type safe before they are executed or otherwise processed, and it's considered acceptible to have to recreate all of your in-memory data whenever there is a code change. In an environment like Smalltalk, the bulk input and the frequent data recration both go away. Instead, programmers make one or two changes and then run their code some more to see how it is faring. They'll even reuse existing instances to try their changes with. TO DATE, THERE IS NO STATIC TYPING SYSTEM WHICH FUNCTIONS IN SUCH AN ENVIRONMENT. The hardest issue for such a type system would be to deal with existing data: if you have live objects floating around, then changes to their classes will make those instances become non-type-safe. This problem is pretty much the same as "database scheme evulation", a difficult problem that has received a lot of attention in research. A second difficult issue is that it may require multiple changes to reach a new type-safe program for a simplistic type system. Somehow the system *must* deal with the intermediate stages between type-safe programs, in order to maintain the nice environment. Again, this is clearly a very difficult problem. (Well, clearly if you've used Smalltalk.) By focussing on the environment style, the points are very clearcut and thus the discussion is much calmer than is usual with this topic. The debate boils down to a choice of environment style: is it acceptible to do batch inputs instead of developing a program with live data floating around? This is not to say that other issues in the dynamic/static typing debate are no longer interesting. For example, it's still true that there aren't any good OO type systems, and it's still true that for most practical purposes static types don't buy you very much. But in addition to being more diplomatic, the focus on environment style really gets at why *I* at least don't want to use static types: with today's typing technology, static typing means giving up some of the best features of Smalltalk. In fact, if there were a type system that would let me work in Smalltalk as usual, then I for one would be okay using it. I even wish there were more researchers focussing on static typing for such environments! My issue is simply that, there is no static type system at all that functions in a Smalltalk-like environment. Now, we just need a spiffy name for this style of environment....