Smalltalk Tidbits, Industry Rants

Well, that wraps ESUG 2004. It's been a good two days - I wish I could have seen the first two. I'll be linking Niall's and John's reporting as I get it. On to Camp Smalltalk, and then home.

Stephanne Ducasse and Michele Lanza are behind Moose - one of their grad students, Tudor Girba is up to discuss Moose. It was started in 1997 at the University of Berne. So to start - we define some basic terms.

• Re-Engineering - you go from idea, to design, to code. As time goes by, you end up losing the original structure and cleanliness. Re-Engineering is the process of getting back in the right direction.

A high level view (i.e., a class diagram) does not qualify as reverse engineering. Moose is a re-engineering tool. It can be use to create metrics, do evolution analysis, and show diagrams of the code. The basic metrics can answer questions like - How much code, how many classes, how many methods per class, how many lines per method, etc.

Visualization can provide a quick overview. A spatial orientation can give you a quick look at what you have, allowing you to use other tools once you focus in.

Evolution analysis looks at how the code evolved (how did we get from there to here. History can tell you which parts are change prone, and can tell you how you arrived in the place you are at now.

Moose is a VisualWorks tool. By selecting a specific version of the code (a model), we can examine various aspects of the system. Moose is an environment for re-engineering. It can work with C, C++, Java, Cobol, VisualWorks Smalltalk, and Squeak Smalltalk. It could be extended to deal with other languages as well. It's available under the BSD license (free). It's research driven, but has been validated in industry. The rest of this presentation is a demo - you can get a lot of that information at the website - and you can download it here

Up next - Markus Denker on AOSTA. Markus is doing this work for Squeak. We already have JIT systems for the commercial systems, and even an (unreleased) JIT for Squeak. What this is about is "hotspotting". This is all done at the Smalltalk level, using the profile information created by the JIT compiler. The system would compile to optimized bytecode, but get turned off for debugging purposes. The main areas:

• Profiled execution of (unoptimized) areas from the JIT
• Collect type information from the PIC (Polymorphic Inline Cache). Needs to be readable at the Smalltalk level
• Inlining (from the above)

Where is it? The design is done, but not tested, The bytecode transformations (to SSA) is done, and works in VisualWorks. The backend - a transformation out of SSA is being done now, with a simple code generator (In Squeak - works with some examples now). SSA stands for Static Simple Assignment.

Two steps:

• Deconstruct the SSA
• Generate Bytecode

The main problem that can crop up is that some optimizations end up with wrong results - you need to fix that up - which makes the algorithm more complex. There's an answer to this called the Phi-Congruency Method.

To do - lots - dynamic deoptimization (for debugging). Possible experiments:

• AOSTA for Squeak with a JIT
• Does it make sense for an interpreter?
• Exupery as a backend?

With a byte code to byte code translator, what else is possible?

• Enables more late binding
• An API for changing the language semantics and implementation at runtime (for example, the meaning of inheritance)
• Squeak has MetaClassTalk, but it's slow
• iVARS are accessed via offsets
• offsets calculated at compile time
• makes changes and experiments harder
• Make a MOP more practical
• Allows a much simpler system

Bottom line - could enable a lot of things that aren't (directly) related to performance.

Petr Stepanek is talking about Gemstone, and comparing it to relational technology. So - starting with the object model. If you are using Smalltalk, then you have one - the example in this case is a call center (CRM) system. The problem is that the underlying data (object) model is not immediately known, and will be changing over time. This customer wants live development on a 24x7 system. They have looked at various commercial CRM systems, and have not been impressed - so they opted for a custom system.

Live Development, constant change to a running production system (you mean, that thing that critics like Isaac says customers don't want?) - that's what they want here. They did a fair amount of reading for possible solutions, including the ValueWithHistory idea put forth by Kent Beck - where you use Decorators on objects instead of instance variables. They ended up with what they call a Linked Object Model (if I can get a copy of the presentation, I'll post a link - there are some pictures on the slides). In general, they have a "cloud of data" with various links between the objects. They use a Node class which holds links between objects. They ended up with the following rough choices (the picture of the object model is complex :)

• an RDB with two huge tables (Links and Nodes)
• plus additional tables for Node subclasses
• Or an OODB (they selected Gemstone)

So how do you get at the data to change it - write accessing methods!

Setter

Link new
	node1: aPerson;
	node2: aName;
	meaning12: 'name';
	meaning 21: 'person';
	hook

Getter

^OneLinkTraverser new
	node1: self;
	meaning12: 'name';
	validAt: Timestamp now;
	node2.

Slower than direct accessors, but they have been able to deal with that. They keep links in Gemstone, and they implemented the OneLinkTraverser class (etc) in Gemstone (so that it runs on the server). They have also implemented aggressive caching. The pros and cons:

Cons

• Complex - not immediately obvious or "natural"
• Confusing - inspecting is complex (solvable with Trippy in VW via #inspectorExtraAttributes) - not solvable in Gemstone

Pros

• Less work - no idea how they could do this (well) in an RDBMS
• Past data handled same as current data
• May change model with no GS class migration on a live system
• High chance of committing transaction in GS
• Can still use GS indexes.

On the business side, this is great for complex models that change over time - which this one does. Past data is important, and easily accessible. Fast responses for requests from any direction are supported in this model, and that's critical in this business.

I arrived a little late this morning, and found Avi talking about Seaside and web applications. This is actually the same talk he gave at Smalltalk Solutions 2004, so I'm going to sit back and enjoy the talk this time.

I noticed this morning that MS is longer providing full content in their RSS feeds, and I commented on that here. Since then, I was told that the MSDN site supports both mod-gzip and conditional-get - and that they still had bandwidth issues. I was skeptical, to say the least. So, I fired up a VW image and tried the following:

HttpClientModel get: 'http://blogs.msdn.com/MainFeed.aspx'.

I stepped through the request in a debugger, so that I could see exactly what happened. Sure enough, the request asked for compressed content - but did not receive it. I got back a textual response with the feed's contents. As I stepped through, my code cached the necessary information for a future request (i.e., the requisite information for conditional-get). Then I immediately executed the same request. Still not compressed content, but another surprise - the exact same response (i.e., same content) - not a 304. So, color me unimpressed. The problem isn't with RSS, and we don't need some snazzy updated version of nntp. What we need is for someone to provide a cluestick to the people behind msdn blog feeds. To see a large number of people who are unclear on the concept, read the comment stream from Scoble's post

Carsten Haerle is talking to us about Smalltalk in teacher support. Schools may have hundreds of PCs and thousands of users, with many applications to install and manage - typically without a dedicated system administrator. This leaves the task to teachers, who are also trying to teach the students. Another problem is making PC's tamper proof - including the ability to roll back to a known state after each class. There's also the need to do internet filtering, and make sure that the same content is displayed/transmitted to each PC.

They wrote an application Beno which integrates a few other (non-Smalltalk) Windows applications: DX-Union - that handles deployment issues - management of what should be where, etc. Another application - Dr. Kaiser - makes PCs tamper proof. NetO handles screen transmission, and Cobion/Time does internet filtering. Beno is an integration platform for all of these applications. This created a single point of interaction for all of the supported functions. So, now comes a demo - something that doesn't come across well in a blog :) What he's showing us is how you can use Beno to push an installation (In this case, the Google Toolbar) out to a set of managed PCs.

It's a cool and useful suite of applications - written in Dolphin Smalltalk. They are the biggest distributor of this kind of software in Germany. Why Smalltalk?

• Cost savings in Smalltalk
• Faster Development
• Better Diagnostic capabilities
• Able to do this with a 6-7 person team - could not have done that with VB or C++ or Delphi

Unlike a lot of Smalltalk applications, this is a shrinkwrap application, and they are likely going to get MS logo certification. Which Smalltalk? Dolphin, which they consider to be the replacement for Digitalk Smalltalk.

Update: I made some corrections to the text based on an email from Carsten.

Christian Haidar is talking about how his company uses Smalltalk to build products - including development, marketing, and pricing. He started with a contract to build a simple chart program He built a system he called smallCharts in 3 man months over the course of a year. That went well, and the system went into production. As a result, he trademarked the term smallCharts. He then got a contract to build something similar for the parent company - so he founded a company and got the job done in a few months. He's now gotten a second contract for his new company. What did Smalltalk have to do with any of this?

• He did the project only because he could use Smalltalk
• Change requests that came from clients were quickly addressable
• The ability to explore external data sources (stock market feeds) dynamically (see this post from Bruce Badger - it's the same idea).

What's different about running a small company? Worrying about profits, dealing with people (negotiations), Organization, partners, bureaucracy (of prospects, and of your own). Small stuff - company logo, website. It has to get done :) Other things that come up - professional delivery, testing, bug tracking and support - it stops being a pet project on sourceforge and starts being a product. What about marketing?

It was easy when he had one customer. After that, it took legwork. He had to get his message out to decision makers and use word of mouth - get both himself and his product known. All the things that engineers in a large company rarely think about :) Then there's the whole problem of pricing - rental, license, what? Figuring out who the competition is isn't always as easy as you might think.

So what were his early mistakes? Lack of marketing, and an under-estimation of how long it would take to build things. Even more critical, he underestimated how long a prospect would take to make a decision.

DB Systems and Daedalos Consulting are telling us about their train scheduling system for the German railways - they call it RUT-K. The system (rail) is big - 40,000 passenger and freight trains, 65,000 kilometers of track, and 8500 crossings and switches. The trains run at different speeds to different stops. There are 400 users of the system in 7 offices across Germany.

Managing a train schedule is like putting together a huge puzzle

The system handles:

• Exact construction of train paths
• Timetabling by train
• A structured database holding multiple versions of the timetables (with variants)
• Distributed data storage and data editing capabilities

The system allows for interactive development of train paths and schedules, with user inquiries answered by possible answers. The inputs are the objectives - train path and stops (including times), as well as the actual circulation of the train. The system creates a detailed timetable without conflicts and calculated running times. Potential conflicts in a user's desired path/schedule are displayed , and the system supports graphical editing of train paths and schedules. Reports for this can all be generated.

The system has to generate these visual schedules quickly, and detect (and make users aware of) conflicts rapidly. They managing hundreds of MB of data in the client application. They have gotten some smart people on board to define appropriate algorithms for solving these problems in code - successfully. The system is client/server, using Oracle as a back end. The development environment has migrated from VW 3.1 and Envy to VW 7.x and Store. They also have an offline version for laptops.

RUT-K is not the only Smalltalk application used in the railway system - their scheduling/planning system and some of their back office systems are also done in Smalltalk. The system has been deployed since April 2003. Why has it been successful?

• User involvement at all points
• Detailed specifications
• Short development iterations
• The organization and team
• Smalltalk
• Reuse of components across applications
• Easy build process
• Powerful class libraries

I've seen the application in their offices, and it's very impressive. We are seeing a demonstration of the mobile version running on a laptop with test data. I'll have to see if anyone with a digital camera has shots to post.

Niall Ross is talking about the value of Smalltalk - in the context of JP Morgan's experience with VisualWorks and Gemstone in the Kapital project. What is Kapital? Kaital is a risk and value management system. It deals with complex financial products and figuring out their actual value so that buying and selling can be done profitably - in other words, you don't want to offer a product whose value statement is "take my money". It's used in three ways:

• batch jobs - run overnight, all night, every night. This derives a map of possible risks
• interactive - the traders manage their books, value trades, etc
• housekeeping - weekend runs clean data, archive, verify, do sanity checks, etc

Kapital has a team of 30 developers and 500 end users across New York, London, and Tokyo. Ultimately, it's the enabler of $Large revenues for the investment bank. Niall had to remove the actual number :)

So why does it matter that this is done in Smalltalk? Kapital is a very hard problem. The issue here is simply delivering any system at all. The domain requires a meta-model in order to actually define the financial systems being modelled:

• All objects can value themselves
• All objects can walk their graph to explain themselves
• domain models are in VW only; GS is a memory extension

It took 1.5 years to get the models right. The reason Smalltalk fits for this is that meta-modelling is so easy in Smalltalk. The domain in this business is rapidly changing and unfixed - which makes it very hard to deal with in more static systems (e.g., Java). Kapital survived by delivering value early. Smalltalk enables meta-modelling because the meta model of Smalltalk is available - everything is an object, and there are few reserved words. Nothing gets in the way. For instance - the lack of (static) typing removes the obstacles that would otherwise stand between the developers and the models.

Kapital survived the PPS/ObjectShare meltdown, and got past the Gemstone/Brokat problem as well. Management was nervous, but the traders needed the value that the system delivered - there was too much money at stake to stop development for an N month/year migration effort, during which no updates would happen in the existing system. Smalltalk allows the developers to work very closely with the traders. Example:

• New financial product (can't say what) was introduced
• Every client of every investment bank asked for it
• For a (longish) period, only JPM could offer it, because they were the only bank that could actually handle the new product with their software systems
• Result - JPM gained 100% of the business during that period, which helped drive new client relationships
• Competitors got into this with expensive staff increases and dodgy spreadsheets - Kapital managed to expand with small amounts of new code

Rapid delivery has distinct value in this space. Another benefit is scalability. The Kapital system (over 10,000 classes) is delivered to traders as an unstripped (i.e., as a development image prepared for application use). This means that production problems that are unique to production runtime issues can be found, debugged, and fixed. Performance has never been an issue that they could not overcome. Smalltalk has allowed them to figure out real bottlenecks with full tool support.

Re-engineering is far, far easier because everything is available and accessible. An example:

• Kapital started with 200 financial time series objects (curves). Now has 70,000
• retrieving their keys (descriptors) began to slow an important UI operation. Users were unhappy
• re-engineered to use lazy synchronization for this
• Re-engineering this core part of the product was easier because there are no hidden bits, no final classes, etc - everything is open

Another thing that is easier is data migration. The domain model changes over time, and this has to be managed. Data is lazily migrated as it's loaded from the persistent store, and then saved in that state as necessary. This means that they don't need to do explicit schema migrations that stop operations when new revs come out - it all happens automatically. This means that developers can run the latest codebase agaiinst copies of the production database without having to upgrade everything. Data upgrade on release takes less time.

What would they like to do better?

• They would like to have performant meta enabled collection classes
• Would like to more easily find and get rid of dead code. In a 90 MB image, they think they might have 20MB of it
• Same problem with dead data
• Like the rest of us, they would like to enforce better coding standards

More information: A press release and some more information

I see that Synchrony Systems has a partner in Europe - Tricept. I'm hearing the same "modernize your Smalltalk application by moving to Java" pitch that I heard at Smalltalk Solutions. There's an interesting problem here, but it's not the one you think I'm going to bring up. One of the big pitches here is that you'll need to take your old client/server application and make it into a server based application. Yeah, that'll work.

Back in the old days, ParcPlace had a pitch like this when we released VisualWave (in 1995). We told people that you could just load Wave, and bingo - your old application would be instantly web enabled. It's not that easy. Client/Server applications tend to have a huge number of single user assumptions baked in, and transforming an application to be server capable is not a matter of changing look policies (widgets to HTML widgets), or translating from Smalltalk to Java. It's fundamentally about rewriting your application.

When you hear someone pitch you on the notion of using tools to "modernize" your Smalltalk application (i.e., move it to Java and make it server aware) - you need to understand just how deep the money pit is that they want you to fall into. It's not a surprise that the people pushing this represent service companies that bill by the hour :)

I missed the first day of ESUG 2004 - I was enjoying the labor day holiday. However, John McIntosh was taking notes! Enjoy.

Martin Fowler explains what a closure is. It's a valuable explanation for non-Smalltalkers who keep hearing how useful they are :)

Don Park links to Scoble explaining a problem at MSDN:

RSS is broken, is what happened. It's not scalable when 10s of thousands of people start subscribing to thousands of separate RSS feeds and start pulling down those feeds every few minutes (default aggregator behavior is to pull down a feed every hour).

Bandwidth usage was growing faster than MSDN's ability to pay for, or keep up with, the bandwidth. Terrabytes of bandwidth were being used up by RSS.

So here's my set of questions:

• Do the MSDN feeds support conditional-get?
• Do the MSDN feeds use mod-gzip?

If the answer to either one is no, then the problem isn't RSS - it's with Microsoft. So which is it?

One of the persistent theories you'll see bandied about is this: "You can make up for low prices with volume". This works in one of a few circumstances:

• Even with the low price, you are still profitable - i.e., you are willing to trade a level of profit margin for increased market share.
• You have enough money that you can afford to take a temporary loss in a business in order to drive out your competitors. You'll then recover by raising prices back into a profitable range
• You have a loss leader that drives other (profitable) business. In this case, you are willing to lose money in one area because the gains elsewhere (directly or indirectly driven by the loss leader) are larger than the loss

The key thing is that one of those things has to be true in order for a losing business to make business sense. Microsoft follows a loss leader theory with their development tools, for instance. They really don't care whether they make money from their development tools, so long as their adoption drives sales of Windows (the OS) and Office. IBM uses Eclipse as a loss leader to drive sales of things like WebSphere and their services business. Various airlines have lowered prices dramatically on specific routes in order to drive a competitor out of that space - afterwards, the prices rise back into the profit zone.

And then there's Sun. Sun's business depended (and still depends) on the sale of Sparc based hardware running Solaris. What that means is that anything which commoditizes hardware is a net negative for Sun. This is obvious to anyone who's paying attention - which apparently doesn't include Jonathan Schwartz:

As I've said, I'm a big believer in the idea that volume wins. And we invest (much to the occasional befuddlement of our friends on Wall Street) to support that thesis - most notably in the propagation of our programming platform, Java.

And in the J2ME mobile handset platform, the dividends are beginning to appear - in the form of the single most popular platform those devices have ever seen (as measured, of course, by volume - which happens to be a handy precursor for revenue for every network service imagineable). That volume begets more volume, more licensees, more apps, more infrastructure. And so forth.

There's a reason that the Wall Street crowd is befuddled by Sun's investments - it makes little business sense. Look at what Java has achieved - the platform no longer matters. Want to build an application server? It'll run just as well on commodity intel hardware as it does on Sun's expensive hardware - which leads to a drop in sales volume for that expensive hardware. This is clear as day - commoditizing the platform has been a godsend for IBM, and ruination for Sun. Mobile phones? Is he kidding? First off, the margins on sales of those are tiny, and second, Sun isn't building them. Maybe JVM licenses are profitable there, but only for a much smaller company. Look back at my initial three reasons for selling at a loss:

• Is Java leading to higher sales of Sun hardware at lower profit margins? Clearly, so
• Is Java causing temporary losses as it drives other companies out of the field? Umm, no. IBM is cleaning up, and Sun has virtually no presence at all in the software (applications) field
• Is Java a loss leader? In a sense, yes. Unfortunately, it's a loss for Sun, but the beneficiary is IBM. This isn't a long term help for Sun

Volume really isn't enough, unless it's part of another strategy. For Sun, volume seems to be an end in itself, and that's why Wall Street is unimpressed.

There's WiFi here at the conference itself, but I was unable to get dialup working at the hotel last night. It looks like I'll be connected only during the day. There's a busy schedule of evening events, so maybe that's ok. I'm not speaking until tomorrow, so I can just sit back and listen to the business track today. Right now we are hearing Monika Laurent (Cincom marketing) talk about business and technical marketing as it relates to Smalltalk.

I am finally back at the hotel in Koethen. I arrived in Frankfurt at 7 am (local time), and got a ride up here with one of my colleagues in the Frankfurt office. That was a long ride - 4 hours. We got here about noon, just in time for a scheduled social outing. We headed out to a railroad museum located near one of the old East German coal mines. The trains and tenders there were fascinating, and the tour guide did a very good job, even though he spoke very little English. Lots of cool machines there. We also had some coffee and cake, which I definitely needed after the long flight and drive.

From there we went to the site of one of the old coal mines, which they are now calling "Ferropolis". It was run by the former government until reunification, when it was shut down. It was a massively inefficient strip mining operation - 1/3rd of the power generated was used just to power the mine itself. It was also brown coal, which apparently burns very dirty. They are in the midst of a large cleanup, and the mine is being filled in as a lake - it should turn out quite nicely once they get that done.

There were some truly large machines they had preserved - they had been in the mine itself, but had been conveyed out for a large scale monument to the past. They ranged in age from 1944 to 1986 - that last was one of the most rusted out, oddly enough. The machines are ranged around an arena, up on platforms - they now have concerts down there (Metallica has played there, appropriately enough). They are refurbishing some of the offices to act as discos, and trying to make the surrounding area into parkland. All in all, an ambitious plan for one of the "rustbelt" areas of Germany

Then, we headed to the Wurlitzer park area for dinner. Alan showed a few people his progress on tools for Store using GLORP - including the ability to read a Store repository from a VA Envy image. Very nifty. We had a good dinner and pleasant conversation, followed by a (late) walk around the town and lake. The trip back to the hotel had a delay based on some kind of traffic problem (an accident?), but we got back here just before 11:30. A full day, and I'm definitely ready to get some sleep. I'll be taking notes during the sessions tomorrow, and there's supposed to be WiFi access in the conference room. We'll see.

Give people a gigabyte of storage, and who knows what they'll do with it. Over on slashdot, we see that someone has written a blog server on top of gmail. Sometimes, the most fascinating uses of a technology are the things it wasn't designed for...

I'm leaving late, but I'm off to ESUG in Koethen, Germany. I'll be there for part of Camp Smalltalk as well; I don't leave for home until next Sunday. I've missed 2 days of the conference, so I have some catching up to do - better late than never. I'm hoping that the remnants of Frances don't screw with my flight plans - the leg to Germany leaves from Charlotte, NC this afternoon (4:30 pm). Crossing my fingers on my way out the door...

A few of us got to talking about Sun, IBM, and Java on the IRC channel, and here's what came out of that - this may well qualify as "you had to be there", but anyway:

[22:55] <michaell> what sun did was this. They built their own kind of microwave, made lots of them, put them in stores all over the country, then gave them away for free. Every other microwave company that didn't have locked-in customers gets hit hard, but demand for the free microwave can't be met and people who already have microwaves that work don't need a new one yet

[22:56] <jarober> what they did is give IBM a stick to use, and then they bent over to get beaten

[22:56] <michaell> every one that didn't have a microwave "because it leaks radiation" suddenly jumps in and grabs one, because it's free

[22:56] <michaell> then IBM comes along and says "We can service your free sun microwave for only $10000"

[22:57] <jarober> heh

[22:57] <michaell> so people turn to sun and say "We didn't pay anything for this microwave and now we have to pay IBM $10000 to fix it when it broke because you used dodgy parts." To which Sun replies, "Can't talk now, building another batch of microwaves to give away."

[22:58] <michaell> So then microsoft comes along and says "Well, how about you buy our microwave at a market reduced price and we also support you, for $1000". So people buy Microsoft microwaves, forgetting all the old microwaves that were only $50 still work just as well.

[22:59] <michaell> That flooding of the market is like walking in to a market place where vendors are trying to sell their wares and pulling out an electromagnetic powered loud speaker and talking over every one, then shutting it off - every ones ears are ringing so no one can sell anything there any more.

In that chat, this is michaell.

This panel discussion at OOPSLA has gotten Alan some attention - his blogged has been linked off of the msdn architecture site (scroll down to the OOPSLA links - the one that mentions the J2EE vs. .NET shootout). Go Alan!

The Register reports that the UK's navy is going to use Windows as the platform on some of their ships - including ones that carry Trident missiles. Color me unimpressed with that choice....

Joseph is giving a talk on the future of Smalltalk today in Basel. If you're nearby, check it out

Bruce Badger explains how to be truly productive.

I've got the conversion from the Http-Access codebase over to the cleaner NetResources package (both in the public store) done. NetResources is a cleaner, simpler network layer - it's removed all of the Http stuff from my code and sloughed it off to the library (where it belongs). I've not completed the testing, but the early results look good. Next, I can start on the Twoflower to WithStyle conversion. Once I'm comfortable with that, an improved BottomFeeder will be available. It'll require a VM and Image replacement; in addition the library changes, the new version will be based on the recently released VW 7.2.1.

With interest in Continuation based web applications growing, it's a good thing that I stumbled on this Seaside tutorial on the CST wiki. The spam that some moron added to the bottom has been removed, so have a look!

In this post, I talked about how MS' security model is still too little, too late. Take a look at Steve Wart's comment - he makes an excellent point:

Check out your referrer spam -- even the most obscure blogs are getting thousands of hits a day. Do you think these companies are doing this manually? "0wners" of the zombie nets will let you get your URL added to thousands of web sites for a small fee.

That's why this happens. The early stuff was pranks - it's business now.

Jonathan Schwartz does it again. In a great exercise in hand waving, he says this:

Sun is not a threat to GNU/linux. Innovation is not a threat to GNU/linux. dTrace is not a threat to linux. Nor is Solaris 10, nor Janus. Nor is our new comp plan.

Well duh. Now, Is Linux a threat to Sun and Solaris? Look no further than here, and make sure you notice what Sun's number's look like without the MS sugar money. I wrote about that here. Michael Lucas-Smith has some related comments here.

Chris Petrilli has a cogent observation in the comments to this post from Ralph Johnson:

That's the trouble with what's going on in the curly bracket world of programming. People want to play with the language, where as Smalltalk and LISP are so simple as to allow you to do almost anything you can imagine, use any paradigm you can dream of, make any bizarre control structure you could ever want, without changing the language. Whether it be the pure messaging syntax of Smalltalk, or LISP Macros (which are even more powerful than people can imagine), you can do just about anything. Why are people so obsessed with a new language? New does not, by default, equal better. It simply is new. Different. People built cars with all kinds of weird transmission designs, push buttons, etc., but eventually everyone figured out that one design worked better. The problem is that all the other languages are trying to to catch up with Smalltalk without realizing that they don't need to ADD features, they need to take stuff out.

Sometimes, Less really is More...

Here's a guy blogging from Melbourne, FL - as Frances crawls it's way towards him. What they heck is he still doing at the shore?

Cincom and Daedalus have entered into a new strategic partnership that will allow Daedalus to take advantage of Cincom's powerful development environment, VisualWorks. Daedalus, currently based in Lisbon, Portugal and with operations expanding to Brazil, is one of the leading developers and manufacturers of the Geotaxi System, a premier dispatch and fleet management system used for taxis and other vehicles-for-hire.

See the Press Release here

Bob Congdon points to a recipe for Twinkie Sushi. That's just... not right.

Jeff Eastman asked me to post this, as he's looking for feedback. Let him know what you think:

Windward Solutions is conducting a research project to understand the current Smalltalk market and how newer technologies such as Java and the Web are impacting customer commitment. We are seeking information from professionals working in the field and from companies that are employing Smalltalk and related technologies. If you have recently worked or are working in the Smalltalk space we solicit your assistance. We have posted a brief market survey at (http://www.windwardsolutions.com/smalltalksurvey.htm), and it should not take much of your time to respond. We will make the results available to all who contribute to it.

ComputerWorld has a disturbing article on the links between organized crime and virus/trojan attacks:

And what was happening, according to Hypponen, was the beginning of a concerted, unabashed effort to turn virus and worm infections into cash.

Eight days after MyDoom.A hit the Internet, somebody scanned millions of IP addresses looking for the back door left by the worm, said Hypponen. The attackers searched for systems with a Trojan horse called Mitglieder installed and then used those systems as their spam engines. As a result, millions of computers across the Internet were now for sale to the underground spam community.

There's a lot more - including this scary anecdote:

Hackers and malicious-code writers are increasingly automating the Internet shell game that keeps many of them one step ahead of law enforcement. The Kuwaiti hacker group Q8See is a case in point.

On March 8, a Russian source reported to F-Secure analysts the existence of a Trojan horse created by Q8See called Slacke. But what made Slacke unique was the extraordinary lengths to which its authors went to hide their tracks and the mystery that remains about the group's intent.

First, the worm downloaded code from a Web site hosted in Sao Tome and Principe, a small island nation located off the Atlantic coast of Africa. Analysis by F-Secure, however, showed that the domain rights for the Web site had been sold to a company in Sweden. But registration information listed the company name as JordanChat and the location as Irbid, Jordan. The contact name was TeR0r.

As thousands of infected computers downloaded the malicious code from the Web server in Sao Tome and Principe, they were then linked to an Internet Relay Chat system operated by CNN in Atlanta.

Once logged into CNN's IRC server, the systems connected to an IRC channel in Mexico called Noticias. And when Hypponen and his analysts studied the channel, they were astonished at what they saw.

"There were 20,000 clients just sitting on the channel doing nothing. They looked like people, but they were bots," he says, referring to programs that perform repetitive, automated functions.

The bots, however, weren't alone. According to Hypponen, three Kuwaiti users, presumably members of Q8See, were sitting on the channel and sending commands to the bots to scan various ranges of IP addresses. And while CNN eventually shut down the chat server, nobody knows for sure what the hackers were doing.

Scary, to be sure. In light of that, read what Dan Gillmor has to say about Microsoft's "security":

If you buy a new Windows PC for your home and hook it up to a DSL service or a cable-modem line without first installing a hardware or software firewall, your computer could well be compromised by hackers before you've even had time to install Microsoft's "critical" security updates.

The PC may be turned into a spammer's toy, a zombie spewing thousands of mail messages per day, some of which could clog corporate networks. Or, worse, it may now have a keystroke logger in place, snarfing up personal and corporate log-ons and passwords and sending them who knows where.

This is a clear and present danger to corporate networks. If an infected home PC gets connected to the corporate network, via a VPN or other means, all the work IT does internally to keep things safe could be wrecked.

Yet this is reality. Why? Because Microsoft doesn't require computer makers and retailers to sell their PCs with totally updated operating systems. The computers likely will have XP with the most recent service pack, but no subsequent updates.

Dan compares manufacturing, where vendors are held (legally) responsible for known flaws in their products to software, where we throw up our hands and sigh. That's not going to last forever - the trial lawyers have feasted on tobacco companies, and are now looking at fast food. Regardless of what you think of those sorts of tactics, one thing is clear - part of the motivation is the pile of money that the big companies behind tobacco and fast food have access to. How long is it going to be before the trial lawyers catch the whiff of MS' $50 billion pile and combine that with the actively negligent security from MS? It won't take a great lawyer to point out just how half baked the XP SP2 firewall is, or that every OS prior to SP2 shipped with no active firewall and lots of ports open that have no business being open.

When it comes to legal action, I think MS is going to regret posts like this one. It's a good, informative post - but look at it from the standpoint of liability - here's an MS employee admitting that the latest rev of the OS doesn't ship in a safe enough state. This after many, many nasty attacks over the last few years. I suspect that MS is going to have a lot of trouble with this, and I think it'll be sooner rather than later.

Update: TechRepublic is also unimpressed.

I agree with Roy - who points at this essay - you need good management and good developers in order to achieve something. However, it's often the case that direct engineering management isn't the problem source. Take the need for good equipment and access to training/books (etc). In many outfits, the decisions on equipment have to be vetted by IT, not by engineering. This leads to unproductive fights over the needs of engineering vs. the more pedestrian needs of typical office staff. It takes more than just good local management - it takes buy-in all the way up the line on the notion that developers will have different needs than other staff.