Smalltalk Tidbits, Industry Rants

Avi has posted some comments to the squeak-dev mailing list about SmallBlog. One of the issues with the current version (you can see the problem on the learning Seaside Blog) is the lack of permalinks for existing posts; that makes it next to impossible to get back to old content once it's scrolled off the main page. Apparently, that's been addressed:

One of the major advantages of this version is that if you configure it with your hostname, the links generated in the RSS feed will be absolute, and so will actually work. Also, accessing the front page and the RSS feed no longer involves HTTP redirects, which confused some aggregators

BottomFeeder was ok with the redirects - it handles temp redirects accurately. It's good to see the link issue addressed though. I'm looking forward to Avi's keynote at Smalltalk Solutions - I'd like to hear more about Seaside.

Don Park comments on why Open Source projects typically have low quality UI's:

• open source developers have little interest nor incentive to do it right.
• most software developers lack the knowledge and experience to design good UIs.
• UI design is hard and insanely tedious, even for the professionals.

This was in response to Eric Raymond's post lamenting this. I'd add a simple observation - open source developers tend to build exactly what they need - and nothing else. Why? Well, this hearkens somewhat back to this topic. Most open source projects are small efforts (there are exceptions, like Eclipse and Apache). Most of these efforts are also not really about making money. As Don mentions, building a decent UI takes time and effort. If you aren't being paid, there's very, very little incentive to put in the kind of effort MS and Apple clearly do. Instead, you'll build something that's clear to you (the developer) and move on to more "interesting" (read - technically challenging) problems.

Heck, you see this in commercial projects as well. For years, VisualWorks had a second rate user presentation, because the tools were being built by engineers as an afterthought. We have people who are interested in and care about presentation on staff now, and it shows (compare the UI from 5i.3 forward to the UI for 5i.2 and previous to see what I mean). Small open source efforts are going to fall into this as well, unless they are fortunate enough to have a developer who actually cares about these issues. The larger ones - Eclipse, Apache, et. al. - are effectively commercial (i.e., funded) efforts and can afford to pay someone to care.

A lot of things fall into the "UI bucket" that aren't strictly speaking UI - anything that qualifies as a "finishing touches" issue will tend to fall by the wayside in open source projects. This isn't a flaw in open source development; it's simply human nature at work - and I expect that it's one of the reasons that political decisions to move to Linux (like this one) are going to run into rough patches. There are rough edges in Linux that many end users are going to be very frustrated with.

In an attempt to see if anything will stick, SCO has sued AutoZone. Meanwhile, ComputerWorld points to an interesting flaw in their theory:

AT&T said it wanted "to assure licensees that AT&T will claim no ownership in the software that they developed -- only the portion of the software developed by AT&T."

In other words, AT&T never intended for Unix licensees to give up ownership of code they added to their versions of Unix. That was never part of the deal. And the deal AT&T cut is the one SCO has to live with -- even 19 years later. That's how contracts work.

Of the million lines of Linux code that SCO claims IBM hijacked from Unix, SCO hasn't identified a single line that came from the original Unix source code. It was all created by IBM. According to AT&T in 1985, that means it's IBM's to keep -- or give away. And SCO's theory that it owns Linux code appears to be kaput

Goodnight Irene....

Cafe au Lait points to this question - "Think about it: have you ever had to reboot your microwave?" . Well, just like the Cafe Au Lait guy, I've noticed an increasing number of common appliances that need to be rebooted. My microwave, no. However:

• My minivan sometimes has spurious sensor malfunctions that light up the "check engine" light. A trip to the mechanic results in a hardware reset for the sensor in question, with no repair needed. I've had this more than once; the last one ended up pushing my annual pollution check on the car back
• My stereo receiver - a very nice Sony unit - sometimes refuses to play audio for any devices. It's clearly receiving signal from radio, or the CD or the DVD - it just won't play audio. Powering on/off doesn't work; I have to unplug and count to about 20, then plug it back in.
• We have two Replay TV's in the house, and they are supposed to be aware of each other - allowing streaming A/V between them. Periodically, they "forget" that there's another machine on the network, and have to be rebooted.

This is all due to the spreading of embedded systems to appliances and other devices. One of the things it's pointing out to me is that the people who write embedded software don't seem to be significantly better at catching boundary issues than the rest of the developer community is. Kind of makes me wonder about some of the truly mission critical systems out there....

Blaine Buxton announces the first meeting of the Omaha STUG:

If you're in the Omaha, NE area, please feel free to stop by Abraham's public library (around 90th and Fort) at 7:00pm for the first Smalltalk user's group! We will have an exciting demo fo Squeak by Mr. Steve Wessels. I would like to have lots of discussions and maybe we'll go for coffee later. I want the user's group to be a lot of fun and very interactive.

I remember Steve Wessels. Tell him I said hi!

ComputerWorld reports that IT hiring is increasing this year. Interestingly enough, they are also reporting that R&D is being offshored. That likely means that the overall market for IT services and products is starting to rebound, and that overall demand is starting to come back. Either way, an interesting pair of stories

The demand for Smalltalk books in Germany seems to be strong. I posted on this new book last year, and now I've learned that the book has gone into a second printing - only a 6 months after it became generally available! The book is in German, and includes a Cincom Smalltalk (VW 7.1 and OST 6.8) CD. If you've been looking for a good intro to Smalltalk, and you speak German, this is the book you want.

If you use VW 7.2, our engineering group has an important patch you need to get:

We have a patch for a fairly serious MD5/SHA regression in 7.2 (AR 47235: Hashes hashes intermittently generate wrong digests).

Have a look at the patch page - grab 47235 and install it now

If you are developing with VW and Store, I strongly suggest that you take a look at the package Store-Speed Patches in the public store. Loading packages goes a whole lot faster after loading it - kudos to Cham Puschel!

Amazon now has a ton of predefined search feeds. Wow.

Here's some more details on the schedule for Smalltalk Solutions 2004 - go and register today!:

An exciting set of keynotes feature Microsoft CLR Architect George Bosworth on the Smalltalk and CLR virtual machines, former Hotspot architect Lars Bak on Smalltalk for very small embedded devices, and Seaside inventor Avi Bryant on using Smalltalk to redefine web development.

Learn about technologies in-depth with tutorials covering the Seaside continuation-based web framework, Ward Cunningham's "FIT" acceptance-testing framework, Gemstone, garbage collection, web technologies from a Smalltalk point of view, and the GLORP object-relational mapping library.

Expand your knowledge with a wide-ranging technical program. Stay current with talks about Smalltalk and current "hot" technologies, including web services, .NET, XML, web interfaces with CSS, and Smalltalk on small devices. Hear the experiences of developers using Smalltalk in domains from pension plan management to emergency services dispatch to internet syndication to 3-D CAD and on topics from document management and reporting to the issues of migrating an application from Oracle to Gemstone. Last, but not least, learn about new enhancements and future plans, the impact they may have on your development, and about directions for the long-term evolution of Smalltalk.

Make sure to join us in Seattle!

Life after Angel - Firefly is going to hit the screen in 2005. That's really cool news.

The Schedule for StS 2004 is here. Now's a great time to register and get ready to come see the show. I'll be talking about BottomFeeder - Come see that if you want to learn more about the entire process of deploying a Smalltalk application in the wild.

The Register has found out what the PR masterminds at SCO have to say about themselves:

The SCO Group's masterful public relations tacticians have demanded that the company be compared to fellow IP (intellectual property) crusaders at the RIAA.

"We believe that there are important similarities between our recent legal activities against end users and those actions that have taken place in the recording industry," said SCO CEO Darl McBride, during a conference call today.

"It wasn't until the RIAA (Recording Industry Association of America) ultimately launched a series of lawsuits against end user copyright violators that the community at large became fully educated regarding the liabilities associated with using copyrighted materials without providing remuneration to the copyright owner. We believe that the legal actions that we have taken and will continue to take will have a similar impact on end users of Unix and Linux."

Yeah, there's a plan - identify yourself with the group that's suing 12 year olds. I had this vague notion that PR was supposed to be positive...

This year's Smalltalk Solutions promises to be a great show with some great presentations - like Avi's keynote on Seaside:

Winning the Application Server Arms Race: Using Smalltalk to Redefine Web Development keynote
Avi Bryant: http://www.beta4.com
Monday 10:30:00 am to 12:00:00 pm

Abstract: It would be hard to imagine a worse model for user interface development than HTTP. Would you use a GUI framework where every event from every widget in your application was handed to you at once, periodically, as a large hashtable full of strings? Where every time a single piece of data changed you had to regenerate a textual description of the entire interface? Where the event-based architecture was so strict that you couldn't ever, under any circumstances, open a modal dialog box and wait for it to return an answer?

Those are the costs of using the web browser as a client platform, and, by and large, we accept them. The dominant paradigms of web development -- CGI, Servlets, Server Pages -- do very little to hide or circumvent the low level realities of HTTP, and as a result, web applications are fragile, verbose, and ill-suited to reuse.

Smalltalk can do better. More than that -- Smalltalk is uniquely suited to do better. To date, we've followed conventional wisdom and built Smalltalk implementations of the same old paradigms, providing familiarity and compatibility. But by throwing these away, Smalltalk can instead provide an overwhelming competitive advantage. By leveraging Smalltalk's particular strengths, we can abstract away the ugliness of browser/server interaction in ways that simply aren't possible in other environments, and profit greatly by it.

For all its limitations, the web is fast becoming the most important deployment platform for many classes of application. The Java, Perl, PHP, and .NET worlds, to name a few, are pursuing it agressively. Many of us are going to have to play their game -- but we don't have to play by their rules.

Bio: Avi Bryant is an independent consultant based in Vancouver, Canada. Much of his work centers around the use of Squeak Smalltalk as a platform for commercial software development. As an actively contributing member of the Squeak community, he maintains its standard version control system, as well as packages for web development and relational and object database access. As a consultant, he has helped companies develop Squeak-based products for the travel and theatre industries, higher education, and mobile devices. Avi previously worked as a developer and research assistant for the University of British Columbia.

I've updated the details page on the upcoming (Fall 2004) release of Cincom Smalltalk. Have a look at what's coming your way

I've had a few reports over the last month or two of BottomFeeder's update loop inexplicably stopping, requiring the user to toggle the application through online/offline to restart it. I was baffled for awhile, but got some help this morning from one of our engineers who runs the application in his VW development environment (as opposed to the packaged application). It turns out there there were some poor assumptions in the code that checked for "too many" timeouts during the update loop.

There's a setting that allows you to ignore timeouts during the update loop. I always have that set, so I wasn't even seeing the problem. Now, say you have that unset (the default). The update loop keeps track of how many timeouts have occured during the current cycle, and takes notice when "too many" have occurred. How many is "too many"? Well, the code was set for 10%. This works fine for me and my 244 subscribed feeds. It works less well for someone subscribed to, say, 20-30 feeds - 2 or 3 timeouts can trigger the event. Now, the trigger was supposed to launch a dialog notifying you of the problem. This is where the second part of my error came into play

The action on too many timeouts is to suspend the update loop and then pop a dialog. The problem was, the dialog firing code was after the code that terminated the loop - and thus, never ran. Dohh! That's now addressed, and I've also put a lower bound on "too many" timeouts - it's now 10% of total or 10, whichever is larger. That should fix that problem. Now I'm off to create a new potential 3.4 build...

Michael Lucas-Smith points out one of the key differentiators of Smalltalk - extensibility. Every set of libraries - the STL (for C++), the base Java and .NET libs, the Smalltalk libraries as shipped by a vendor - all have limitations. These may be things the vendor didn't foresee, or things that the vendor's engineers have not gotten to. Either way, they represent an issue for any team that runs across them. The nice thing about Smalltalk is that you can deal with them directly. How? By adding to or modifying the base libraries themselves. String is missing a few methods in your opinion? Add them. The XML framework has insufficient reflection? Push it in. The code you add can be versioned off in easily separable ways from the vendor code as well - making it a simple matter to check for issues when the next major release from the vendor comes out. You just can't do this in those other languages - and I don't think it's a "feature", no matter how many ways it gets spun as one :)

Mark's experience with spurious information shows why you should always look at the media with a very jaundiced eye....

The second keynote at Smalltalk Solutions 2004 will be George Bosworth's talk about the CLR:

Smalltalk and .NET: A Comparison of Virtual Machines
keynote
George Bosworth: Microsoft
Tuesday 10:30:00 am to 12:00:00 pm

Abstract: TBD

Bio: George Bosworth is a CLR Architect with Microsoft and formerly architect of the Digitalk Smalltalk virtual machines.

We don't have an abstract yet, but George will be discussing VM architectures, dynamic language support, and the CLR. I'll post the abstract as soon as it becomes available.

Sci Fi Wire reports that there's going to be a remake of Logan's Run. All I can think is "Why?"

Sébastien Paquet has an interesting graph of subscription numbers from Dave Winer's share your OPML pages. At 246 subscriptions, I'm starting to push towards the right end of that chart - still nowhere near the 1300 or so that Scoble subscribes to though. I have no idea how he keeps up with that...

I started this as a comment to this post, but I decided to just post it once it started getting long.

The point we are trying to make is simple - all libraries, from all vendors, have issues and limitations. Pick a Java library or a .NET library, and you are pretty much stuck with the limitations. In many cases, some bozo library designer has declared it perfect for all time and made it final, so you can't even subclass it. Other times, usage of specific classes is hardcoded so that it's not practical to subclass even if you can

When confronted with this, you end up having to re-invent a lot of the supposedly reusable vendor code. Every Java application I've ever heard of has their own private String libraries to deal with this. The beauty of Smalltalk, in this case, is that we can overcome the limitations of the library without heroic efforts. I've made a number of such changes in BottomFeeder - in many cases, new releases have obviated my changes and I've removed them. But I didn't have to either:

• Live with the limitations until the next release
• Create my own parallel set of code that solves the issue

Instead, I've had to make small tweaks here and there - easily monitored, versioned off, and eliminated when necessary. That's one of the things VisualWorks would lose if we integrated into .NET (or Java) the way some people suggest. If we used "off the shelf" platform libraries, then the ability to modify them when we needed to would disappear. Here, go read this post for an example of what I'm talking about - Troy "enjoys" those .NET facilities every day :)

I indented that to make it clear that I was responding to the referenced comment. It's not that reusing existing facilities has no value - clearly, it empowers developers to "stand on the shoulders" of others. However, VisualWorks (the Smalltalk implementation being discussed here) is cross platform (which obviates total integration with .NET), and is dynamic (which obviates the JVM as a platform choice, since its support for dynamic languages is very sub-par. Yes, Jython esists. It's also much slower than it should be).

Looks like XP Service Pack 2 could break a lot of products - like all JITTed systems (most Smalltalks, and most extant JVM's). Here's the relevant quote:

"Applications which perform dynamic code generation (such as Just-In-Time code generation) that do not explicitly mark generated code with Execute permission might have compatibility issues with execution protection." The company is supplying specific instructions and code samples to explain the implications of the changes for application developers.

It's actually quite brilliant. I's a great way to take a shot at Java while standing innocently and saying "who, me?" You have to give points for the audacity alone. Here's the best part, from the MS page referenced above:

Some application behaviors are expected to be incompatible with execution protection. Applications which perform dynamic code generation (such as Just-In-Time code generation) that do not explicitly mark generated code with Execute permission might have compatibility issues with execution protection. Windows .NET Framework applications do not currently mark generated code with Execute permissions. XPSP2 recognizes the current, shipped versions of .NET Framework and runs them with NX off. Therefore existing .NET applications will continue to run. Microsoft is enhancing the .NET Framework to take advantage of NX and will ship service packs for each of the shipped versions in the XP SP2 RTM timeframe. The .NET Framework "Whidbey" will innately support NX.

Wow. So .NET gets a pass, and the rest of us get to suck eggs. This will be fun...

Here's an interesting article on changes in the game (software) development sector - it seems that multi-language development is becoming the norm in that world:

With the recent advancements in processing power and computing capability on the desktop, it is now possible to execute the logic and "upper layers" of a complex application almost as fast in interpreted code as is possible in native languages. Some languages are better than others at various things, or for certain types of authors. Recently, a number of games have used "dirty Java" techniques that link Java to a native engine through JNI (Java Native Interface).1 Vampire: The Masquerade 14Redemption (Nihilistic Software, 2000) used JDK 1.1 as its scripting engine with great success.2, 3 Java also contains a wonderfully well-written networking API (application programming interface) for communication using TCP/IP: One possible use of "dirty Java" would be a multi-user game engine handling all of the net code through the Java language, but rendering graphics using native code. The bottleneck in this case is the network itself; using Java byte code is a trivial cost in terms of execution speed, but a huge savings in development time and ease of construction.

Smalltalk could play that kind of role in the business world easily enough - it's highly productive (more so than the mainstream choices) and covers all the bases in the network/interop arena quite nicely. So instead of using VB for an entire app, developers could do all the "eye candy" and reporting there, and build the back end in Smalltalk. Right now, business developers are still in the "one language for all" mindset. Maybe they need to look at what's going on in the game shops for a few minutes...

Register for StS 2004 here so that you can hear all about making embedded systems serviceable in our third keynote address:

Resilient: Making Embedded Systems Serviceable
keynote
Lars Bak: OOVM A/S
Wednesday 10:30:00 am to 12:00:00 pm

Abstract: Developing software for embedded systems has until now been very static. Source code, written in C, is compiled and linked on the development platform and the resulting binary image is transferred onto the device. In an industry where robustness is paramount and dynamic software updates are required, this is simply not good enough. This presentation will describe a new approach to developing software for embedded devices. At the bottom of the software stack we have replaced the operating system with a Smalltalk based virtual machine. Scheduler, interrupt handlers, device drivers, networking code and application software are executing on top of this virtual machine. We will discuss some of the design decisions behind this dynamic, lean and mean system for embedded devices. The approach solves many software related problem within the embedded industry. The two biggest problems are full serviceability and transparent software updates. We will conclude with a demonstration of the Resilient programming environment and embedded platform.

Bio: Lars is a technology industry veteran with more than 15 years experience in virtual machine technology, product engineering and management. Prior to founding OOVM in 2002, Lars was the main architect of the Java HotSpot virtual machine at Sun Microsystems, Inc., a highly successful product with more than 50 million installations worldwide. At Sun, Lars was also the main architect of the CLDC HotSpot virtual machine, a new high-performance system for mobile phones. Lars holds a MS degree in Computer Science and is inventor on numerous patents within virtual machine technology.

May 3-5 in Seattle - see you there!

The Eolas web patent has been nullified. Is this progress at the PTO, or an "even a stopped clock is right twice a day" event?

Doc Searls takes the typical intelligentsia swing at TV - "it's all crap" while explaining why TiVo hasn't caught on:

Part of the problem is this right here: the Net. It's much more interesting and informative, and even entertaining. TV can't compete. So I think the problem is with television itself. It's still mostly a drug, and getting a better way to administrate it doesn't change the nature of the substance. It just facilitates better abuse.

I have gotten very tired of this brand of slam - whether it comes at TV, at the net, at politics (etc). It's all the same thing - Sophisticated people love to tell you how crappy something is, and why they don't pay attention to it. It's a tiresome argument, and reveals far more about the person making it than about anything else.

To be sure, there have been changes in TV over the last few decades. It's simply no longer the case that one of the major networks can get the attention of a large plurality (or even a majority) of the viewing audience with a few shows. There's simply too much competition. Say you like science fiction - it used to be that you had to just sit back and take Star Trek, or whatever else the networks offered (or didn't). Now you have the SciFi channel. Is there always something on that's worth watching? No, but there's a decent number of interesting things for that fan base within a given week. It's the same thing for history and science - it used to be that all you had was Sunday morning fare and public TV. Now there's the History Channel, the various Discovery Channels, and the Weather Channel (which airs weather related infotainment when it's not covering the weather). Which explains why you don't have to wait up for the 11:00 news anymore - the Weather Channel is always there, as are the 24 hour news networks.

And that doesn't even get into the vast sea of movies and series that are available on cable. Or into classic movies on things like TCM (Turner Classic Movies). The point is, TV isn't "crap" - it's filled with a huge variety of things, some good, some bad, some excellent, some awful. That's where a PVR - TiVo, ReplayTV, etc - helps out a lot. You set up the things you are interested in (either specifically or by category), and then it does the heavy lifting of separating the wheat from the chaff for you. So why haven't these things taken off yet? Well, I'd guess that we are still in "early adopter" mode on these. It took VCR's awhile to really take (I can remember many people questioning their worth in the late 70's), and - until recently - they were only being offered by two very small companies (one of which, ReplayTV, has had numerous issues). That's about to change though. My local cable company is offering PVR's as part of its service now, as are other cable (and satellite) vendors. This is going to help mainstream the technology.

It's not just the smallness of the vendors that has prevented takeoff though. Setting up a PVR is no walk in the park for most people. Getting all of these pieces properly set up:

• The TV
• The Stereo equipment
• The VCR

And adding the PVR into the mix such that you can watch one thing while recording another is asking a lot. I suspect that having the cable company offer to come out and hook it up will help with penetration - lots and lots of people's eyes glaze over when they are confronted with the sea of cables that have to be connected - mine included. I've set up two ReplayTV's, to two different tv/stereo/vcr setups now - and adding the Replays also meant adding a network connection into the A/V mix. I think the biggest issue with PVR penetration is the same issue we face with PC's - people mostly want to buy it, plug it in, and have it just work. Outside the hobbyist community, twiddling with cables and connections is work, not entertainment, and getting things subtlely wrong is just too easy. The cable and satellite vendors are adding a service offering into this mix, which will help a lot.

Enough with the "it's all crap" thing already though - get over yourself....

BottomFeeder 3.4 has been released. I'd like to thank Rich Demers for his help on this release - he spotted numerous bugs before they had a chance to embarrass me, and he did his usual great job on the Bf users guide. Michael Lucas-Smith prodded me to clean up the UI, and that's been done - we have a cleaner, sparser main UI now. As always, report any bugs to me.

If you are already using BottomFeeder 3.3, then you don't need to do a re-install - simply get the appropriate base application from the downloads page, and replace the image or executable. If you have 3.2 or prior, then you'll need the full install, as 3.3 started using VW 7.2 as the base deployment environment. Back up the contents of the btfSave directory before you do anything! If you do a full re-install, you can just restore the files in btfSave, and the btfSettings.ini file after you do so. Enjoy!

Variety has a slew of RSS Feeds - I just subscribed to the TV and movie related ones. Nifty.

This is interesting: VisualStudio effectively creates a runtime image while it operates, in order to facilitate all the features of the IDE:

The reason, though, why you can't turn of background compilation is that the IDE completely depends on it. The information provided by background compilation drives Intellisense, it enables the WinForms designer (as well as all other designers), it fills the dropdowns at the top of the window, it drives the object browser, it enables go to definition, etc, etc, etc. Essentially, without background compilation, the IDE becomes Notepad.exe with syntax coloring. (Coloring, interestingly enough, does not require background compilation because it's entirely based off the lexical grammar of the language and requires no further knowledge of the code.) So that's why we don't let you turn it off.

I'm always intrigued by the fact that large projects effectively re-implement Smalltalk and/or Lisp in order to accomplish the things they need to do. There's a simple way they could take a shortcut, of course... :)

Register for StS 2004 here and hear Paul Baumann talk about SRP:

Introduction to State Replication Protocol (SRP)
presentation
Paul Baumann:
Monday 8:30:00 am to 9:15:00 am

Abstract: SRP is a multi-dialect framework for binary serialization of objects. SRP currently exchanges objects between seven Smalltalk dialects: Dolphin, GemStone/S, Smalltalk/X, Squeak, VisualAge, VisualSmalltalk, and VisualWorks. SRP excels at portability and space efficiency.

An overview and demonstration of the SRP is presented. Participants will understand how to use the framework, how data is encoded for portability, how to customize replication, how to exchange objects, and how to apply various encoding options. Other topics likely to be discussed are portable mapping rules, metastates, remote references, and proxies. Version 3.0 of SRP will be available at the presentation.

Bio: Paul Baumann has developed Smalltalk applications since 1992. He is proficient in code management and in the development of portable frameworks.

See you in Seattle!

Scoble links to a demo of the Kinzan demo. I've had a look, and yes - it's a clone of PARTS. These sorts of things don't scale worth a darn. Not to mention that - even in the simple demo Kinzan has constructed - making the same alterations in a text pane would likely have taken far less time and effort. These things are eye candy, and project managers tend to be awed by them. Until, that is, they have a moderately complex application built with the connection tool that simply cannot be understood any longer. I've got customers who went down that road years ago, and wish they hadn't....

Ryan Lowe comments on my post and on the Visual Studio link that I originally commented on. He's not happy with the way background compilation works in VS:

As for C#'s less than perfect background compiling: I can't stand it. There's nothing worse than editing a file in a *modern* IDE, seeing no errors, then compiling/running it and finding compile errors. It's a complete waste of my time and it only gets worse as the project gets larger and more complex. I know we've come a long way from the dark ages of the command line interface but I'm a new school hacker -- I'm more demanding, I'm writing agile code and I'd rather not wait for: code, complete re-compile, run test suite, code, complete re-compile, run test suite, etc...

That's an interesting problem, and one that "new school hackers" would simply not have were they using Smalltalk. In a Smalltalk system, the code you are creating doesn't need a complex background compilation process - each method is compiled into byte code at the point where you accept (compile) it. That means that you can actually create a test - before the code is written (with said test referring to non-existant code). The system will complain about references to objects that don't exist, but you can let that go. Your test will fail of course - but that's the point (then, at least). You can then start creating the classes and code you need, testing incrementally the whole time

XP came up out of Smalltalk because Smalltalk supports that way of working. While you can use agile techniques in any language, they offer the most productivity in a truly agile language (like Smalltalk). Look at what VS and Eclipse are trying to do - build a Smalltalk-like system. You could actually be working with one, instead of with some second hand, not fully baked copy :)

Variety reports something that makes me cheer - The theatrical release of RoTK on DVD is set for May 25. No word yet on the extended DVD, but that should tide me over....

Register for StS 2004 so you can hear Dan Antion talk about Smalltalk in the nuclear industry:

ANI's Digital Archive
experience report
Dan Antion: American Nuclear Insurers
Monday 8:30:00 am to 9:15:00 am

Abstract: American Nuclear Insurers has been developing a document management system using VisualAge Smalltalk. ANI's digital archive is designed to support both availability of business critical documents in the event of lost or damaged paper documents and broader access to all documents by off site staff. ANI reviewed commercially available document management systems, but they were prohibitively expensive and required a significant amount of effort to prepare and index documents upon submission.

The system can handle any digital document or digital files, such as images, related to documents. In addition, enhanced support was included for business documents based on existing business objects. Once known business documents are scanned, they are pulled into the archive, and the management system creates most all of the index keys necessary. The system also contains a comprehensive search and archive navigation program. A server component handles moving documents in and out of the archive, to prevent people from moving or deleting files outside the control of the system.

Bio: Daniel Antion is Director, Information Services for American Nuclear Insurers. He is responsible for all systems development activities in addition to managing general information technology efforts. Prior to joining ANI, he worked in systems development for several companies. He also worked as a consultant for Coopers & Lybrand and KPMG Peat Marwick, specializing in information systems and consulting services to financial institutions. An enthusiastic fan of Smalltalk, Dan has made presentations at Smalltalk Solutions and OOPSLA

See you in Seattle!

I posted on the MS changes in XP SP2 a few days ago. As it turns out, VisualWorks already does the right thing here. An internal AR (Action Request) was raised, and our VM guys responded:

Turns out we already apply execute permission to the code cache so on the face of it we have nothing to do. However, we in fact apply execute permission to the entire initial allocation the engine makes to load the object memory, which includes not only the code cache but also all of permSpace and oldSpace.

It wouldn't surprise me to learn that most JVM's do the same thing as well.

I've come across an interesting call for papers from a post Java set of workshops. The very name of this event is interesting: 2nd Workshop on Object-Oriented Language Engineering for the Post-Java Era: Back to Dynamicity. It seems that the R&D community in software is starting to realize that Java - and C# - are the last signposts in a dead end area of software, not the heralds of a new way of doing things:

The advent of Java has always been perceived as a major breakthrough in the realm of object-oriented languages. And to some extent it was: it turned academic features like interfaces, garbage-collection and meta-programming into technologies generally accepted by industry. Nevertheless Java also acted as a brake especially to academic language design research. Whereas pre-Java Ecoop's and Oopsla's traditionally featured several tracks with a plethora of research results in language design, more recent versions of these conferences show far less of these. And those results that do make it to the proceedings very often are formulated as extensions of Java. Therefore they necessarily follow the Java-doctrine: statically typed single-inheritance class-based languages with interfaces and exception handling.

That's certainly been the case at OOPSLA the last few years - all Java, all the time - and pretty much none of it new. Instead, it's been a progression of things that had already been learned, but redone in Java. In that respect, the academic world has been echoing the goings on in IT shops during the late '90s bubble - things were redone in Java, and not for any really good reasons. The herd jumped that way, and everyone got behind the herd. Now, it would seem that two things have started to occur:

• IT shops have reconsidered large rewrites as a strategy (the budgets for such things have become very hard to justify)
• The academic world is waking up and realizing that there might be some value in looking elsewhere.

This is all very good news for those of us who have thought that Java represented a sideways step. Yes, the mainstreaming of VM technology and of garbage collection have been altogether good things - I no longer have people questioning their value. However, it's also meant the continuation of a very static approach to systems development. Look at web applications - nothing really new has been invented in that space except in the dynamic arena - Seaside and other continuation based web frameworks have come out of the dynamic language camp (Smalltalk, Scheme, Lisp) - not out of the Java or C# side of the house. All we get from there is masses of XML based "advances" (Struts) that represent a status quo solution to an existing problem. All the new thought is coming from the dynamic niche - which is exactly the sort of problem that people behind this workshop see:

Recent academic developments seem to indicate that a new generation of application domains is emerging for whose development the languages adhering to this doctrine will probably no longer be sufficient. These application domains have recently been grouped together under the name Ambient Intelligence (AmI). The visionary idea of AmI is that in the future, everybody will be surrounded by a dynamically defined processor cloud of which the applications are expected to cooperate smoothly. AmI was put forward as a major strategic research theme by the EU's IST Advisory Group for the 6th Framework of the EU. Meanwhile, the first european symposium on AmI has recently been organised and institutions like the MIT and Phillips have published their visions on the matter. Currently, AmI seems to group previously "unrelated" fields such as context dependency, domotics, ubiqutous computing, mobility, intelligent buildings and wearable hardware. Early experiments in these fields already seem to indicate that their full development will need a new generation of programming languages that have dedicated provisions to deal with highly dynamic hardware and software constellations. As such, AmI will open up a new "market" for a new generation of programming languages which are designed to write software that is expected to operate in extremely dynamic hardware and software configurations. In the past, lots of languages answering this profile have been investigated. Examples are Lisp, CLOS, Scheme, Self, Smalltalk and loads of less well-known academic languages. Give the new constellation outlined above, we believe there is a new future for languages like this. The goal of this workshop is to bring together researchers in object-oriented language design who adhere language features and languages that do not follow the current Java doctrine but adhere more "dynamic features".

Take a look at what's being said there - these folks believe that we need progress, and it's not going to come from the static side of the house. There's progress to be made, but doing so requires a more dynamic style of development than is possible in languages like Java. I have to say, it's nice to hear some validation of the sorts of things that we dynamic language advocates have been saying for years now. With any luck, OOPSLA will start being an interesting show again, instead of "Things we already knew how to do, but have applied to Java".

If you are interested in this from a research standpoint, then follow this link and get involved with the workshops.

Tim Bray noticed something I blipped over the other day. There's been a set of stories claiming that MS is funding SCO's lawsuits. Now, I have no idea whether there's anything to that story or not, although I have my doubts - it's the sort of thing that would look very, very bad to a lot of people - judges especially. The interesting thing is how MS responded:

They went to Scoble to get the message out. I guess that they realized something simple - a net rumor could only be fought properly in the same medium.

Martin Fowler has some interesting observations relating to software developement and how it's impacted by "world view":

• A debate a while ago triggered by Joel's post on exceptions. He didn't like exceptions because they could be misused badly, leading to confusing code (directing). Bill Caputo pointed out that exceptions, when used well, make life much easier (enabling).
• Some of the static/dynamic typing debate brings up these points. Some arguments in favor of static typing talk about how they prevent people from making certain kinds of mistake (directing) while dynamic typers point out how static typing restricts some useful idioms (enabling).
• Agile processes are PeopleOriented (enabling), while plan-driven methods seek to ensure that even a poor team can do an acceptable job (directing).

Martin ties a lot of threads together on a bunch of topics that many people - myself included - have commented on. It's well worth reading the whole thing

In an otherwise interesting article about Sun's plans for RSS use, Jonathan Schwartz apparently felt compelled - as usual - to take a swipe at Microsoft

Gillmor: You mentioned earlier that Microsoft is holding RSS back for some reason. What is that reason?

Schwartz: It's a couple of things. One, the RSS market is relatively nascent. And there are some technology leaders who are going to go deliver their RSS feeds more proactively than others. Is Microsoft missing a huge market right now? Probably not. But it just goes to the prior point that he who controls distribution controls the definition of the standard.

On one hand, I think they're uncomfortable with how much of the RSS standards have been done in the open source community that they can't therefore lock away. And if they take a path, they have to take one that breaks that alliance, and in breaking that alliance - as they've tried to do with HTTP, Java, and every technology they couldn't control - lies some risk for Microsoft. I'm not sure right now they're all that interested or focused on it. I think Steve Ballmer is probably more focused on his pricing in Malaysia than he is on the infrastructure for RSS

I guess Schwartz is unaware of MSDN RSS access. I guess he's also unaware of evangelists like Scoble. But wait, it gets even stupider, with the silliness spreading over to eWeek's Gillmor:

Gillmor: Given that, when will we see some code coming from you that essentially makes it more difficult for Microsoft to ignore RSS?

Schwartz: We have to have that strategy ironed out by the time we announce the developer desktop, which I'm hoping will be within the next few months, certainly not the next few years; this is a this-year activity. And there is already so much innovation occurring in the RSS community 14the number of articles written on RSS today is staggering. Everybody's talking about it. There's Java readers, Mozilla add-ons, Ampheta 26 The issue of when we will make a decision about what we will include in the desktop will be in the same time frame as when we announce our developer desktop.

Somehow, I rather doubt that MS is ignoring RSS and Atom. It wouldn't surprise me a bit to wake up one day and find out that one of the readers that integrates with Outlook (like, say, Newsgator) has been purchased by Microsoft. On the other hand, it wouldn't surprise me if they just let the field develop the way it's been developing. MS is doing the right thing as a content producer with RSS; heck, for that matter, Sun seems to be as well. All I know is, when I hunt around the blogosphere I hear a lot more out of bloggers on the MS side of the aisle than I do from Sun/Java guys. Maybe Schwartz should spend more time trying to get his people blogging, and less time tilting at windmills.

Update: Scoble makes the same points, but with a little more edge.

Sam Ruby's feed validates, but it looks odd to me. What's up with content being in a separate <body> tag instead of in a <description> tag? I can't find any listing of that anywhere as standard. In fact, I went and checked here. Nowhere is a <body> tag referenced as an alternate possibility for <description>. Heck, it's not defined in a namespace, it's just sitting there as something that an aggregator is supposed to magically figure out. This explains why Sam's items are mostly showing up as empty in BottomFeeder right now - valid or no, it's a bad feed

I pushed an update to BottomFeeder last night that deals with the XHTML <body> tag in Sam Ruby's RSS 2 feed. Here's my problem with what Sam's done (apparently quite awhile back; it's discussed here) - it's not sitting in a defined module, and it's not part of the RSS spec. Yes, it's sitting in a namespace. However, it's a "private" module for all intents and purposes, put forth - from what I can glean from Sam's site - because there's some thought that it's "bandwidth friendly", and easier to parse. The former, maybe. The latter? Here's a cluestick - if you have a halfway decent XML parser library, neither the XHTML nor the encoded html is any harder or easier to parse - as an application developer, you never see either one. This is a silly concern over utterly irrelevant technical points. There's also the fact that - as a non-standard extension - aggregator developers are only going to notice this IF they happen to subscribe to a feed doing this, and IF they notice that the content disappeared (which is what I noticed yesterday).

I did a seach on Blogdigger for "xhtml body" - and one on Feedster. Blogdigger brought back 3 results, none of them relevant. Feedster answered zero results. Google actually got me to the relevant blog posts (no pages describing this as a proper RSS Module though). This is a private extension dreamed up by a few people not actually creating aggregators themselves under some delusion that it makes life "easier". Not to mention that all of them are doing it slightly differently - some of them just slapped a <body> tag around the text in <description> - some are throwing out a separate tag, like a module (but again, not documented as such). I dealt with the body tag inside descriptions months ago when I stumbled on it.

Contrast this with something like the Comment API - there's an actual page describing the module - what it is, what it's for, how to implement it. As opposed to this atrocity - described in a few blog postings and foisted on aggregator developers for absolutely absurd reasons. This makes me oh so confident in the eventual outcome for Atom - how many "because we can!" things will end up being tossed into that spec? Or worse, how many won't be, but will start getting used anyway?

Joe Gregorio sounds a little cynical about XML:

Listen closely, in 5 years we'll replace XML with some new whizbang format, and make all the old mistakes in totally new ways.

Sort of like the way XML is a whiz bang format, with a set of interop standards (Web Services) that replaced the former whiz bang format (IIOP) and set of interop standards (CORBA)? Heck, there's even talk of binary XML now. The more things change, the more they stay the same....

Martin Kobetic will be talking about encryption technology in Smalltalk at this years's Smalltalk Solutions. Register today so you can hear all about it!

Cryptography & Smalltalk
presentation
Martin Kobetic: Cincom
Monday 9:15:00 am to 10:00:00 am

Abstract: Recent eruption of security consciousness in the IT industry promoted cryptography from a geeky toy of particularly paranoid computer junkies to an everyday reality for the majority of computer users. Cryptography is just a small part of the arsenal of security professionals today, nevertheless a fundamental one. Thorough understanding and proper use is absolutely critical for any cryptographic solution. Seemingly minor issues can utterly destroy any security properties of an application.

Complexity and misunderstanding is often the culprit behind of all too frequent failures to deliver secure software solutions. Superior expressivity of Smalltalk along with its inherent suitability for agile development methods like TDD provides us with unique opportunity to address many of those issues in an efficient and reliable way.

This presentation is meant to spark the interest of smalltalkers and to motivate them to add cryptography to their arsenal and hopefully profit from this opportunity. It is primarily a practical introduction to cryptography using the Visual Works Security library, but the concepts that will be covered apply to any cryptographic library regardless of the environment or even programming language.
Small "cryptlets" will demonstrate critical properties of various algorithms and techniques. Discussion of practical aspects of a "100% Smalltalk" solution in contrast with alternatives will complement the instruction.

Bio: Martin Kobetic is a member of Cincom Smalltalk development team working primarily on various networking frameworks (Opentalk, DST, Web Services) and the security library. Prior to that he worked on TOPLink for Smalltalk at The Object People, Canada and on various internal frameworks at ArtInAppleS, Slovakia. He presented at Smalltalk Solutions several times on various topics, notably TOPLink, Opentalk and CVST.

See you in Seattle!

Mark Bernstein points to a post by Dave Winer, asking for a merge of Atom and RSS (2.0). It would be a nice thing, and would certainly make things easier on us aggregator developers :) I wonder if the interpersonal politics will prove to be too much though...

I was amazed to read this about Movable Type:

The first problem I ran into was that the process of exporting my existing database and importing it into the new Movable Type installation did not preserve the IDs of entries. Unfortunately, entry IDs are used to construct the URLs of individual posts, which means that all URLs anywhere on the web pointing at specific entries would point to the wrong entry. For about 5 minutes I waffled on whether or not this was acceptable, but then I found these instructions on how to work around the problem.

Modifying the Movable Type source, exporting, putting out-of-order entries back into order, and inserting dummy entries to preserve IDs took about 45 minutes of tedious emacs work. Export/import that preserves IDs/URLs seems like a pretty basic capability.

I'm feeling a lot better about my object serialization scheme for saving entries now :)

Great post on Smalltalk and why developers tend to not "get" it:

That environment-the image-is very different conceptually from how most people program. Most people see programs as a series of files that are compiled and run. There is, underneath even the most extreme of the XP ideas as implemented in Java, etc., the write-compile-run-debug loop that has been inescapably etched onto people's minds.

Smalltalk isn't like that. Code is effectively always compiled, always ready to run, and the debug/run/edit cycles are all blurred together. You can make changes in the editor and continue on from where you are, without having to restart and get back to your original location. It's totally foreign to how people are taught to think about software development. Smalltalk doesn't have phases, and when I write code, I incrementally write/test/explore everything, using a combination of the Browser, the Debugger and the Transcript to do everything.

It's a fascinating thing - more so as tools are now groping more and more towards an image-like state - VisualStudio and Eclipse, for instance, more or less build an image each time you fire them up....

Ian Bicking is somewhat confused about Smalltalk. Yes, Smalltalk looks different than C - but then again, so does Basic (and oddly enough, people seem to be able to use it). Here's the part that caught my eye:

Well, starting from causes, I think Smalltalk's insularity is its greatest flaw. This is in part because Everything Is An Object, and objects have fairly specific conventions. There's a considerable barrier between The Rest Of The World and Smalltalk. It's not just that the syntax looks weird to people -- though that doesn't help -- but it also looks weird to other programming languages. You can't easily map C or other libraries into Smalltalk. You can't make analogous interfaces to the interfaces found in other languages -- you can't even make a freakin' function! Sure you can do everything you need to without functions, but you can't directly map other system's APIs onto Smalltalk syntax, which means you can't map people's past programming experience, or their past programs. (It doesn't help either that Smalltalk's OO nature encourages everything to be a framework, instead of building mere libraries, but that's a topic for a different day)

Gosh, there's so much misinformed confusion there that it's hard to figure out where to start. Too many frameworks and not enough libraries? I suppose this guy has never heard of Taligent or the STL. Everything being an object is a problem? Other than making an assertion, I don't see a real argument in his post. Ahh - here it is "you can't make a function". Translation: "All this object stuff confuses me. Give me a few globals so I can feel safe again!". He then rants about not being able to script Smalltalk or use it to create CGI scripts - first off, I've created Smalltalk images that support scripting on Linux - it's not a huge challenge. The issue here isn't capability so much as culture - Smalltalkers haven't put any effort into supporting scripting, because - for the most part - they haven't been interested. CGI Scripts? I could create one in VW, although having a persistent application server that gets invoked via web server services is simpler and more efficient. I can't run Smalltalk from the command line? Apparently, he hasn't seen any of my Linux server images.

I just love it when people without any recent Smalltalk knowledge make wild assertions like this. I don't spout off about Python or Ruby - due to the simple fact that I don't know a lot about them. I think Ian needs to download a Smalltalk system and ponder it awhile before the next time he lets loose with uninformed silliness....

Update:Patrick Logan comments

Sjoerd Visscher says that liberal parsing is wrong:

RSS and Atom are both XML file formats, they do not accidentally look like XML. Thus according to the XML specification, aggregators are not allowed to try to show broken feeds. If you are doing liberal XML parsing, you are not playing by the rules.

A lot of people are parsing feeds, or are planning to do so. Most of them do so because they want to do something interesting with the data, it might be an aggregator, but it could also be some cool new application. What they certainly are not interested in is the technology of parsing itself. They simply want to use one of the abundantly available XML parsers. Now there are two ways to do feed parsing. One is to only allow proper XML and patiently educate feed producers who do not use the proper XML tools how to improve. (And almost all feed producers are willing to produce valid XML, but they are not helped enough to actually do that.) The other way is to liberally parse anything that vaguely resembles XML and spoil the fun of using feeds for everybody else. If you are doing liberal XML parsing, you are being inconsiderate.

Heh. He's even gone so far as to say he's stopped reading my blog over this. Here's the problem with his theory - it's wrong. And no, I don't really care what the XML spec says. The spec was written before XML went out into the wild. It's out there now, being used by actual people. You know what happens under those circumstances? Errors happen. You know what happens when an end user can't read a feed with an aggregator? Here's a hint - they don't contact the author of the feed, they contact the author of the aggregator. Why is that? Because - from their perspective - it's a bug. You can point to the spec all you want, and it just doesn't matter. Don't believe me? Go write an aggregator, get yourself some users, and then see what happens.

The issue is even simpler - XML is a textual spec. What that means is - in most circumstances - recovery from an error condition is easy, and getting the rest of the document trivial. That's not the case with binary specs - if the people who fuss about XML being a pure spec are really serious, let them go create a binary spec that doesn't allow for simple error recovery. They can also tell me all about the zero end use they'll get

The funny thing is, I actually use a parser that blows chunks on bad XML. I use Smalltalk though, so I've subclassed the system parser, and overridden the error handling as necessary. I have it flag an error and move along. In BottomFeeder, you'll see that as a black bar on the feed icon. In that manner, if the end user is so motivated, he or she can look at the collection of errors, find the contact info (assuming the feed had it) for the author and report it. Contrast that with Sjoerd's preferred world - the application would report an error and stop processing the feed. No more information, no contact info for the feed author, nada. So here's the punchline - he thinks liberal parsing is inconsiderate. Of course, in his world, we simply get inscrutable errors that can't be reported to anyone - but that's somehow considerate. And he says I rant too much :)

Nu Cardboard has a far more pragmatic explanation of why developers stay with their familiar text file based approach to development:

The problem with text files, as with petrol engines, is that they are good enough. We are used to text files. We are trained to work with text files. All our IDEs, OSes and version control systems are geared to text files. Any other system for storing and manipulating source is competing with computing's technological and cultural heritage.

The funny thing is, Smalltalk sources are in files - they just aren't in a bunch of little files stored in a directory hierarchy (typically, although VW's parcel files are a lot like that). On the other hand, it seems to me that tools like VisualStudio and Eclipse are groping in the direction of image based development more and more - it will be interesting to see where they end up as they go that way.

May is just around the corner and Smalltalk Solutions will soon be here. Remember to sign up before April 3rd to receive the early registration discounts. Current STIC members receive a $75 USD discount for the conference. You can easily join STIC or renew your membership while signing up. To register visit:

http://www.smalltalksolutions.com/registration/register.htm

When you register for the conference don't forget to book your hotel. Smalltalk Solutions will take place entirely within the Crowne Plaza Seattle hotel. Make sure to mention you are attending SS 2004 in order to receive the hotel discount. More information can be found at:

http://www.smalltalksolutions.com/hotel/hotel.htm

Keep your Tuesday night open while in Seattle because STIC has planned a fun-filled night at the world famous Seattle Space Needle for conference attendees. We have reserved a banquet room high above the Seattle skyline for you to enjoy. Hors d'oeuvres and drinks will be served starting at 6:30 followed by a delicious dinner and entertainment later in the evening.

This year's Smalltalk Solutions looks like it will be a blast and I look forward to seeing you all.

Thanks, from the STIC team

Register for StS 2004 and hear Bob nemec talk about custom reporting solutions:

Visibility based Report Framework
presentation
Bob Nemec: Northwater Objects
Monday 9:15:00 am to 10:00:00 am

Abstract: Northwater Objects has implemented a custom report writing framework based on Totally Object's "Visibility" product. The framework is built with logical, data, output and print layers. "Logical" is the report specification; 'data" is the specification combined with the domain data; "output" is the data combined with the layout and "physical" is the collection of visibility print command objects. We have also written a user interface for report configuration and diagnostics.

Having the entire report writing mechanism in Smalltalk has proven to be a huge benefit. Our previous experiences with Access and Crystal Reports, while functional, were much more labour intensive and error prone.

The application is written in VisualAge Smalltalk with WindowBuilder and GemStone/S.

Bio: Bob Nemec, Vice-president of Northwater Objects, is responsible for the framework development of an in-house financial application, written in VisualAge Smalltalk and GemStone/S

See you in Seattle!

I've posted quite a bit on why I think Smalltalk is more powerful than many of the competing solutions - now I'm going to toss a few numbers around. One of the fascinating things about the software field is the relative dearth of hard data. Even when there is data, however, many people are more than happy to rationalize that data away. Take this post from 2002, for instance - I can paraphrase the analyst viewpoint this way:

Never mind the fact that our research says that following the mainstream of development will yield dramatically higher failure rates. Being mainstream is all that matters!

The amazing thing is that companies pay huge sums of cash to have unqualified people advise them that way. It's hardly limited to analysts though. Ask a developer how hard it is to learn a new language (software language, that is). I've yet to find one that will say it's a significant hurdle. Now, go recommend to a development manager that project X should use Smalltalk (or some other niche language, for that matter). Suddenly the eyes glaze over - "but where will I find staff?" Never mind that his entire existing staff will tell him that learning a new development language is not a real problem.

But wait - it all extends down to developers as well. I've been pointing to this post (which has been updated here in the past couple of days). "Source code not in a directory tree? Syntax that doesn't look just like C? Heresy!". There are plenty of developers that are stopped cold if the syntax isn't sufficiently C-like, or if they have to do anything differently than the way things have "always been done" (I seem to recall the old auto industry being run clean over by overseas competition - partly as a result of hidebound practices. But nah, that would never happen in software - offshoring's a myth, right?). Well, even actual data doesn't get through the wall of rationalization.

SPR still has the data compiled by Capers Jones on language levels, error rates, and lines of code per function point. The data is instructive, if a little dated (1999). C# wasn't out then, but - I would have to place C# within the same basket as Java. Here's the relevant snippets from their data:

Language	Language Level	Lines of code per Function Point
C	2.5	128
C++	6.0	53
Java (C#)	6.0	53
Smalltalk	15.0	21

Ponder that for a moment (Function Points are defined here). With a little arithmetic, you find that Smalltalk is nearly 2.5 times as productive as Java. You'll immediately run across two objections to this (try making these points in comp.object to see what I mean):

• Function Points are meaningless
• You'll get more errors in Smalltalk due to the lack of manifest (declared) typing

Well, the first point is nothing but a rejection of the data by assertion. This is research that was done over the course of many years; if people want to object to it, they can point to conflicting research. I've yet to see any such argument being made. The second point is commonly made against Smalltalk (and other dynamic languages). However, there are some other bits of research from the SPR documents in this area - it turns out that they measured error rates per function point:

Language	Error rates per FP
Java (C#)	0.5
Smalltalk	0.13

So much for that. The arguments you'll hear at this point hold as much weight as those against Function Point measurement - the assertion will be made that it's all irrelevant, without any attempt to point to research that shows otherwise.

The bottom line is, this is the data we have, and it points in a particular direction. Do analysts pay it any heed? No, the best they can do is count the number of developers and declare winners (they seem to think that this is all Nielson ratings). Project Managers? No, they quiver in fear of finding developers (regardless of what real developers would tell them about ease of learning). Developers? No, they have a magic faith in C style syntax and declared types (It's what we've always done, don't bother us, we refuse to look at contradictory data). This is a large part of the reason that I run this block - it's an uphill battle, but I have to keep pushing the rock up the blasted hill :)

We are releasing a new set of VM's for VW 5i.4, with a number of fixes. Here are the details:

VW 5i.4x Engine Updates

As of March 2004, these 5i.4c engines are the most up-to-date engines for VisualWorks® 5i.x images. See http://www.cincomsmalltalk.com/CincomSmalltalkWiki/VisualWorks 5i.4c engines.

Bugs Fixed over 5i.4b:

• On all platforms, several primitives that had incorrect argument counts have been fixed. These incorrect argument counts could have caused crashes when primitives failed (but only when they failed).
• On all platforms, the oldSpace allocator now uses a sane approach to calculating the free-list probe count. This should improve image-level MemoryPolicy behavior.
• On all platforms, a bug was fixed that caused a crash when using the TimeProfiler due to incorrect stack management in primitive Context>>#terminateTo:.
• On all platforms, a bug was fixed that caused a crash in the debug and assert engines when using the check-mark mechanism to verify the incremental collector when running with -o11s (aggressive assert checking).
• On IA-32 platforms (Windows® and Linux86), these engines fix a performance problem with floating-point primitives on dual Xeon processors. Floating-point performance is about 4.8x faster.
• On UNIX® platforms, signal handlers now use significantly less stack space.
• On the SGI® platform, "dirty sends" have been enabled, improving Smalltalk execution performance by about 5%.
• On the Windows platform, a bug was fixed that caused attempts to open files larger than 4 Gigabytes in read-append mode to not seek to the end.
• On the AIX® platform, the translated floating-point primitives have been implemented providing almost a factor of two improvements in floating-point performance.

Bugs Fixed in 5i.4b and 5i.4c Over 5i.4:

• On all platforms, a bug was fixed in the \\ primitive.
• On all platforms, a bug was fixed in context management during non-local returns that would occasionally cause crashes.
• On all platforms, a bug was fixed in the code generator that caused | i | i := 2. ^3 between: i and: (i := 4) to return false.
• On all platforms, a bug was fixed whereby doesNotUnderstand: method lookups were not being flushed when requested.
• On all platforms, a bug was fixed in the translated floating-point primitives whereby aFloat op anInteger would return different results to aFloat op (anInteger asFloat).
• On all platforms, a bug was fixed that accused the snapshot primitive to incorrectly save the free list, causing a crash on image load.
• On all platforms, a bug was fixed that would cause a remembered-table overflow on loading a perm-saved image, causing the image load to abort.
• On all platforms, a bug was fixed whereby code referencing new literals might not be correctly scavenged, causing a crash.

On all platforms, a bug was fixed whereby shrinking oldSpace could corrupt the list of oldSpace segments, causing a crash. On all platforms, long-long access primitives were added, improving the performance of [unsigned]LongLongAt:[put:].

• On UNIX platforms, a bug was fixed whereby attempts to list the contents of directories mounted over nfs would return an invalid list of files.
• On X11 platforms, a bug with fetching and storing the text selection was fixed.
• On Windows platforms, the priority of the IO poll thread was corrected.
• On Windows platforms, bugs with zlib decompression of images were fixed.
• On Windows platforms, bugs with 64-bit file access were fixed.

Customers with support should already have received an email to this effect, but I know how many spam filters kill automated emails (even those that are actively being subscribed to).

In my last post on this topic, I alluded to the rise of offshoring, and how it sounds an awful lot like an echo of what happened to manufacturing years ago. Now I see that Dan Gillmor of ComputerWorld is writing about that topic:

I never entirely bought their faith, though the Valley has repeatedly shown an ability to rebound to new heights after deep economic downturns. The recent evidence, notably the surge of offshoring, makes me ask again -- about the Valley and the entire nation.

And I wonder if something is genuinely different now.

Intel CEO Craig Barrett put his finger on it a few weeks ago when he stopped by my newspaper for a long chat with some reporters and editors. What's new this time, he told us in a persuasive way, is the nature of the global workforce.

For the first time in human history, Barrett said, a truly gigantic pool of well-educated, technically adept and eager-to-please labor is being created. This pool of talent, which will include hundreds of millions of people in China and India (many of whom speak English fluently), has another characteristic: a willingness to work for a fraction of what Americans expect.

This is not because they like living poorly. It's because local conditions and currency exchange rates make what would seem like a pauper's salary here a highly attractive one there.

Well, this can go one a few different ways. American development shops can keep doing what lots of developers think is "good enough" - unproductive languages that hinder more than they help (Java, C#, etc). Code in files, and the old "edit-compile-link" cycle. If that's the way people go, then they will be screwed - overseas competitors can use unproductive tools and heavyweight processes (CMM-5, anyone?) at a fraction of the cost. The results won't actually be any better, but boy, will they be cheaper. And since the level of competence in IT is so low now (just go look for IT project failure rates; the numbers are not improving), getting the same crappy results for a lesser dollar amount will be seen as huge progress

Now, what have people done in the past to overcome this kind of thing? They've gotten more agile (like some of the newer steel companies in the US). Now look at software shops - asleep at the switch, using unproductive tools and languages - and they act utterly astonished when jobs get moved overseas. Is there any awareness of the higher levels of productivity available from agile processes (see the Agile Alliance site) and dynamic languages (see the numbers I posted here? Heck no, there's a dogged insistence that all is well, and that doing the same old things in the same old ways will be just fine. Never mind that offshore developers can do those same old things at a fraction of the cost - apparently, Alfred E Newman is alive and well, and living in most US development shops

If you want to keep working in this field, you're going to have to take a hard look at what happened to auto (and other manufacturing) jobs in the last 30 years, and at what kinds of changes had to be made to keep US shops competitive. Here's a hint - it didn't involve doing the same old things in the same old ways. It's well past time for developers to look for more productive ways to work - both in the process area (agile) and in the language/tools area (dynamic vs. static). I think Gillmor is more pessimistic than he needs to be - but there will be a large jolt in this sector, and everyone who is cheerfully wedded to the mainstream is in for the biggest set of shocks....

For those of you with rather large hard drives, this is a use for XML I bet you hadn't considered:

I saw an article on TSS labeled "Thread dumps as XML," and thought to myself, why couldn't byte code be done as XML? So I built a custom JVM and converted rt.jar to my new XML byte code format. Now, this might seem an impossible undertaking, but fortunately I had some extra hard drive space. My new rt.jar is 620GB, but the class files are all human-readable now, and it's really nice to be able to edit them in Notepad

I don't know whether to be impressed or scared :)