Smalltalk Tidbits, Industry Rants

Ted Neward points to an article he mostly disagrees with - but stumbles into yet another re-invention of something Smalltalk got to a long time ago:

Why do we distribute applications across multiple systems today? Is it because we like managing multiple systems? No! It's for scalability. We exploit the fact that tiers of a multi-tier app have different processing loads and scalability methods. Typically, we scale the web/app tier by throwing more servers at the farm while we scale the data tier with bigger servers. However, as Moore's law increases the performance of these machines, the need to scale becomes reduced, From my experience, many smaller apps could easily run a single machine today (esp. when you consider the increased efficiency of eliminating the network and process hops). Moore's law will continue increase the headroom these machines provide and expand the definition of "smaller apps". If you can run the app on a single hardware node, there'd be little reason not to run as much of it as you can inside the database, other than "we might want to scale this out someday".

I wonder if these guys have ever heard of Gemstone/S?

There's some good media news about Smalltalk in Germany:

Smalltalk and VisualWorks covered in a German computing magazine

"c't magazin fuer computer technik" is one of the best-known and most-read magazines for computer and software freaks in Germany. The current issue #8 of April 5, 2004 shows a double coverage for Smalltalk respectively Cincom Smalltalk:

The article "Einfach abheben" ("Take off simply") written by Hajo Schulz and Joachim Tuchel (p. 234 - 239) is the first part of an introduction into object-oriented programming with Smalltalk. As an overview the authors present a comprehensible comparison between Smalltalk and other programming languages. Based on Cincom Smalltalk's VisualWorks the authors explain 'step by step" how to use VisualWorks and create small examples ('hallo World" and "turtle new") for a first start.

"Programmiererfutter" ("Fodder for programmers") by Hajo Schulz (p. 126 - 128) recommends Cincom Smalltalk's VisualWorks as one of three tools for a professional software development. VisualWorks 7.2. non-commercial is part of the CD delivered with the magazine. The article helps for the first usage of VisualWorks - how to start with the CD, where to save the software on the desktop etc. It is a very good "how to use" instruction for VisualWorks beginners - excellent to start with given you understand German.

The magazine's web site: www.ctmagazin.de - Soft-Link 0408126 and Soft-Link 0408234

Report on Cincom Smalltalk Evening at OOP 2004
OBJEKTspektrum, the most important OO magazine in Germanic Europe, published in his latest issue, # 2 March/April 2004 p. 19, a report on the Cincom Smalltalk evening which was organized by Cincom and Georg Heeg eK during OOP 2004 in January in Munich and which was a great success.

I've posted a new BottomFeeder update to the dev stream - along with a new TwoFlower. You need both; you'll have some issues if you only grab one. What's new? Well, Holger has done some nice work with Twoflower, and I've been working to turn all the strings into UserMessages (so that the app can be localized). Bugs? I'm sure there are plenty (this is a dev update!) Please let me know

Chris Double points to the announcement of a new version of Seaside for Squeak. There's also a new VW version in the public Store, but I believe that one is a trifle older...

This is why Sun settled - they are losing money hand over fist, with few prospects of improvement....

Sean Malloy notices that the software world takes 1 step forward and 2 steps back on a continuous basis. He's not wrong :)

Ted Neward takes a look at Smalltalk, and likes what he sees - with a few questions:

And suddenly I wonder, Is this the source of all that XP goodness that the Smalltalk community gushes on about? If we had the ability to "load" a JVM or CLI instance into a frozen image, and ship that, say as a 24-48 MB "image" file, think about the possibilities--less startup time (I would think, since this could be a more or less memory-mapped image), plus I could conceivably give my customer an ability to "freeze" an image if a bug hits, and email or FTP the image with the bug in it to me for diagnostics. No more having to recreate the problem! It's all right there, for me to load, inspect variables, and so on.

The worry comes here:

Then again, there's security questions--what stops an attacker from mangling an image and injecting some rotten stuff? Is the image format well-known and easily subversible? If I started using Smalltalk as a back-end HTTP-processing agent, is there weird buffer-overruns or command-injections that could corrupt the image somehow?

There's no way to do a buffer overrun - in .NET speak, Smalltalk is a managed environment - immune to that kind of thing. As to command insertion - you can't load code from a remote location unless the server is set up to do that sort of thing. I have this server set up to load code from a known (server side) directory for patching, but I have to have permissions to place code there in the first place - and the directory is not in the web directory side of things, so it's inaccessible from there.

More generally, and image is just byte code - it's somewhat like a big JAR file, but with the ability to extend and override any code you want/need to. I do live updates whenever I have new code - without taking down the server. The nifty thing is this: If I load in a new version of a class, all the existing instances get updated - i.e., if I added/removed an attribute (instance variable), then all the instances added/removed it as well. That's what makes live updates feasible. The site that hosts this server is running VisualWorks (part of Cincom Smalltalk), and the only attacks I've suffered have been the kinds that all bloggers suffer - comment and referer spam :)

Now one more thing - as to bugs? There have been a few times I've had to debug the server - in which case I've started it up with a GUI, using X over ssh. And then I've debugged the actual problem in the live server as it was handling load. If I wanted to do that with less fuss, I could set up the remote debugging tools that use Opentalk - which I intend to do, when I get a few spare minutes :).

Apparently, DotNet actively rots your brain - just look at this post:

I'm sitting here at work building an application using TDD (which by itself is another post, and may be coming later), and every time I start a new class for another piece of the puzzle, I'm hating on how I have put the keyword "sealed" class in my declaration. Now, this isn't a major issue, but it can be if you plan on releasing an API for customers to build against. What's my issue? Well, I'm wondering if the "sealed" and "notinheritable" keywords should be applied by default in Whidbey.

He calls this "good design". Uh huh. Assuming that you know everything and that the end users of your code know nothing, I suppose it is. If you assume some level of intelligence in the end users of your code, it's just bad. I'm starting to think that "sealed" and "final" do more harm than static typing - they encourage closed end systems that cannot be extended without heroic efforts on the part of end developers. Run, don't walk, from any code developed by people who think this way...

Patrick Logan considers how things could have gone

If Sun had gone with Smalltalk rather than Java, where would they be now?

If Microsoft had gone with Smalltalk instead of C#, or way back in the 1990's when they could have forged something with Digitalk instead of their long and winding DCOM fiasco

To sleep, perchance to dream.... :)

Register today so you can hear all about drawing editors in Squeak. Ned Konz has been doing research and implementation; check it out:

Building structured drawing editors using Connectors and Squeak
presentation
Ned Konz: Viewpoints Research
Wednesday 4:00:00 pm to 4:45:00 pm

Abstract: Connectors is an open-source framework for building structured drawing editors using Squeak Smalltalk. The rich component library provided with Connectors makes it easy to customize shapes and connectors, in many cases without writing any code.

This presentation will introduce Connectors and describe how Connectors can be used to quickly construct a Squeak application for editing and visualizing structured data. It will demonstrate the entire process of developing a simple Connectors application, including customizing connectors, connection policy, shapes, toolbars, flaps, and worlds.

Integration with the Genie gesture recognition system and the eToy tile scripting system will also be described.

Bio: Ned Konz has been a Squeaker since 1997, and has contributed a number of enhancements and fixes to the Squeak effort. He is also one of the six "Squeak Guides" who lead the open-source Squeak development effort. He has been working as an independent consultant since late 1999, at the end of a 7000km bicycle trip around the US west. His consulting work includes embedded system development as well as Squeak development.

About six months ago, Alan Kay invited him to join his team at Viewpoints Research, and Ned is now working with a number of projects including end-user computing, eToys, simulation, and other user interfaces.

See you in Seattle!

I've finished the job of replacing strings with UserMessages in BottomFeeder - now I need help. I've uploaded the message catalog (English) here. I've got a volunteer working on a German translation; anyone else have the time and/or inclination to help?

We had the snipers, and now this. I guess this is better than that nutter who was shooting at cars in Ohio, but not by a lot. I drive that stretch of highway quite frequently, as it turns out...

Ted Neward points to the UML Fever article - making a fine point:

Oh, how I remember former bosses and employers demanding UML models of code that was already written, "for documentation purposes", even though every developer on the project knew that the models would be (a) incorrect, (b) too high-level or too low-level to be useful, and (c) would almost immediately fall out of line with the code itself with the next feature request. (This was in the era of the very first two-way round-tripping tools, and they all--without exception--sucked.)

That pretty much sums up any technology fad - Java in the 90's being a particularly good example. For some reason, people in this industry continue to believe in silver bullets, regardless of how many werewolves pop up that are immune to them....

Ted disagrees with my take on final classes:

It was in my days as a C programmer that I came to realize that the fundamental difference between Smalltalk and C was that in Smalltalk, all reusability derives from inheritance. You want to reuse some code, you inherit from it, plain and simple. Even working through the Cincom Smalltalk manuals, I see that message over and over again. This is not true outside of Smalltalk.Inheritance creates a dependency on the base class type within all derived types, and if for some reason something in the base class type needs to change, every class below it feels the change, potentially breaking what happens.

First off, I'd say that most Smalltakers are somewhat leery of deep inheritance hierarchies now. With dynamic typing, polymorphism makes it easy to create ad-hoc interface matching without having to share a base class. In fact, that makes it easy to avoid the whole "fragile base class" problem entirely (even though it's less of a problem for Smalltalk than it is for static languages). I meet plenty of people who disagree with me on this point - the guy who gave the API talk at ot2004, for instance - I spoke to him briefly on the subject. I'm just not convinced. I know too many Smalltalkers who also know .NET and Java - all of them dislike "final", and all of whom talk about the nasty work-arounds they have to create to deal with the problem (typically, lots of helper classes). I tend to think that anything requiring that level of work-around is probably a bad idea.

Sure, this is a culture clash - but I still think it's a bad idea as well :) I think we'll have to agree to disagree for now

After writing this last week, I stumbled on misbehaving.net talking about a programmer gathering - and explaining pretty clearly why so many women stay away from the field...

Ted Neward argues in favor of sealed classes:

Look at it this way: take a simple example, that of overriding a method. What can you do in the base class to ensure that a future derivative doesn't somehow break your class' contract? Should derivatives call the base class method? And *when* should they make that call? At the start of their override? The end? Somewhere in the middle? What about synchronization concerns? Type compatibility? Are you really fully prepared to ensure that the Liskov Substitution Principle is honored in all its forms? From my experience, not many developers even know what Liskov is, much less what it's supposed to be doing for you.

Here's the simple answer: Why do I care? If another developer picks up my code, and wants to extend it by subclassing, it's not my problem - it's his. I'm going to make the assumption that said developer either

• Knows what he is doing
• Doesn't know, and will learn from his mistake

To my mind, stating that classes should be sealed is like saying that you should protect your kids from each and every mistake they might make someday. It might make you feel better, but it does positive harm to the people involved. Let other developers make their own decisions - making them for them is no favor.

I guess I've posted on this subject a bunch the last few days - maybe having a ten year old daughter is inspiring me :) Anyhow, Julia Lerman points to a Girl Scouts affiliated site that is trying to encourage girls interested in the field to stick with it. I have less than no idea whether this sort of thing helps or not, but I'll point my daughter to it and see what happens....

MaryFran Johnson believes the press releases from the Sun/MS deal. I would have thought a ComputerWorld editor would be more perceptive, but I guess not:

No question about it, this one belongs to you. IT customers were the driving force, the ultimate bottom line, the wake-up-to-reality call behind the historic Sun-Microsoft accord announced the morning of April 2

Uh, no MaryFran - customers had less than nothing to do with this deal. It hinged on a number of things, one of which she touches on later in the editorial:

• Sun's increasingly weak and desperate position in the marketplace
• MS' desire to get rid of a distracting lawsuit
• Both companies desire to hurt the IBM/Linux push

That last one is something both companies agree on - and from the look of it, they agree on this more than they dislike each other. This is touched on later in the editorial:

Both companies are worried about the rise of Linux and the ever-present threat of IBM's enterprise dominance. Sun has suffered through years of financial setbacks and faces yet another quarterly loss and an upcoming layoff of 3,300 employees. Microsoft has spent tens of millions of dollars in courtroom battles over antitrust issues, and its stinging defeat last month by the European Commission moved its legal troubles as a monopolist onto the world stage

Funny that she puts that in the penultimate paragraph of the editorial - it's the key point of the deal - and the only reason it's happening. MS wanted to get rid of the suit, and Sun is weak - but neither was enough to drive this deal. What drove it was those two things combined with their joint belief that IBM and Linux are the bigger threat. The key thing to watch over the next few months is just how much Sun starts downplaying/cutting all the desktop initiatives they have been pushing - and how far they start distancing themselves from open source. This post from James Gosling could be considered an "opening salvo" in that positioning:

GPL software is not "free": it comes with a license that has a strong political agenda. Like GPL software, the Java platform is "free" in many senses: you don't have to pay anything for the runtime or developers kit and you can get the sources for everything. Unlike GPLd software, the Java sources don't come with a viral infection clause that requires you to apply the GPL to your own code. But the sources for the JDK do come with a license that has a different catch: redistribution requires compatibility testing.

Don't get too caught up in the "it's all because of what customers have been telling us hype - this is all about the three points I mentioned earlier. Sure, there's potential customer benefit here, but that's a secondary concern at best

VAST developers should run to Eric Clayberg's talk on advanced VAST programming at StS 2004 - Register today!

Advanced VisualAge Programming
presentation
Eric Clayberg: Instantiations
Wednesday 4:00:00 pm to 5:30:00 pm

Abstract: Eric Clayberg, Sr. Vice President of Product Development for Instantiations, Inc., was Executive Vice President of Objectshare Systems, Inc. and Vice President of Development for ParcPlace-Digitalk, Inc. He is the primary author and architect of over a dozen commercial Smalltalk add-on products including the popular VA Assist Enterprise and WindowBuilder Pro product lines. He has a BS from MIT and an MBA from Harvard.

Bio: This presentation will cover several advanced VisualAge Smalltalk topics including advanced GUI techniques, complex configuration management and development tool (browser) enhancements. Some of the specific topics to be covered include: callbacks & event handlers, attachments, hiding source, complex subapp configurations, version renaming, etc.

Topics will include:

• Advanced GUI Techniques
• Widget Callbacks & Event Handlers
• Using Pointer Motion
• Using Timers & Delays
• Determining Key State
• Attachments
• Morphing
• Complex Configuration Management
• Hiding Source
• SubApp Configurations
• Version Renaming
• Locating Dependent Configs
• Development Tool (Browser) Enhancements
• Extension API
• Subclassing TextSelectionManager
• Hooking KeyPress in Text Widgets
• Enhanced Text Menu

See you in Seattle!

Check this out:

Join Vladimir Horowitz's mailing list to stay up-to-date on all the latest news, tour info, contest announcements, and more!

Tour info... Horowitz died in 1989, so if he goes back on tour, it'll certainly be news...

I've just added (but not yet deployed) a new feature in Bottomfeeder - a "related links" view. Once you subscribe to a number of feeds, you'll find that many items refer to other items you've already got. Sometimes, it would be nice to view those items as a chain of related postings - which is what this view does. After evert update cycle, the link cache is updated so that you'll have accurate results. After a little more testing, I'll push it out to the development stream.

Or at least, why sealed is a bad idea:

Another example, I like the way Common Lisp enables you to access variables not exported by a package. It requires you to access them in a different way to normal but you can still do it. There are simply times when you need to dive into the implementation of things that the originally designer thought you should be prevented from seeing. Having a way of doing this is invaluable when trying to do things 'outside of the box'.

IMHO, developers who seal classes to "protect" other developers are merely putting irritating walls in their way - and worse, they think it's helpful! Don't assume that you know how others will use your code. You don't. Period.

PR News thinks that PR people should worry about outsourcing:

First of all, true PR and media work requires long-term relationships with media members. A level of trust, rapport and understanding needs to be established to receive proper recognition and media placements. True, but what rule states that you have to be in the same geographic arena as the media? Why wouldn't someone in India be able to form a relationship with media? If they don't have them now, they can partner with a US firm or an independent US consultant for help (and let me tell you, there are lots of very senior PR people floating around looking for work) and eventually transition it all over

Hmm. Let's take this question: "Why wouldn't someone in India be able to form a relationship with media?" - there's a simple answer: the 12 time zone difference. Think about it - we sleep while they're awake and vice-versa. Over the long haul (the time it takes to establish a relationship) - how many people are going to be willing to work that far off cut? Not many, I'd guess. This is a simple, but quite large obstacle...

Interested in what's going on in Squeak with respect to tools? Then register today and go to Colin Putney's tool talk:

Squeak Tools
presentation
Colin Putney: independent consultant
Wednesday 4:45:00 pm to 5:30:00 pm

Abstract: Squeak has come a long way in the last couple of years, and armed with improved tools and infrastructure, the community is progressing more rapidly than ever. This presentation will examine the new breed of Squeak development tools - PackageInfo, SqueakMap, Monticello, OmniBrowser and SqueakSource - and the technical and social issues that shape them. We'll also have a look under the hood with Monticello and OmniBrowser, a development environment well suited for the curious intersection of traditional Smalltalk philosophy and the new culture of OpenSource software.

Bio: Colin Putney is an independent consultant with a background in media, information systems and project management. He has worked in print media, television, the travel industry and international conservation. He was first introduced to Smalltalk several years ago and has never looked back.

See you in Seattle!

Found this in Planet Lisp - a fascinating look at a Java guy's first interaction with a dynamic language:

The interpreter immediately is waiting for you to tell it to do something, so I entered at the prompt:

>
>> (  10 2)
>
>and it gave me:
>12
>

Wow! I know this does not seem like much, but from the Java world where I come from, to get a Java program to add two numbers together would have taken a public static void main(String args) (etc) with the correct classpath settings, a class file, a compilation, and an execute.

Heh. I enjoy showing jsp developers "self halt." in an SSP page, myself :)

There are a few tweaks to the schedule for StS 2004:

Smalltalk Soutions is less then two weeks away! The show this year looks like it will be one of the best ever. Fantastic keynotes, outstanding presenters, and the best programming language there is. What more could you ask for?

For those of you local to the Seattle area or if you just happen to be in town for a day, we have added a one day pass for the conference. The one day conference pass is $200 USD and gives you full access to that days events except for tutorials. One day passes can only be purchased at the conference.

Two Additional Presentations Have Been Added to the Schedule

Squat: a minimal yet extensible Smalltalk system
Presentation
Craig Latta: The NetJam project
Wednesday 9:15 am to 10:00 am

Abstract: Squat (http://netjam.org/squat) is a portable Smalltalk system comprised only of that needed to start and extend itself. With its web-based installer, a visitor can transfer and run the system in a few seconds, by making a single webpage visit. This has the potential to make Smalltalk more accessible to newcomers. Squat's module system affords clean organization of the system, and accurate network distribution of behavior without using files or the compiler. This has the potential to increase the efficacy of Smalltalk software distribution and team development. This presentation is a look behind the scenes. We'll examine Squat's remote message-sending framework, how it enables both remote snapshot dissection and module distribution, and the virtual machine changes underlying it. We'll also look at the module system proper.

Bio: Craig Latta (http://netjam.org), a diligent minimalist, hesitates to say more about himself. However, he points out that he started Smalltalking in 1991 while in the music department at UC Berkeley, and has been an active contributor to Squeak since its first release in 1996, when he was at Interval Research. He currently works as a consultant on projects at Bedarra Research Labs and EZBoard, and records music in a Squeak-based digital studio.

Using SNMP for high-performance network monitoring
Presentation
Alex Pikovsky: Quallaby
Wednesday 2:00 pm to 2:45 pm

Abstract: The SNMP protocol is the principal tool for network discovery, data collection, monitoring and management. However, SNMP structure and design present a number of problems for high-volume/high-performance network monitoring.

In this presentation I start with a brief introduction of SNMP. I then discuss issues involved in SNMP-based data collection. Techniques for building a flexible, high-performance SNMP collection engine are introduced. The second part of the presentation discusses network discovery via SNMP. Alternative approaches are presented and case is made for using relational model for the discovery. It then discusses using a combination of ECMAScript and SQL for SNMP object discovery and data collection.

Bio: Alex Pikovsky became involved with Smalltalk in 1995 when he joined Cincom Systems. At Cincom, he combined consulting gigs with development work on ObjectStudio Smalltalk. Alex redesignedthe native thread engine and developed a new Class Browser for ObjectStudio. He was also interested in transactional computing and co-authored the object-transactional framework ObjectLinks with Stephen Pair. After Cincom's purchase of VisualWorks from ObjectShare, Alex led the Internet Connectivity project for VisualWorks. He designed e-mail and HTTP clients. He was also responsible for XML-to-Object engine and Web Services framework (SOAP and WSDL).

For the last three years Alex has been a principal engineer at Quallaby working on network performance monitoring software. He lives in Boston with his family.

Tutorial Added

Modular Smalltalk -- Refactoring Smalltalk to produce cross-language consumable components
Tutorial (extra cost applies)
David Simmons: Smallscript Corp
Monday 2:00 pm to 5:30:00 pm

Abstract: A large proportion of software is developed today using a variety of languages for extending or consuming pre-built components and shared class-libraries that are designed to function within one or more widely available cross-language server systems or frameworks. For commercial purposes, it is essential for today's programming languages to be capable of readily consuming building blocks and libraries from other languages. However, it has become equally critical for commercial viability that such languages also be capable of producing building blocks and libraries in cross-language standard formats for transparent consumption by other languages. This interactive presentation and discussion will both outline the objectives behind the modular architecture of the S# smalltalk dialect and it will explore the benefits of rethinking the single-image concept by modularizing Smalltalk frameworks and projects.

The presentation will discuss design challenges in modularizing Smalltalk and the related demands of cross-language integration, specific design solutions employed in the implementation of Smallscript Corp's S# smalltalk dialect and its underlying Agile Object System (AOS) Runtime and Framework, and demonstrations of components built in S#. The components presented in the final section will illustrate Smalltalk's ability to produce industry standard executables and shared-libraries (dll's) that exhibit both fast code execution and small deployment sizes.

Specific attention will be given to capabilities for automatically exposing libraries (written in Smalltalk) to other languages without sacrificing reflection or other dynamic language features when the same components are shared with other Smalltalk executables and dll's.

Depending on audience interest, the talk may also explore just-in-time integration which includes illustration of side-by-side sharing of different(dll) versions of the same class modules within a single application. Of note in such explorations are the capabilities that make it possible for a single application/executable to simultaneously host multiple Smalltalk dialect frameworks.

Bio: David Simmons has been designing and developing language systems and virtual machines since the early 1980's. He was the principal designer and architect for QKS Smalltalk-91, its commercial toolset, and its pre-emptively multi-threaded virtual machine. Since 1999, his ongoing work on the smalltalk language has focused on the design and development of the S# smalltalk dialect for both Microsoft's .NET Framework and Smallscript Corporation's Agile Object System (AOS) Framework, a modular multi-threaded platform for dynamic languages. This work has concentrated heavily on modularization, performance, object models, and meta-object protocol capabilities for supporting cross-language integration and runtime framework support of a superset of today's popular language features.

See you in Seattle!

InfoWorld reports that a new rev of Netscape is in the offing...

I ran across an interesting VisualWorks application this evening: the BESM Character Generator:

The future is now! How often have you said to your close friends, "Well, I would LIKE to make up a morphing mecha magical girl berserker, but it's just too much trouble. I guess I have no choice but to play the same old boring 11-levels-of-combat-mastery-kensin-ripoff character that I always do." Now with the power of wacky space age style programming technology, constructing even the most min-maxed 100-interlocking-attributes every-stupid-flaw-in-the-rulebook combat demon is as easy as taking out Tokyo in a 120-point battle mech!

Check out the site - they make the sources available as well - I'm going to download the application and take a look. Very cool looking!

Cringely doesn't think much of Sun's chances:

Look at the companies that can be thought of as true competitors of Microsoft -- companies that have caused Microsoft fits in the past. There aren't very many such companies, but ones that come to mind (in no particular order) are Netscape, Novell, Lotus, Adobe, Intuit, and IBM. This is not intended to be an exhaustive list, just some that came to mind; if your company also qualifies, well, I salute you. Some of these companies were in businesses where Microsoft had ambitions, like personal finance software and fonts. Some were at one time bigger than Microsoft, like Lotus and certainly IBM. Some created products that defined whole product classes like Netscape and Novell. And in every case, if we look to the time when that competitor was causing the greatest grief for Microsoft, it was when they were also paying no attention whatsoever to Microsoft.

His point - Sun is still too focused on MS - unlike the examples he gives. Read the whole thing.

There's been a lot of talk about sealed/final since I posted here. In various posts (like this one from Ted Neward, the assertion is made that languages like Java and C# (any CLR based language, actually) need this capability, while Smalltalk doesn't. That sounded wrong to me, but I'll get to it. The other argument came across in a brief conversation I had with Joshua Bloch after this talk at ot2004. The argument goes like this: There's a pyramid of developers, with elite developers at the top (in small numbers) - with most living at the bottom two rows of the pyramid. making classes "final" protects this class of developer from themselves. I've pondered these two arguments, and had a few conversations about them on the Smalltalk IRC channel, with people who have experience with Smalltalk, Java, and C#. Here's what we came up with:

In Java, interface inheritance is the way to do things. A change in the API or semantics of the interface will ripple through all users - even though they aren't inheriting from the base class. So exactly what have you saved people from? Nothing except the option to inherit from a class if they wanted to take on that responsibility. So posit a class SecurityChecker and a method checkPassword(). That method should only take an instance of String, not some subclass or compatible class. That kind of security is arguably ok - but making it impossible to subclass String for any reason, ever - is overkill. The controls belong at a finer grain. What "final" ends up doing is cutting off your nose to spite your face. Here's a question: who's in a better position to know whether subclassing is appropriate:

• The library developer who has never seen the end developer's code
• The end developer who has seen both the framework and the end developer code?

Ted and Joshua Bloch say the library designers are in the better position. I say that's just silly - it really is akin to deciding that you are going to protect your children from all possible harm that could come to them by standing next to them 24x7. Sure, they'll be better protected. They'll also grow up as less than adults. This kind of protection means that developers have lots of (potentially better) options closed off to them, and they'll create crufty code. Worse, they'll start thinking that it's a good idea. The protection extended to them has ended up crippling them.

So now we come to arguments that Whidbey (the next gen of VisualStudio) should declare classes final by default, forcing developers to open them if they so choose. For the reasons given above, I think this is an awful idea. It will end up creating inflexible code - and since api changes ripple through a declared interface anyway, it offers few of the supposed benefits. I really have no idea why anyone thinks this is a good idea...

So I'm trying to send mail to a BottomFeeder user - not using my corporate (Cincom) mail (why that doesn't work is another story for another day). So I send the mail off, using my Comcast account. Boom - notice from SpamCop that it's been blocked, due to spam from the server in question (i.e., the comcast mail server). So let me get this straight - because some people using Comcast as an ISP are sending spam (likely infected PC's), all of us using comcast as an ISP are being punished? That's bad enough - I figured ok, I'll try and contact SpamCop with a question. No dice on that:

• No email addresses for contact on their website
• I registered for their support frum, but since I'm not a customer, I can't post a question
• No phone number on their website

So who the $%^&*() are these evil people? They filter out major ISP mail servers and leave no opening for complaint? I guess I have to contact comcast and see what (if anything) they can do for me. SpamCop - evil morons from heck.

John Dvorak has had plenty of stupid things to say before, and he stays true to form here - he's off on a rant about how useless chat (AIM, IRC, etc) is. Oh? Sure, there's wasted time involved (just as there is in ad-hoc "water cooler" meetings in an office - but it's like any other conversation mechanism - it's as useful or as useless as the people involved care to make it.

Seth Finkelstein thinks that the "A-List" bloggers are the new gatekeepers in the blogosphere. Let me just relate my experience on this. I started blogging in the summer of 2002. I was getting something like 10 pageviews a day for the first few months. It accelerated some with the addition of an RSS feed, but not tons. Building up a readership (my pageview count averages around 2500 a day now) took a long time and took a lot of work. What's it take? Well, regular postings, on topics that people find interesting enough to read and/or discuss. It's helped that I've blogged a few conferences - some of the readers who followed conference writeups have stuck around to read whatever else I blather on about. It's not magic, and it doesn't require affirmation from A-Listers (gosh knows I haven't gotten it or tried to get it :) ). What it takes is consistently putting out content that other people are interested in. Nothing more, nothing less.

AT&T Wireless gives us an excellent example of de-motivation in action:

However a new CIO appointed in April 2003 from Indian offshoring firm Wipro had his own techniques for motivating the IT staff, which borrowed heavily from Dilbert's Pointy Haired Boss. At Merrill Lynch, Christopher Corrado had been responsible for sending tech jobs offshore.

"Former employees say morale wasn't helped by Corrado's first presentation to the IT group, in which they say he proclaimed, 'Come in every day and expect to be fired'. Intended to inspire the troops to greater effort, the talk backfired," reports CIO magazine.

That's a sure-fire way to motivate the troops - letting them know just how much in danger their jobs are. Maybe if this bozo had gotten the same speech from his management...

Charles Miller has some really insightful thoughts on releasing software. Read the whole thing; this summary really does sum it up:

Anyway, as I was saying in the first paragraph, I used to think that the hardest thing a software project had to do was make the painful cut of features and bugs for 1.0. It turns out I was wrong. The hardest thing to do is, in fact, to make the cut for 1.1. The moment you release 1.0, you start getting these incredible things called users, who find all those bugs you never turned up during development, and who make really cool suggestions for things you could add.

Everyone who has ever released software that gets used learns this one the hard way...

Alan Kay - The father of Smalltalk has won this year's Charles Stark Draper Award from the ACM. This award is often dubbed "The Nobel prize of computing". Alan Kay shares the prize with other Xerox PARC alumnis Robert W. Taylor and Butler W. Lampson, and Charles Thacker. The best quote came from Alan Kay:

Kay added: "I have said to powerful computer industrialists: By all means use the ideas, but please try to understand and use the entire idea, otherwise what happens are the gross caricatures so often found in commercial vendor software. The evidence indicates that they didn't understand or heed my request."

One of our (Cincom's) technical field staff attended the Seaside talk in bern, and I got this report from him in email:

I attended an SSUG presentation yesterday in Bern. This presentation was about Seaside, the revolutionary Smalltalk web application development framework.

The slides can be obtained from http://www.iamexwi.unibe.ch/studenten/renggli/choose/

There were about 25 attendees and I could talk with a few people. There is a unanimous agreement that using Seaside for a web application should outperform all other current technologies (ASP, J2EE, PHP, Zope, Struts, MVC, etc) in term of development speed. The speaker, Lukas Renggli, is a student at University of Bern but also work for a swiss company named netstyle that creates web application for their customers. For some of their customers they are using Seaside, together with Squeak. One of their complex apps was demoed during the talk, this was for an insurance company with 50000 customers (?). The app was completed in 3 months by two people. See http://www.netstyle.ch. They also demoed something smaller (Available at http://kilana.unibe.ch:8888/) that was done by 1 person in 4 days.

I also met Ian Prince from a swiss company named inextenso. They are currently building web application that they do using Zope (a Python based framework). They are now reconsidering they choice for Zope after they started looking at Seaside. See http://www.inextenso.com We promised to meet again in the near future. He wrote a report from that SSUG talk at http://blogs.inextenso.com/seaside/blog/learning

Stephane Ducasse wrote that Seaside has the potential to make Smalltalk a "killer app" for web applications, because other languages like Java and PHP do not allow the implementation of the Seaside concepts. Some other languages would be OK though.

Sounds like a great talk; I'd love to see a similar one done here in North America. Avi?

Gary Short provides a rebuttal to my post on the perils of sealing a class. Needless to say, I disagree with him, but he makes a good argument.

I've just added some new support in the development stream of BottomFeeder - three new features:

• The "View New in Folder" menu pick now obeys the tree view setting - if you have opted to stay in 3 pane mode for such views, this view now obeys that
• If multiple items you've downloaded share the same GUID, then marking any of them read or unread will affect all of them. of course, if you read during the update cycle and read one item before the next downloads, you won't see this happen
• If an item has any related items - i.e., other items you've downloaded that refer back to it - there's a menu option offering a view of the related items.

These options are still somewhat experimental, and have only been released to the dev stream - so if you see problems, please report them!

Bob Congdon imparts some words of wisdom on optimizing. Nothing new or earth shattering, but something that far too many people ignore - I've fallen victim to early optimization more than once myself:

Optimization matters only when it matters. When it matters, it matters a lot, but until you know that it matters, don't waste a lot of time doing it. Even if you know it matters, you need to know where it matters. Without performance data, you won't know what to optimize, and you'll probably optimize the wrong thing.
The result will be obscure, hard to write, hard to debug, and hard to maintain code that doesn't solve your problem. Thus it has the dual disadvantage of (a) increasing software development and software maintenance costs, and (b) having no performance effect at all.

Too many times I've been at a customer site and had an exchange like this:

Them: Your product is too slow
Me: Have you profiled? Do you know know what's slow?
Them: No, we haven't profiled. But we know the problem is in (insert some vendor library here)

Invariably, I've whipped out the profiler, and found that the problem wasn't where they thought it was. Sometimes it is Cincom code; we are hardly perfect. However, it's almost never been where the developers thought it was....

Bob Westergaard needs a PS2 on his desk at work. It's critical :)

There are many languages and tools that developers can choose for the development and deployment of mobile applications. Smalltalk likely isn't one of the ones they would immediately think of - after all, Smalltalk has been around for many years, and is not nearly as well known as Java, C, or C#. However, Smalltalk has many advantages - it's the original OO language, and is much simpler - and more powerful - than Java, C, or C#. Cincom Smalltalk is a direct descendent of the original Smalltalk developed at Xerox PARC in the late '70s. Recently the 2003 Turing Award, considered the "Nobel Prize of Computing" was been given to Dr. Alan Kay for leading the team at Xerox PARC that invented Smalltalk, as the first complete dynamic object-oriented programming language. Now Smalltalk supports a wide range of platforms - including mobile devices.

What do developers of mobile applications need? They need a development and deployment platform that allows them to develop on traditional client platforms as well as on mobile devices. They need a platform that has the same power available on a full scale platform, without all of the bloat that normally comes with that. They need a platform that is easy to work with, and easy to update in the field. Why should developers select Cincom Smalltalk for mobile devices instead of the alternatives? The answer is simple - Cincom Smalltalk offers a low cost, low risk, high value development and deployment platform:

• Low Cost
• Creating software for the mobile platforms is expensive. Using Cincom Smalltalk, development can proceed on a "pay as you go" model, driving down up front development costs
• Rapid Return on Investment
• Smalltalk is an extremely agile and productive system for the development of applications. Capers Jones research over the course of a decade shows that Smalltalk is three times as productive as Java. The same research shows that the rate of errors produced when using Smalltalk is dramatically lower
• High Value
• Complete binary portability - developers selecting Cincom Smalltalk can develop on their favorite platform and then deploy to any other - including Windows CE, Windows Mobile for Pocket PC, Windows XP Tablet PC Edition and Linux - with no changes. Cincom Smalltalk supports the x86, XScale, and StrongARM based mobile devices, as well as standard Windows, Unix, Mac, and Unix workstations and servers.
• Software Updates - updating software deployed to mobile devices is not simple - unless you use Cincom Smalltalk. Cincom Smalltalk applications can be updated quickly and easily, without requiring a full redeployment
• Complete Power - unlike J2ME or .NET compact edition, Cincom Smalltalk offers all the power of the full platform - whether the deployment is to Windows XP, Unix, Linux, MacOS, or Windows CE. No compromises are necessary.
• Complete interoperability with the relevant standards - Cincom Smalltalk offers full support for all the relevant communication and interoperability standards.
• Low Risk
• Maturity - Cincom Smalltalk has been under continuous development and deployment for over thirty years now - with great success at a number of Fortune 500 firms. None of the competing solutions can point to a similar record of robustness and maturity
• Stability - Cincom Systems has been in business since '68, under the leadership of the same CEO - Mr. Thomas Nies. Cincom has been supporting many of its products for more than thirty years - a record of stability that few firms can match
• Support - Cincom pioneered 24x7x365 support decades ago, and offers "whatever it takes" support to its customers. Developers selecting Cincom Smalltalk will never have to wait long for a solution to support issues

That's a white paper I created to point out the benefits of Cincom Smalltalk as a development/deployment platform for mobile devices. We are about to release full support for CE4 devices on x86, XScale, and StrongARM based devices with the release of VisualWorks 7.2.1 (part of Cincom Smalltalk spring 2004), due in May. We pushed a press release here

Register now for StS 2004 (only 11 days from now!) and enjoy an evening out at the Space Needle with the Smalltalk community:

Smalltalk Night at the Space Needle

Tuesday, May 4th, 2004
6:30 pm - 10:30 pm

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.

As an entertainment destination, the Space Needle is in a league of its own. The Space Needle is located at Seattle Center. That's an apt description of where we are: the center of Seattle. Whatever your interests - theatre, ballet, opera, professional sports, rock-n-roll history, roller coasters, science, movies, shopping, exploring or just plain walking around - the city unfurls from the Space Needle.

Built in 1962, the Space Needle served as the symbol of that year's World's Fair. It has since become the symbol of Seattle, and one of the most recognizable structures in the world. The privately owned Space Needle is managed by the Space Needle Corporation

See you in Seattle!

In subscribing to the Learning Seaside blog, I started seeing bad characters in the RSS Feed. In taking a look at this, I ended up refreshing my memory on the standards for http transmitted documents and for xml documents. It's an interesting little pathway into heck - here's the rules:

• Http transport: iso-8859-1
• XML documents on the file system: UTF-8
• XML via some transport (like HTTP or MIME): The transport default

Here's the relevant section on xml docs from the 1.0 spec:

In the absence of information provided by an external transport protocol (e.g. HTTP or MIME), it is a fatal error for an entity including an encoding declaration to be presented to the XML processor in an encoding other than that named in the declaration, or for an entity which begins with neither a Byte Order Mark nor an encoding declaration to use an encoding other than UTF-8. Note that since ASCII is a subset of UTF-8, ordinary ASCII entities do not strictly need an encoding declaration.

That's where, IMHO, a bunch of problems crop up. You create an XML document, encoded in utf-8. Now you make it available on a website, but forget to add encoding information. In most cases in the US, this isn't going to lead to any (obvious) problems. However, say this document comes from Europe, and has characters with accents (et. al.). Suddenly, you have badly encoded characters that show up on the client side as interesting garbage. Browsers mask this problem by having complex and sophisticated encoding guessers - they score the document if it doesn't have a declared encoding, and show you what seems best - and it usually works. Mozilla allows you to change the encoding if your eyeballs think the guess was wrong.

That's where I've ended up with BottomFeeder - I don't have the expertise to create a guesser, so instead I offer an encoding menu for the user in case it "looks wrong". For my example above, changing the encoding to utf-8 fixed all the issues in the feed. The choices I've made available are: utf-8, iso8859-1, iso8859-15, ms-1252. That ought to cover most of the bases, and allow people to fix clearly wrong encoding presentations.

In general, this whole area is a mess, and creates headaches for all of us who have decided to walk into it...

Specs are great, especially when there are so many of them. Take a gander at this comment thread on Sam Ruby's blog - it shows just how confusing this area is for everyone, myself included....

One of the Java guys apparently feels threatened by the existence of Cincom Smalltalk for Mobile devices.

I added a cross feed guid resolution and cross feed item referencing to BottomFeeder earlier this week. I just added a setting to allow those to be optional. Why? Well, it's a somewhat expensive operation (memory wise) if you have a lot of feeds. I had one user on old hardware complain that Bf had suddely gotten very slow, and it dawned on me that the reference gatherhing was the root of his problem. This likely means that I need to consider my implementation. In the meantime, it can be turned off in settings.