Smalltalk Tidbits, Industry Rants

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.

Chris Petrilli explains what things to load (and where to find them) in order to build a basic development image. The only thing I'd add is the NetClients parcel, but that may be because I'm working in that area all the time...

If you're a Smalltalker in Uruguay, check out the SUGUY page.

A Lisp guy (Ng Pheng Siong) explores Smalltalk/X and finds that he likes it - and scripts up an example of downloading the PDF of this book (link courtesy of Chris Petrilli). It's an example of how easy it is to get started in Smalltalk - grab an implementation, open a workspace, and start trying things out. No obscure compiler options to figure out, the debugger pops up if and when you need it, and the browsers work with you to find code. Go ahead - take the plunge and see for yourself!

Look no further than Chad Dickerson's article on IDE's for an explanation as to why there hasn't been anything better than Smalltalk or Lisp introduced since the dawn of the software age:

As a Java shop, we have our choice of dozens of tools to produce our code, but our developers have opted for the humble text editor. Our developers use a wide variety of text editors within the team (UltraEdit-32, vi, and Emacs), but each developer basically sticks to the simple text file environment. Our team is highly productive and probably the best at hitting deadlines that I have ever managed, but when it comes to writing code, IDEs (integrated development environments) just leave them cold.

It starts with the notion that sharp sticks and pointy rocks are somehow more productive than tools optimized for your job. Part of the problem is that the relevant tools in the Java space are pale imitations of a Smalltalk environment. Another part of the problem is the whole dead object mode of development - a Java object resembles an object in much the same way that a corpse resembles a person. Why do so many Java developers opt for a text editor instead of a tool? Because the tool doesn't really do a lot for them, and the tool cannot be (easily) extended. Sure, Eclipse offers plugins. It's not the same as doing a quick modification to a Smalltalk environment and getting the benefit right now. Take a look at this post from Eric Winger for an example of what a developer can do to optimize their personal development environment. Now imagine an Eclipse developer doing the same thing... When you stop giggling, you'll understand why so many of them opt for the sharp sticks and pointy rocks approach.

Here's Chad's summary - I'll have a comment on it below:

The IDE debate will probably continue until the end of time. A surprising degree of passion flares if you bring up this issue with developers. But does it actually matter? The answer, like any dealing with the ambiguities of IT philosophy, is yes and no. As long as your developers produce quality code that they can debug at the lowest level when necessary, the IDE debate is probably more of a cultural issue than a technical one. Consistent, quality code delivered on time trumps the means of getting there; however, culture matters within a development team. If your development team spends a lot of time debating the merits of writing code in an IDE or a simple text editor, they probably won 19t be incredibly productive. The important thing is to choose the route that makes your team most productive - and execute.

The problem appeared early in his article - at the point where he said "we are a Java shop". he didn't say "We look around for the best tools for a job" - he said "we are a Java shop". Right there, he ensured that there was a fairly low top point to his team's productivity. Python? Ruby? Smalltalk? Nah, text editors and Java are the way to go. This is nicely in line with the 4 zone charts that these bozos like to draw, but it's not a way to rise above the competition. If you make sure that you do exactly what the other guys do, you have made a risk averse decision - you won't fail any worse than they do, but you also won't succeed any better. You'll tread water.

Chad should take a look at a Smalltalk environment - there are plenty to choose from - and see how productivity can rise when the team has an environment that lets them move the bar up.

It may be time to throw in the towel on Atom. Why do I say that? Well, Google (by way of Blogger) has rolled out Atom 0.3 - as have a number of other people. 0.3 is permanent now, no matter what the IETF does with Atom. It's more than that though - if you subscribe to the Atom mailing list, you'll get to see just how little it takes to generate a useless discussion. Take the argument over dates (please!). It looks to me like it will take years for a putative 1.0 spec to come out - and at that point, no one will care. Atom 0.3 or RSS (either 1.0 or 2.0) will have been chosen as the default syndication format by every organization that cares. What value will they see in pushing out a new format? Initially, no aggregators will support it, and some never will (most of the authors will do what I plan to do - take a "wait and see" attitude). The syndication problem will already be solved for places that use it - spending time and resources on making no value changes just won't look that attractive. My advice - admit defeat and move on to something worthwhile.

The Register is not impressed by SP2 security - check out the services that are still listening after you install it...

Reflective Surface explains why he likes Smalltalk:

I fell in love with Smalltalk the first I time I saw code written in that language. A language with only five keywords and where all things are objects could only have that effect of me. Those two facts create a language that is extremely powerful, whose syntax is also extremely pleasant. Interestingly enough, Smalltalk's syntax has remained essentially unchanged for more than 20 years now. That's a tribute to its power.

I believe that two factors are crucial to the success of a programming -- success here meaning the language achieves its intended semantic purpose, not that it achieves any significant market share. Those two factors, simplicity and reflexivity, also tend to create languages that are aesthetically interesting. Aesthetics, then, it's not a visual function when programming languages are concerned. Rather, it has more to do with the way the language allows for the clear, simple, efficient and readable representation of algorithms.

Note the bit about the mostly unchanged syntax - the only real change in VisualWorks is the addition of Namespaces a few years ago. The fact that Smalltalk doesn't need new features in order to embrace new ideas is very powerful - while the curly brace guys bolt on new keywords and add syntactical sugar, they haven't figured out that less is more

I think Scoble usually does a good job of being forthright with MS related news, but this:

Dave (Winer) also said that the news was broken on Friday evening in an attempt to "take out the garbage." That's not true. Mary Jo Foley broke it at 9 a.m. on Friday morning. The official press release was posted before noon on Friday.

C'mon. Releasing bad news on a Friday as a way to bury it is something that all marketeers do - both the corporate and the political kinds. Just accept that MS was following the pattern and move on :)

Patrick points to Miguel de Icaza on Avalon:

Complexity: The Avalon API has a very large surface area. To get an idea, the Button class is number 11 on the inheritance chain with ButtonBase, ContentControl, Control, FrameworkElement, UIElement, RetainedVisual, Visual, DependencyObject, UIContextObject and Object as its base class.

My prediction is that Avalon v1 will be a throw-away: it is not really the foundation on which you will build applications: V2 will likely not be backwards compatible, they will have to re-architect bits of it: which means that people will end up with two frameworks running side-by-side: Avalon V1 and Avalon V2.

I do not think I could have solved a problem of this magnitude, am sure the complexity is huge and the Microsoft folks are doing their best, but maybe a change in the way that features are interlocked and how those are delivered to users must be rethought.

Looks like the standard pattern of ignoring MS software until version 2 or 3 will apply here. Interestingly enough, we are also in the midst of creating a brand new UI framework for VisualWorks - Pollock. A quick perusal of Sam's blog and the code will show you that we are trying to get this mostly right the first time - and the best way to do that is to solicit feedback early and often.

I had a bizarre set of interactions between my mail client - Eudora, and my anti-virus application (Norton) this afternoon. It all started when I had Eudora trim the junk folder. This involves Eudora taking older junk and moving it to the trash folder. The trouble started when Norton noticed a virus (in an attachment) - I guess it noticed on the file copy operation. Norton wanted to delete the virus file, but Eudora had locked the trash file as it executed the copy. The upshot - neither operation could progress as they bickered. I had to turn off Norton's checks, let Eudora finish the operation, and then re-enable Norton. Goodie - I love it when applications fight, especially when they each deploy modal dialogs. Grrr...

Frances looks absolutely terrifying. Keep in mind, Florida (western and central) just got slammed by Charley 3 weeks ago - when I went to Disney on vacation on the 18th of August, large parts of the Orlando area were still without power - and the cleanup from Charley is still going on. So now Frances is coming in - and as of now, the predicted path takes it straight into Melbourne Florida. That's scary for me, since my parents live there. They say that they will be bugging out early Friday if it's still aiming their way; I guess we'll have to see how it goes...

Update: Well, this is selfish of me, but Frances is denying me one of my favorite comic strips - Day by Day. Seems that the author lives right in the (currently predicted) path, and is bugging out. Stay safe Chris, and come back and make us laugh

Via Mark Baker we see that the RIAA stands athwart progress shouting 'Stop!'. Morons

Travis made an interesting post on #perform. It's an interesting method, and easy to use - like Travis, I'd like to see some stats on comparable uses of reflection in Java or C# applications. Anyhow, Travis' script turned up 471 uses in a fairly basic image (Store and a few tools loaded). I just tried it on on my BottomFeeder development image, and found 694. Zoinks! I don't think I use it that heavily (there's some usage in Bf and the Blog poster, but I don't think I have 200+ more. Then again, I have a lot of things loaded - Wave server, Web Services and Opentalk, Net Clients, XML-RPC - I guess it adds up :)

Here's an interesting explanation of how the increment/decrement operators work in C#. It takes a bit to explain what actually happens when you enter: x += x++;

If you use ObjectStudio, you'll want to bookmark this page - we have information on ObjectStudio builds and patches there.

Darren Oakey complains that Smalltalk "won't make it into the 90's" until it ships with Intellisense support. Sorry to burst your bubble Darren, but VisualWorks already ships with 2 components - both community provided - that offer that support. The latest one is the Code Completion package in the public Store from Anthony Lander. Here's a question tossed back - can Visual Studio developers make comparable additions to the environment on their own? Eclipse offers plugin support, but it's far, far more limited than what a Smalltalk developer can do...

One of the commenters in this thread said the following (as to why Java developers dislike Smalltalk):

The main reason most programmers dislike Smalltalk is *because of* the dynamic nature of the environment. If you hack away at your environment all the time, not only do you not get any work done (see "Macdinking" in the Jargon File), you end up shipping the workbench to the customer because your app won't run otherwise. Java IDEs produce code that can be run with a standard JVM.

Hmm. I guess BottomFeeder doesn't exist then. Separating tools from application is not as hard as the commentator makes it out to be. What his argument boils down to is this: "Protect me from myself, because I am not responsible enough to deal with power tools".

As to this:

It's not a matter of ignorance. Basically every professional programmer knows Smalltalk, from reading Design Patterns if nothing else, and quite rationally chooses not to use it. Making a prettier GUI isn't going to change that. We're not idiots, and we're not shallow, and the pompous attitude that we are makes us treat you with contempt. We chose the best tool for the job, and it wasn't Smalltalk.

Seriously, you're going to have to wait for me to get off the floor, where I'm suffering from a serious laughing fit.... Ok. I've traveled extensively, and attended a number of trade conferences over the years. The best you could say is that most programmers have heard of Smalltalk. Most of them couldn't identify code as Smalltalk code if their lives depended on it - not because they are stupid, or uninterested - simply because they haven't encountered it. It's possible that Lisp is less well known, but not by a lot.

Well, here's a gift idea for the geek who has everything - a Swiss Army Knife that comes with a USB drive. The drive itself detaches so that you can board a plane without hassles. Looks pretty cool.

If you are on the dev update stream for BottomFeeder, then you'll see a new update available this afternoon. There's an option on the item menu to spin an item out into its own window. I am still thinking of making a tabbed browsing kind of thing for the main Bf window, but doing it this way was far, far simpler given some of the existing code. See what you think.

The next release of BottomFeeder should see a raft of improvements. I'm in the process of moving the Http code over to use NetResources - a package written by Michael Lucas-Smith. It's basically a cleaned up, better version of the Http-Access package that I've been using. This should result in some cleaner code, and better performance when fetching cached items (and a smaller footprint - this package does disk caching instead of the all in memory job that my package does). After that, the big job comes up - WithStyle. I intend to replace the Twoflower browser component with WS - and that should give a major usability boost. WithStyle handles CSS, and does a generally better display job. A fairly large amount of massage code that I've done to work around Tf limitations will come out as well.

These are fairly major revisions, and will require a fair bit of work on my part. I'm just starting on it now, and the whole thing will require testing before I let it out - even in dev. The end result should be a much better tool though - so we have something cool to look forward to.

Blaine explains why many Java developers think Smalltalk is old and out of date:

So, why do the java developers think their tools are ahead of ours? Eclipse looks mighty pretty and it has a lot of great features. But, pound for pound, we have the same features and more. We have a live world to play in. Eclipse is nothing more than a painting of the world. We are the real thing! I can change the object inspector in the IDE and no shut down! Any change to Eclipse and I have to shutdown and restart. So, why are java tools considered better? The only thing I can think of is the looks. At work, we use VisualAge and well, VisualAge looks old. I'm trying my best to tell them not to judge a book by its cover and there's a reason a lot of people think it's cool. But, they have this notion that us Smalltalkers are just old technology guys hanging onto our past for dear life. It saddens me that they see me this way. I love new technology and I'm constantly studying new languages. But, so far, the one I am most productive is Smalltalk. Period. End Of Story. Ruby and Lisp are great too, but I can still code faster in ST. I would still pick any dynamic language over java/C# any day of the week.

So, here's the rallying call. How do we make Smalltalk not seem old. I think despite it's age, it's still far ahead of the game in a lot of areas and where we lack, we can quickly close the gap. Let's get rid of this stigma that Smalltalk is old technology. We are the future NOW!

Well, might I suggest that you show them a Smalltalk environment that is still under development - Cincom Smalltalk, or Dolphin. I can't speak to Dolphin's recent improvements, but For CST have a look over here. There's been a lot of work done, and there's a lot of work being done now. We have a development roadmap that covers the next few years - so you'll continue to see a lot of cool new things. If you want to impress the developers, show them what's being done, and what will be done - not what was done quite some time ago.

I think Marc Hedlund hates Word more than I do, and he's figured out the general issue that I've only mentioned examples of:

Microsoft hires very smart engineers -- I would say the smartest in the business. When they see that some number of their users have some writing problem they believe a computer could be trained to solve, they do a better job than anyone at writing the code to solve that problem. They talk all the time about "knowledge workers" and their needs. What the Word team lacks, in my view, is an awareness that, when a user is trying to get his or her own work done, the user is always smarter than the technology. Assuming that smart people aren't their market is the surest way to produce a bad word processor, which is exactly what I think they've done.

MS' Word team has decided that they know what I want, and they are really, really wrong If I could buy Word for Windows 2.0 today, I'd happily give up all the "progress" in the newer versions.

I just upgraded my mobile phone, and decided to make it a camera phone while I was at it. So I got a Samsung sch-a610. It's not a great camera, but I'm not all that concerned - it was inexpensive, and it will work for what I want (quick shots to send by email or post here on my blog). I noticed that Verizon now has cheaper calling plans as well, so I saved a few bucks while I was at it. We'll see how it goes.

Everyone else has commented on the Longhorn decisions - but here's something I'm wondering about. MS has announced that the file system (WinFS) will be missing from Longhorn, and will "ship later". Hmm. I don't think you ship a file system as a set of dynamic updates to the OS - I mean seriously - outside of a major upgrade, how many people are going to take the time to install it? I'd say that it's entirely possible that WinFS will never ship. Why? Look at the timelines:

XP SP 2 - shipping now
Longhorn - shipping 2006

Longhorn is still two years out (at least - I wouldn't discount the possibility of further delays). MS isn't going to want to ship a disruptive upgrade too soon after Longhorn either - which puts WinFS out until something like 2008-2009 (at the earliest). Now, what's the liklihood that it'll survive that long without some MS development group deciding that they have something better between now and then? I'd say pretty slim.

Phil Ringnalda says out loud what I've thought many times - and I'm sure many others have as well:

After just a few months, 3% of my unimaginably huge 1GB GMail storage has been used up by atom-syntax. If you are among the people whose name I can search on and be shown "1-20 of hundreds" of messages, if your typical quote:content ratio is huge, if every single thread of a hundred or more messages (there's at least one such burning all the time) prominently features you, you, you, you might want to consider whether this mess would clear up if someone took you out and shot you. Lord knows the rest of us are considering it.

No kidding. The thread on dates alone...

I guess I'm not the only cynic on the MS announcements about Shorthorn - Charles Miller is desperately looking forward to the new photo experience as well :)

Charles Miller makes some funny points about software development - Java and Ruby in particular.

David Moschella of ComputerWorld has some timely points to make about IT and their interactions with the rest of the company - and it's going to require a lot of adaptation on the part of IT:

Do the employees in your organization ever complain that they have better technology at home than in the office? Do you require them to access corporate systems via a dedicated PC as opposed to any Internet-connected browser? Do they ever use their personal Internet e-mail accounts for business and laugh at the limitations of Microsoft Exchange or Lotus Notes? Do they sometimes shake their heads wondering why, if they can set up a wireless LAN at home in a few hours, corporate IT says wireless systems in the office are too complex and risky?

That's one issue for IT shops - the glass walls are gone, and the end users are getting to be experienced enough to know when they hear BS back from IT. Just about everyone I know has a story that fits into that paragraph. The problem is that the end user community is setting up their own (wired and wireless lans), dealing with things like GMail, and working with video and audio applications. Formerly patient users are now able to ask "why not?" far more convincingly than before:

The ramifications of this are now becoming clear. IT departments have become accustomed to treating employees like children who must be told what they can and cannot do. But many employees want to be treated like consumers, given choice and flexibility in their use of IT. If they are going to work at home and lug around dual-use work/personal devices, these devices will have to meet their personal standards, not just for functionality but increasingly for style and fashion as well. Requiring every employee to accept the same generic IT capabilities will become almost as absurd as requiring that every employee drive the same car.

That's what IT departments are facing - and the ones that want to succeed are going to become more flexible towards the user community. The ones that don't are going to cost their companies money.

There's another thread in comp.lang.smalltalk on debugging and testing. There's a level of misunderstanding between Smalltalk developers and people who've never used a language like Smalltalk - you'll see that in comments like this:

Debuggers are great tools, the but the thing to ask whenever you want to use one is why it isn't easier to just write a test case. In some projects it is. In others, well, we all know when we are working in a project like that, but there are things that we can do to make it easier.

It's not that debuggers are bad, its just that they can desensitize us. It's like downing a beer and sleeping on the beach; we shouldn't be surprised if we wake up with a sunburn. We can start to think that our code is pretty good when in fact its really pretty lousy because we've ignored concrete evidence that it could be easier to understand and test.

Now, I know why people who mostly work in languages like C# and Java say this - their debuggers are forensic tools - the patient has died, and the best that you can do is figure out what killed him. Smalltalk developers have a different tool at their disposal - the Smalltalk debugger

The Smalltalk debugger is both a debugger and and code browser. With Smalltalk, the developer becomes a surgeon - the patient isn't dead, he's been sedated. We can look at what's wrong with him, and fix him up while we look at him - in the debugger. That's why most of these conversations end up with people talking past each other. In Smalltalk, we can write the test - and when it fails, we end up in the debugger - from where we can patch the code (or the test, depending on circumstances) up and move along.