Smalltalk Tidbits, Industry Rants

There's a good take on programming language evolution over at Reflective Surface. I won't quote a lot; there's way too much good stuff to extract - go read it yourself. This segment stood out to me though:

Another concept that has gained wider acceptance in the last years is that of dynamic typing. Many modern languages have opted for dynamic typing to improve productivity and reduce errors. It's curious that Java and C#, languages created with market considerations in mind, use static typing, and are forced to provide resources to "violate" that concept because of its failings. (Boxing is one of such "violations", which tries to remedy the gap between value and reference types in those languages.)

Yeah, it's as if the language designers almost got it, and then fell back on more confortable, but less useful paradigms...

Via Matt Croyden:

Until Unix and Linux programmers get over their macho love for low-level programming languages, the security holes will continue to flow freely, argues SecurityFocus columnist Jon Lasser.

...

To be sure, some software must continue to be written in lower-level languages: Database servers such as MySQL will inevitably be written in lower-level languages for legitimate performance reasons. And it would be both unlikely and counterproductive for the Linux kernel or the system library to be rewritten in Perl, Java, or Python.

But none of those concerns justify writing an IRC client in C. And if it seems unimaginable for a print server to be rewritten in a high-level language, the reality is the benefit would be substantial and the performance costs negligible.

This is a message that most developers have not yet absorbed. See my post on premature optimization, for instance...

Here's an announcement from STIC on the re-establishment of the group:

Contact	Andrew Ignatow	Contact	Michele Gray
	Smalltalk Industry Council		Edelman
	513.612.2104		212.642.7746
	Andrew Ignatow		Michele Gray

LEADING TECHNOLOGY COMPANIES JOIN FORCES TO PROMOTE SMALLTALK

Newly Established Smalltalk Industry Council Includes Core Members Cincom, GemStone, IBM and Knowledge Systems Corporation

New Council Sponsors Smalltalk Solutions 2003 Convention and Trade Show

Cary, North Carolina, March 26, 2003 - To raise awareness and increase the demand for Smalltalk as the programming language of choice for application development, the Smalltalk Industry Council (STIC) today announced that it has reorganized. The new Council's core members include Cincom, GemStone, IBM and Knowledge Systems Corporation. Allen B. Davis, chief executive officer for Knowledge Systems Corporation, has been named executive director.

"Smalltalk is by far the best programming language available for Web and enterprise development," said Allen B. Davis, Executive Director, Smalltalk Industry Council. "Smalltalk is a mature technology and well supported. Since it is underutilized, STIC's mission will be to raise awareness of Smalltalk, which provides a simpler syntax, much higher productivity and easier maintainability than other languages. It is the logical next choice for software developers as well as for businesses interested in reducing their total cost of ownership for software systems."

STIC's first large initiative is the organization and sponsorship of Smalltalk Solutions 2003, the premier forum for Smalltalk users, developers and enthusiasts. Taking place July 14-16, 2003 in Toronto, Canada, Smalltalk Solutions 2003 will feature keynote speakers Scott Ambler, senior contributing editor for Software Development magazine and member of Flashline Software Development Productivity Council, and David A. Smith, co-developer of Croquet software and creator of "The Colony," the first 3D interactive game. It will also host a number of sessions, including "Smalltalk for .NET," "Smalltalk for Eclipse" and "Recruiting Object-Oriented Programmers."

"Smalltalk Solutions 2003 will bring together hundreds of buyers and sellers of Smalltalk products and services, while updating the industry on the latest in Smalltalk technologies," added Davis.

For more information on STIC, please visit www.stic.org. To exhibit at Smalltalk Solutions 2003 or for more information, please visit www.smalltalksolutions.com.

About the Smalltalk Industry Council The Smalltalk Industry Council (STIC) is a nonprofit trade association whose goal is to promote awareness and increase demand for Smalltalk. STIC was reorganized in 2003 by Cincom, GemStone, IBM and Knowledge Systems Corporation, creating a cohesive Smalltalk community where information, technical issues, new ideas and concerns are openly discussed to benefit businesses as well as the software industry. STIC's membership consists of users, service providers and vendors of Smalltalk tools, components, databases and services. For more information on STIC, please visit www.stic.org.

Copyright 2003 Smalltalk Industry Council. All Rights Reserved

In creating BottomFeeder, one of the early requests we came across was coditional-get. What's conditional-get, you ask? Well, consider what an RSS News aggregator does - perioidically, it queries all the sites you have subscribed to, gets their information via HTTP, and presents it to the end user. In the process of doing this, it executes an HTTP-get against all the sites of interest

Most people have their readers set to update every hour - possibly more often! Sites really don't like to get hit by the same user over and over again that way - in the early development of BottomFeeder, we got complaints about that. The solution - conditional-get. What is that, you ask? Well, everytime you do an HTTP-get, you get a fair bit of information about the document back - including tags unique to the document, and a timestamp from the last modification time. If you save those, you can insert that information into your query, and get a well defined exception when the document you are requesting is not new. This saves the site the trouble of shipping you the whole document - it instead sends a short "no changes" response, which VW sees as an exception. Here's how you do it:

Say I get a document this way:

response := HttpClient new get: 'http://www.cincomsmalltalk.com/BottomFeeder'.

If I look for two header tags and save them, I'll be ready to do a conditional-get next time:

lastModified :=  (response header at: 'last-modified') value.
etag :=  (response header at: 'etag') value.

Ok, Now I have the information I need; what do I do with it to be a good net citizen next time around? I add that information to my HTTP query:

client := HttpClient new.
req := HttpRequest new.
req method; 'GET' url: 'http://www.cincomsmalltalk.com/BottomFeeder'.
req getFieldAt: 'If-Modified-Since') value: lastModified.
req getFieldAt: 'If-None-Match') value: etag.
^[client executeRequest: req]
     on: HttpRedirectionError
     do: [:ex | ex parameter code = '304'
                     ifTrue: [nil]].

Now, you should check for other exceptions as well - what this code demonstrates is how to look specifically for a 304 (not changed) error. When you see that, you know that the document hasn't changed. The beauty of this is, if it has changed, the query simply returns the new document - along with the header information necessary to do a conditional-get again next time.

This is pretty much how we do it in BottomFeeder. If you want to take a look at the code, then get an account in the public store, and grab the package Http-Access - it's loadable separately from the entirety of BottomFeeder.

If you are thinking of optimization, don't yet:

There are many reasons to leave optimizations until later. The prime candidate is that the necessity to optimize is a very powerful force when writing the code. If it is applied too early, it can impact the codebase so powerfully that the code becomes unreadable from early on. If code is unreadable, it is unmaintainable, and it is unlikely it will function.

There's also the simpler problem - in my experience, developers typically don't optimize the right thing at coding time. They make assumptions about what will be slow, and pre-tune. The better bet is to write the code, see if it's fast enough, and then - if not - use a profiler before you do anything else.

I've been at countless customer sites where they told me - with authority - why something was slow. When asked if they had profiled, the typical answer was no. And usually, the profiler showed a different problem than their assumptions....

The actor playing President Palmer on 24 played Cerrano on Major League.

Heh. Could you come up with 2 more different roles?

Matt Croyden has some good info:

We got the OBD-2 connection to work on my car this evening.  We plugging an old P75 laptop into my 98 Golf, and whadda you know, the check engine light was due to a misfire in Cyl 2 a few days ago.  (I remember it now, I went into second right after starting the car while going up the hill, it was a mistake)  Mike cleared the error, we ran diagnostics again, error gone.

I'm glad I didn't have to pay the dealer to find that out.

Very cool - I'll have to look into that!

Patrick Logan has moved his weblog over here:

Anyway I have a new weblog, and I'd like to point out to you that I expect to increasingly mention Smalltalk over the coming months. (Call me born again.)

Welcome back Patrick! Pick up his RSS Feed Here

Michael Lucas-Smith comments here - but it's worth posting in a more visible place:

Reasons to mock, taken from the C2 Wiki

1. real object has non-deterministic behavior This is exactly why you need to test the realm object! 2. real object is difficult to set up Write the tests first, any object that is hard to set up was hard to make, but you did it with tests first, so.. not difficult to set up any more. 3. real object has behavior that is hard to cause (e.g., network error) (similar to 1) The hardest behaviour is often bugs. Testing bugs is essential so that we can say, "Yes, this bug will never occur again because we have a test for it". Extend your testing capabilities, don't dust it under the mat. 4. real object is slow Run your tests over night. Whether or not it's slow, you still need to know if it works or not! 5. real object has (or is) a UI So what? Do like I did and make yourself an SUnitView. Oh wait.. not using Smalltalk, are we? 6. test needs to query the object, but the queries are not available in the real object (e.g., "was this callback called?") Uhm? .. I've never had any trouble with this. Add the test as interested in the callback, then check if the callback happened. If it didn't, fail, if it did, pass. 7. real object does not yet exist Smalltalk - write it in Smalltalk. You don't -need- the real object yet. It fails nicely since you don't have code to test, but you do have tests.

Well

• sigh*

Good points all...

Reflective Surface is trying out VisualWorks, and having a look at the BottomFeeder Source Code for an example. Let's hope my code doesn't scare him off :)

Installing VisualWorks is very simple. To me, it was enough to unzip the contents of two files, and create a shortcut for the application. The environment is familiar since I've used Squeak (an open source Smalltalk environment) a lot of times in the past years. Obviously, there are some notably exceptions as VisualWorks is more geared to professional development while Squeak is more intended for educational uses. GUI development is completely different, but one can always resort to tutorials and help files to get started in that kind of programming.

Although I never completed a serious application using Smalltalk (I didn't know VisualWorks when I started using Smalltalk, and I don't like Squeak''s deployment model), this time I intend to use VisualWorks to implement a personal project I've been planning for some months now. This project will allow me to work with a lot of the Smalltalk and VisualWorks libraries and get up to speed with Smalltalk again. In fact I have downloaded BottomFeeder's source code to take a look at how a real Internet application is done with VisualWorks (BottomFeeder is a RSS aggregator), and I will use the next weekend to study it.

So, the fun is just beginning.

VW 7.1 and ObjectStudio 6.8 are close to gold. We have some repackaging to do, but the release is now ready to go. Unless something in the packaging turns up, we will be ready to release on time! Kudos to engineering for a great job!

The updated parcels went up earlier; I've now got the new base builds up.

This is interesting. There's a push to use something called MIME-RPC instead of either XML-RPC or SOAP. Here's the riff, and it makes a lot of good points:

• SOAP does not interoperate with existing browser based apps. MIME-RPC does.
• SOAP does not do generic object serialization
• SOAP forces the programmer to think about type coercion because it hides foreign data as base64encoded rather than labeling it with a useful type.
• SOAP does not handle delivery of XML or other types well. MIME-RPC does.
• The SOAP with attachments spec basically says to use MIME. If you are doing that, you might as well use MIME for everything (and therefore MIME-RPC).
• The SOAP with attachments spec is ambiguous about the type of attached objects. Should the type be interpreted according to its mime content-type or according to some XML schema? MIME-RPC provides an unambiguous interpretation.
• SOAP constrains method and variable names to be consistent with XML tag names. Many languages (e.g. SQL) allow method and parameter names that are not permitted in XML tags.
• MIME-RPC is much easier to implement correctly than SOAP
• MIME-RPC has less processing overhead than SOAP.

So will this call get any notice? Worthwhile though it is, I doubt it. As with Java in 1995, the industry will likely make a mad, uninformed rush to the more complex technology in favor of the simpler, easier to use, already proven technology. It's enough to make you think that the big consulting firms with thousands of bodies to sell control everything....

I spent the morning adapting BottomFeeder to the latest build of Twoflower from Holger. He's fixed some issues with the HTML display - this URL wouldn't display in the previous version. It works now. He also added a cleaner way to get mailto: links working - I had added a hack for it. The latest parcels are up, and should show up as available upgrades in the 2.8 dev builds. I'm in the process of replacing the full build downloads as well - new gzip files should be available later today.

Now, I've got to go update the collateral docs for VisualWorks - the old ones date from VW 5i.4, and are pretty dated. Ahh, the joys of Word editing....

A funny post on logical flaws with transporters on Star Trek:

Picard's brother owns a vineyard. (Jean-Luc Picard is captain of the Enterprise on STAR TREK: THE NEXT GENERATION.) That's cool--I dig gardening. But what does he do without migrant workers to pick the grapes? They never say, "Use the transporter to beam the juice from the grapes into the barrels. If they did, they wouldn't need surgeons cutting open Picard's chest; they could just beam in the new artificial heart.

Transporter field dynamics preclude it. Okay, I just made that up, but you know something like that'd be the justification if necessary.

Surgeons use micro-transport and micro-replication all the time. None of it is "point-n-click". That's why they are still surgeons.

I disagree, they never use transporter technology the way they should. They can beam themselves into the heart of a Borg ship when the plot requires it, but they can't beam in a truckload of photon torpedoes when they're getting their asses kicked. I think surgeons are around because no one in the 24th century ever figured out that they could beam fat globules out of your blood stream to avoid a stroke.

They transport only in carefully controlled circumstances, only specific materials masses and distances, and when they have time to plan.

They don't transport "in" a truckload of photon torpedoes, because transporter beams are too easy to jam - even certain planetary ionospheres can do it. (There's also the issue from whom they beam them - another StarFleet ship that's also under attack?)

And more like that. Very funny.

I went to this week's codefest at the XP DC Group. We paired off - each Smalltalker with someone who didn't know Smalltalk, picked a story, and started writing tests. The RB with the SUnit extensions was a big hit. The only complaint I got - and a valid one - is the need for more and better keyboard shortcuts. This is one we know about, and intend to address in VW.

I went to this week's codefest at the XP DC Group. We paired off - each Smalltalker with someone who didn't know Smalltalk, picked a story, and started writing tests. The RB with the SUnit extensions was a big hit. The only complaint I got - and a valid one - is the need for more and better keyboard shortcuts. This is one we know about, and intend to address in VW.

If springtime in Paris isn't enough, check out the SmallNic in Paris this April:

The french Smalltalk community would like to organize the 2nd SmallNic in Paris. What is a SmallNic ? It's something like a mix beetween a picnic and a coding party around Squeak and Smalltalk. The idea is to show what you want around Smalltalk (demonstrations, tools, research projects, ...) in a very friendly environment around computers (and pizza ?). We invite all Squeakers and other developpers from all Smalltalk flavors to join this event to share their enthusiasm and knowledge.

Contact	Serge dot Stinckwich at info dot unicaen dot fr
When	12 april 2003
Where	INJS, 254bis, Rue St-Jacques, 75005 Paris (Metro/RER Luxembourg - Exit : Rue Abbé de l'Epée)

Please add you name, email address and Smalltalk interests at the end of this page (click on the edit button). Take your laptop if you have one!

The C2 Wiki has some good posts up on bad management theories:

First Law of Bad Management: When something isn't working, do more of it.

Self Sealing Beliefs are those where you're erroneously convinced that some desirable result is caused by taking some particular kind of action. Subsequent failure for the desirable result to occur is not used as disconfirming evidence that you're wrong to be convinced that way, but is instead used as evidence of a need for more of that action.

Performance related pay may be one of these. It seems obvious that more pay for better performance will result in better performance. Studies however have shown little or no effect other than an initial jump.

It will work this time After an idea is tried and has failed, been tweaked and tried again, been tweaked and tried again, etc. my inclination to reject the idea and look for alternative solutions.

However, management (and colleagues) frequently claim that that they "know why it didn't work", proceed to address the most obvious manifestation of problems with shallow solutions and chant "ItWillWorkThisTime". (They disapprove of my "negative attitude".)

Yeah, I've seen (and had to live with) these sorts of thought processes more than once. All too common...

I'm still mucking about with the C2 Feed. The item dates are wrong - although I do seem to be getting the right items. You may see some shifting in this feed as I experiment with it. See the C2 Recent Changes Page to see what I mean. I'm currently limiting that to the most recent 50 items, which is why there's a lot more on the site than in the feed....

I've just finished scraping the C2 Wiki. The feed is here. There's always a lot of interesting commentary going on there, and I always forget to check. Now I can track it in BottomFeeder

Earlier today I posted a link to a new feed - I scraped the VW Wiki. I've moved the feed here. The link I posted earlier will also still work.

So now, I have a scraping of the EzBoard Smalltalk Forum - the feed is here.

If anyone has suggestions for other Smalltalk oriented sites that you would like to see scraped for an RSS feed, I'll be happy to take a look. If it's feasible, I'll take a shot at it

I've added a new RSS Feed - I'm scraping the UIUC Wiki, and have the feed here. It turns out that scraping the Recent Changes page was pretty easy.

Mark Pilgrim says...:

IE users can blow me. It's the inline lists. I can either maintain proper markup, or I can make it look right in IE. I don't know how to do both.

Heh. I often feel that way about IE, but it is used by the vast majority of users. If you look bad in IE, you look bad to most people....

Sigh. My cable provider - Comcast - just jumbed their channel lineup around. Their channel guide is all screwed up on the digital cable box, and the Replay TV guide still has the old information on it. To add to my joy, Sonic Blue is going under, so who knows if they'll ever update. Sigh....

We have an RC (Release Candidate) build which is being hammered on. Past experience tells me that we will need another build or two before we go live, but the release is definitely getting closer.

The difference between good writing, and bad writing....

Ok, I have to admit - the opening was cool. But still, I find that the series has mostly lost my interest - it just got too wacky this last season. This episode looks pretty cool - looks like they put it back together for the end. Then there's the fact that one of the plot sidebars has been completely overtaken by current events, but nevermind.

Well, it's clear that the series wasn't intending to end there. Irritating....

I've posted a new BottomFeeder Dev Build. There are two new platforms available - Linux PPC and Linux Sparc. These platforms are not formally supported in VisualWorks (on which BottomFeeder is built), but this is a good way to test out the platform. The latest TypeLess is part of this as well. I have not updated the TypeLess parcel in the BottomFeeder upgrades directory - it requires the new base image I just built. Give it a whirl and let me know what you think!

What does the chapter 11 filing of SonicBlue mean for the ReplayTV?

Life without ReplayTV. Shudder

and also cleaned the back end code up as a result. There's more I'd like to do, but I have to actually go figure out style sheets for that. I've been putting that off for awhile now....

For your input. If you haven't given us feedback, please do so here

I taught the last Smalltalk class for the winter today - I've been using Squeak to introduce 4th and 5th graders to programming. We had a look at EToys today, and we went through the make your own car tutorial. The kids picked it right up - after I walked them through the car, they were able to add the steering wheel and get going. They had a lot of fun, and learned something while they were at it. I'll be better prepared next time, and start with the EToys stuff.

Eliot Miranda posted up an explanation of the VW threaded API call mechanism. While this is a feature VW has had since 2.5.2, many people still seem to not know about it....

Scott Johnson is not amused by ATT support:

I start to traceroute and give him feedback about the broken routes. I ask him: What's an email address so I can mail it to you? "I don't have one". What's a hot mail account I can send it to? "I can't give that to you either." So I ended up reading him the bad routes. Pathetic. And this from a company that sucks $50 from me monthly for broadband?

I finally give him the info, he checks it from there after a 5 minute hold session and B I N G O ! I was *right*. They have a problem on their internal network and then I had to wait on hold for another 5 minutes while he filled out a trouble ticket. Then I got the really bad news.

"It'll be resolved within 72 hours. Not necessarily fixed but hopefully a solution decided upon." What the fsck does that mean ? That within 3 days from now, you'll decide how to fix it and then take as long as you like? Utterly, totally pathetic.

Yeah, I've had to explain networking to Comcast before - and trust me, I am no networking wizard. Just say the word "Linux" to a Comcast rep and watch them try to claim that it's all your fault, even when the problem is signal strength. And then there was my happy times with Sonic Blue support. Are these vendors just trying to drive us away?

Over Here. Cool!

At least, once this sale goes through

Navigate your way here and have a look. There are many more details in the Release Notes, which will ship with the product. Make sure to have a look at those after 7.1 ships

Camp Smalltalk 6 is gearing up, June 22-26 in Germany. Have a look at the projects, the attendees, and the registration. There are tips for getting to CS6 here. I won't be going - Smalltalk Solutions is shortly afterwards, and the schedule for CS6 doesn't work for me - my daughter's summer vacation will just be starting then. Looks like a good camp though!

I'm preparing for the last Smalltalk class for this group of kids - I'm going to have them work on this today. We worked on extending the demo last week - this week, we will work on creating it from scratch. The kids should enjoy that.

I'm teaching this again in a few weeks, and I think I'll start with the EToys stuff right off the next time. It's fun for the kids, and also gets them experimenting. Highly useful stuff!

This post pounts to some good guidelines for development. While they are aimed at Java, the design goals - numbers 1-35 at the beginning - are applicable to Smalltalk as well. For that matter, easier to accomplish in Smalltalk....

While watching the wall to wall war coverage, I found and fixed a nastly little bug in the 2.8 code. I was missing a method implementation! Found that in testing. Hopefully, no more of those lurking on the code....

Then I saw these pictures from the Denver storm. Wow

I can point to two things:

• This document on migration issues
• If that doesn't convince you, look at this from comp.lang.smalltalk

Here's some Smalltalk code:

aminoAt: aString
     ^self aminoList detect: [[:amino | amino name = aString] ifNone: [[nil].

Now the equivalent C#

public CodonAmino getAmino (string aName)
{
    bool found = false;
    CodonAmino amino;
    IEnumerator e = this.AminoList.GetEnumerator();

    while ((found == false) && (e.MoveNext()))
    {
        amino = e.Current;
        found = (amino.Name == aName);
    }
    return found ? amino : null;

The extra typing alone.....

And doing bad things with HTML while they're at it. Go see what Scott Johnson has to say on this:

Someone needs to teach the "gotdotnet" folks what RSS is. Also I couldn't believe their HTML source when I was poking around. So get ready for a vent.

Go look here and look at the __VIEWSTATE input element. To me that's just plain lame. Use a session, send a cookie and use your horsepower for this, not my bandwidth with every page view. And if you really want to barf then click around a bit and go here. They seem to be encoding the entire viewing history in a really nasty way and shipping it back to you every single time. It just gets bigger. After navigating thru like 3 pages I had 6,554 bytes sent down the wire that did nothing for me. Thanks for nothing.

I guess its not all that bad actually but it just seems damn silly. I hope that's not a dot net feature but I'm afraid that it is. Sigh.

Just look at the kind of crusty HTML produced by Word when you do a "Save as HTML". Bleah...

I said this morning that we had one issue that we knew had to be dealt with before we ship VW 7.1. well, engineering found and fixed that issue, and the fix is in code review. There's a build going forward today that won't have that fix, but it loks like we are down to the last little bits here. This is going to be a great release!

As he posts here. Yeah, I've been there with the mini-van. Last year the engine light started blinking periodically. Oil was fine, nothing else seemed to be wrong - and the mechanic I trust couldn't find a problem. It turned out to be one of the sensors in the engine giving a bogus reading, and that required replacing the sensor. It cost way more than was reasonable - and they tried to baffle me with BS on the whole deal, telling me that replacing a chip was complex. Get ready to open the old wallet Matt....

The next release of Cincom Smalltalk is getting close. There was a last issue with menus on the Mac (OS 8 and 9 only) that we were having trouble tracking down, but my email tells me that we have a fix for that. That means that release by the end of this month looks good

BottomFeeder 2.8 will go out as soon as VW 7.1 does - I don't want to ship on a pre-release, and I would like to have the "goodie" parcels in VW match an actual release.

Meanwhile, check out this page to see what's coming!

Got caught by a silly lazy intialization bug - the method that answered a collection of urls to send web log pings to after each post was just answering self, and that caused entertaining problems. fixed now, and I should be pinging all the usual suspects again. Ahh, the joys of on the fly updates....

The traffic in the DC area has been utterly snarled ever since this started. I sure don't need that kind of thing adding to the joy of drive time...

Willow is on Angel tonight!

Gotta get those priorities straight....

Have a look at the Smalltalk Solutions site - things are gearing up for the show. We have a nice set of presentations, and the program team is in the process of sorting out, organizing, and scheduling them. Sign up to attend now!

I posted yesterday on security and posting - the Blogger API in particular just passes usernames and passwords in the clear. I'm following the CommentAPI discussion on various blogs - mostly here.

The theory seems to be to replace various ad-hoc HTTP posting methods with some XML based posting/comment API. And again, security has gone missing. Sure, comments don't need a security story. But posts - updates and new - need authentication of some sort or another. I encrypt everything in my tools.

Come on people, get serious!