Smalltalk Tidbits, Industry Rants

Scoble raves about the Tablet again:

But, this whole thing points out a disconnect. I'm using the latest latest stuff. It has radically changed my life. I can't, and will not, buy a portable computer without the Tablet PC features anymore. It's changed my life that much.

Why? Well why don't you meet me in Southwest Airlines on Friday evening and I'll show you why the Tablet PC is so superior for air travelers?

All this reminds me of 1986. Remember that year? Remember what they were saying about the Macintosh? "It's dead," they said.

Notice one crucial thing about the Mac - the market share. And it's not because DOS was better. It's because a Mac was $2k - $3k more expensive than a DOS box was. That's why I bought a 386 DOS box instead of a Mac back in 1987 - I was unwilling to part with the extra $2K. Well, the same now applies to Tablets. Ink is nice and all, but it's not $2k of nice. It's a niche product until the price point equalizes.

Scott Johnson points to a really, really nasty attck based on presumed trust - and he's dead on about how easily people (tech geeks included) will fall for this. That is one nasty, nasty idea there.

TechRepublic.com reports on a judicial block of a SpamCop blacklisting:

A Northern California District Court judge issued a temporary restraining order to prevent SpamCop, an antispam operation, from interfering with messages sent by alleged junk e-mailer OptInRealBig.com.

Now, spam irritates me - a lot. On the other hand, I despise blacklists. The way SpamCop runs them, it's virtually impossible to get removed from such a list, and they occasionally block mail from large ISP's - I've had them block outgoing mail from my ISP's email server. A pox on both their houses....

We have a new blogger on the Cincom Smalltalk Blog site - Professor Ralph Johnson of UIUC (and one of the co-authors of the GOF book). The blog is here - subscribe to his feed here.

There are a few posts on the Tablet PC this am - Scoble over here, Julia Lerman here, and the story that spawned these posts here. I think the lot of them miss something crucial - IMHO, the Tablet is a niche product. Yes, I'm sure that people do like them when they see them. I'm also sure that most people have no real need to scribble on a screen. Think about it - how many tasks do you actually do in a day that would justify the extra cost of a Tablet? To my mind, the Tablet is a great product for a set of vertical markets - and a nice to have, but not important thing for everyone else.

Now, that may change - 5 years ago, notebooks were not something that most people thought of as a desktop replacement - that's not the case now. Over time, the Tablet may become that way as well - but I think this will happen only as the price differential drops towards nil.

Update: Matt Crowden makes my point:

Price is probably the number one factor that is keeping the Tablet PC install base down.  I've looked at a few TabletPC models at my local Micro Center, which usually has a few in stock, and their sales guys know much more than your standard CompUSA or Best Buy.  I played with a Tablet PC.  It was a compelling experience.  Unfortunately it wasn't two grand compelling.  It wasn't twice as much as I ended up paying for a higher spec'd but bigger (and non-tablet) laptop that I ended up getting

Price is the reason I bought a 386 based PC back in the late 80's instead of a Mac. I liked the Mac - but I didn't like the $2k price differential. Ditto for the Tablet...

Patrick Logan points to a ComputerWorld case study of the Kapital system at JP Morgan:

Technology is essential to the success of any high volume derivative business. The technological underpinning of Kapital is based on one of the earliest and some would say most pure object oriented development languages currently in existence 13 Smalltalk. The current incarnation of this language called VisualWorks has been married with a database technology called Gemstone. The combination of Smalltalk and Gemstone was the technology of choice at the start of Kapital. It continues to be the technology of choice today as it enables the following system characteristics:

• The creation of an application architecture that hides the technical complexities from financial developers.
• Distributed calculations are decoupled from the financial domain and increased compute power is achieved through machine on-boarding (e.g. recent machine on-boarding using PC blades and Linux)
• Allows business users and financial developers to create any type of new business object and save it and share it.
• Allows for disparate development teams, who are focused on different business areas, to develop solutions at different rates

Why are they using Smalltalk with all the Java and .NET buzz about?

Identifying new market opportunities is available to all investment banks. However, profitability and success come from being able to execute on those new market opportunities before the competition. Using Kapital, enables both business and IT staff to prototype and develop new ideas that can be promoted into product sets. This rapid turnaround of idea to product empowers JP Morgan to market and trade new deals before most of the competition. In the world of highly complex derivative products, JP Morgan is the number one investment bank.

Oh, and that canard about it being "too hard to find Smalltalkers?"

With the size and complexity of the system (14,000 classes and 400,000 functions) written in an esoteric language and database, one would assume that the technology would be the limiting factor in its continued growth. However, the greatest difficulty for Kapital is not the technology, but understanding the business and business processes themselves. With the developer firmly in mind when Kapital was originally put together, new financial developers can be on-boarded and be productive within four to six months

Go read the whole thing - and then download Smalltalk and try it out.

Every so often there's a "where are all the Java apps" thread on the comp.lang.java.advocacy newsgroup - for instance, here's the latest thread. Well, that got me to thinking - RSS/Atom/Syndication has gotten to be a fairly active application area - there are many, many readers out there - here's one list of the most popular ones. What I've noticed is that there are a bunch of .NET based aggregators, a bunch of aggregators specifically for Windows and/or Mac - but none of the commonly used aggregators are Java based. Now, I know that there are lots of Java developers out there - and yet somehow, no one has created a widely used aggregator in Java. That's fascinating. Oh, yeah - there is a widely used Smalltalk based aggregator :)

It's a good idea to consider every post you make to a blog - and Mark Pilgrim points out today's example: Google re-edits. I seem to recall pointing this out awhile back....

Staffen Malmgren discovers Seaside, and likes what he sees:

At first look, Seaside doesn't look much different than ASP.NET. It's all about modelling your application's interface in terms of objects and methods ("messages" for you Smalltalkers). Pages are built up of components, inheriting from System.Web.UI.Control (ASP.Net) or WAComponent (Seaside) that can include other components. When the user does things with any component, it results in events being fired (ASP.NET) or messages being sent (Seaside). Both frameworks seem to strive to abstract away the request/response nature of the web, and to allow the programmer to use a more event-driven approach to developement. In addition, seaside uses at it uses continuations to make it possible to, for example, ask the user something (similar to how a modal dialog would do it in a normal GUI enviroment), and then do something with the provided answer -- all within the context of a method.

The main difference is that programming in the Seaside framework results in a lot less housekeeping code. The object is really a ordinary object, except that it's executed through the web. The difference didn't really dawn on me before I tried to recreate WACounter as a ASP.Net Server component -- it did involve a whole lot of code to handle events, manage viewstate and so on.

It's cool that people are finding out about Seaside and what it can do.

The Baltimore Sun answers the questions you didn't know you had.

So Scoble says that the XP SP 2 rev will have IE mods. Will this fix the absolutely horrible thing that the last "fix" did to IE? Apparently, there's a security hole in IE involving the use of urls of the form: http://username:password@www.host.com. You would think MS would fix that, hmm? Why no - their solution in the last set of patches I grabbed from the Windows Update (read: downgrade) site just turned that feature off. You try to use it, and IE gives you a "Syntax Error page". Grrr - at least this explains why I've been getting mail from people trying to download CST NC via http. Here's what Scoble says about the fixes:

While we're on it, this page has one falsehood. It says that the next version of Internet Explorer won't come out until Longhorn. That is absolutely NOT true. The next version of Internet Explorer comes with a ton of security fixes, and a pop-up-ad blocker. It will be included in Windows XP, Service Pack 2. For free.

It darn well ought to be free, when it's a downgrade. There should have been a big warning on the last set of patches: "Warning - this update turns off useful features of IE, because we can't be bothered to fix the actual problem. Download at your own risk".

Bob Congdon points to this excellent essay that I've been meaning to discuss:

The golden rule of programming has always been that clarity and correctness matter much more than the utmost speed. Very few people will argue with that. And yet do we really believe it? If we did, then 99% of all programs would be written in something like Python. Or Erlang. Even traditional disclaimers such as "except for video games, which need to stay close to the machine level" usually don't hold water any more. After all, who ever thought you could use an interpreted, functional language to decode Targa images, especially without any performance concerns?

Follow the second link to the original essay - it makes a point about how fast things now perform even in fully interpreted languages on modern hardware - pointing to the absurdity of things like primitive data types in Java. In the vast majority of applications now, that counts as premature optimization. The software industry is guided more by inertia than logic. People continue to select unproductive languages based on the "everyone else uses it" mindset. They stick with manifest typing, even when the best data we have (from Capers Jones) - shows that languages like Smalltalk produce lower error rates than languages like Java. This in turn empowers the managers who want to offshore development - if the results are bad in any case, they may as well be bad for less money.

I'd say that the software industry is where manufacturing was in the 70's - complacent and ready for a kick from foreign competition - but I don't see that happening anytime soon. Why? The big Indian firms are all into huge masses of paper and CMM compliance levels - my cantankerous theory is that you should avoid any firm that claims CMM-5 like the plague (unless you like rigid requirements and huge backwashes of paper). If you really want to outpace the competition, you might want to pick up a dynamic language - Smalltalk, Python, Ruby, Lisp - and run with that.

Bad news for those of us who like coherence in a series - "Enterprise" looks to be back next year, with Berman still running things. If UPN wants to improve the series, the best thing they could do is to fire Berman. Can you imagine a Star Trek with Joss Whedon - i.e., someone who can actually create a story arc that hangs together? The best I can say for "Enterprise" this year is that - unlike "24" - it hasn't completely jumped the shark....

I posted on this topic back here and here. Now, I've come across this perspective on the issue from a woman "in the trenches" as it were. I can add a side note to this - I introduced my daughter to this Girl Scouts site, and she explored it for a bit - but peer pressure intervened and she's back on NeoPets - because all of her friends are there. Now, there's some (small) value here - she's starting to learn bits of HTML and CSS - the site allows you to build pages - but it's not exactly what I had in mind, either. I'm not sure how - as a parent - you manage to redirect towards "better" content. I mean, it's not as if NeoPets is a bad site. Time wasting, sure (but then again, no more so than BSW, where I spend inordinate amounts of time playing Puerto Rico....)

As much as I think Atom is a waste of time, end users shouldn't have to care - that's why BottomFeeder supports the format (both 0.2 and 0.3 - change your upgrade path to 'dev' in order to get proper support for 0.3). So I was a little surprised to see Scoble complain that Radio still doesn't support the format. That's just silly. Atom is a clone of RSS with different tag names; adding support to a tool that already handles RSS is trivial (it took me less than an hour for Bf). As I recall, I only needed a couple of slight additions to the domain model (the additional dates, for instance) - almost everything was a simple mapping issue....

In a Planet Lisp entry, I see that this blog shows up in a PubSub search feed for Lisp references. Heh. I mention Lisp from time to time when I'm discussing the general topic of dynamic languages, but Planet Lisp is where you want to go for Lisp Info. Also Bill Clementson's blog.

MSNBC's business wire picks up the Cincom Press Release congratulating Alan Kay.

James Gosling says that the world needs more "crazy" people:

There's an interesting article at Wired: NASA Funds Sci-Fi Technology. It's all about a part of NASA that funds projects that many would consider completely crazy....

Most real innovation is done by crazy people doing crazy things

Maybe he could follow that advice, and advocate for a JVM that would properly support dynamic languages. Nah, that would be crazy....

We had one heck of a set of thunderstorms roll through the area last night - at one point, my wife and I ran to the door to see what had gotten hit (a particularly loud clap of thunder that seemed simultaneous with the lightning. I'm sure it hit something; I haven't had cable modem service since then :) The cable TV signal has been horrible as well; I suspect that the signal reaching my house is too weak to get me net access. So here I am, feeling the power of dialup. Maybe I should have held on to that AOL CD that came in the mail Saturday....

After many requests, I've added a preview function to the comment form on the blogs here. It only works if you have cookies enabled though. There's also a pointer to the wiki style markup rules that the comment form supports - if you check the appropriate box, those rules will be used when you post.

The NYC Smalltalk User Group is running a poll (membership required) - they want to know whether an StS in New York City would pull in people. Our (the STIC) primary concern with an StS in New York has been the high cost of New York City. In any case, if this is of interest to you, join the STUG's mailing list and let them know what you think

Some image formats are "lossy" - i.e., putting an image in that format can lead to lost information. I'm starting to feel like Java and the CLR are "lossy" with respect to the entire field of software development.

First, there's this post from Roy Osherove. Now, Roy is a good guy - I've had some very pleasant exchanges with him via the comment sections of our blogs. But look at this - in response to a post I made about BottomFeeder plugins:

I wonder how plugins are supported in SmallTalk. What's the Smalltalk equivalant of Reflection, for example? of a DLL? dynamic loading?

Is there an equivalent of reflection.... It's kind of hard to know where to start with that, honestly. The reflection that actually exists in the CLR is a pale reflection of what you get in Smalltalk. I mean, take a look here - that's a paper from OOPSLA '89! I'm not quite sure how you would implement Method Wrappers (the cited page is old, and newer code is already shipped with VisualWorks) in C# or Java. Reflection in Smalltalk is just so much more powerful than what is available in the mainstream languages, but the mainstream languages are so prevalent that it's as if the information has been lost.

Take another example - this post by Victor Ng - he asks which camp is worse, Lisp or Smalltalk:

Which camp is worse? The Smalltalk people or the LISP people? It seems that both those groups just love to say "we did 20 (or 50) years ago"

I suppose it does come off as arrogant and irksome - but it's the simple truth with respect to so many things in software development. Just take a look at one of the big things buzzing around the software world at the moment - self healing systems. In Smalltalk (or Lisp, or other similar systems), new code can be loaded into a running system and override existing methods - or add new methods to existing classes - or add attributes to existing instances - all without having to take the system down or having to worry about the state of objects in memory. Heck, I patch this blog server that way all the time. Lars Bak talked about this in the context of small devices, explaining why Smalltalk was such a better choice - the ability to do on the fly updates.

The dead hand of rigid systems holds the entire industry back. You have to jump through enormous hoops just to accomplish the simplest thing. I'm hardly the only one thinking this - I referred to this essay just the other day. Developers new to Smalltalk tend to pick this up right off

We need to do a better job of explaining this - or else the information loss is just going to continue

Before he left, Michael presented me with a small container of Vegemite. I gave it a try out at StS 2004 (just a dab on the fingertip) - it was very strong that way. So I brought the container back home with me, and it's been sitting on the counter since last Thursday..... So I finally decided to take the plunge. Following Michael's instructions, I:

• Toasted some bread
• Spread butter on the bread
• Took a small bit of vegemite, and added a thin layer into the buttered toast

And it was pretty tasty! Durned Aussies - it's not like they sell this stuff here :) - but it can be procured online. Hmmm

Update: I just found these two hilarious descriptions of Vegemite here and here. And don't forget the "vegemite song"

I went to see Van Helsing yesterday afternoon - it's an ok movie, although the CGI is pretty weak at certain points - the opening with Mr. Hyde is not that well done, IMHO. The movie does move right along though - which is good, because if you stopped to think at any point, you would notice that the plot was as thin as Friday's soup at the elementary school. It's an enjoyable enough "bubblegum" flick - i.e., if the popcorn is good, and you don't really have anything better to do with two hours, go ahead and see it. Otherwise, I'd say wait for it to come to cable.

Patrick Logan states the truth of it:

So JDO is a mess (original report), certainly EJB is a mess (hence JDO), but let's face it, the root cause is the language itself.

And it's not any better over there in CLR-ville either. The dead hand of rigid systems is holding the entire software development world back....

This is a fascinating story about free WiFi access - and the way it's quite possibly outrun the law:

There is little doubt that when you "piggyback" the WiFi signal you are "accessing" -- or "using the resources of" -- the device that is providing the Internet connection. There's also little doubt that routers, access points and gateways are all computers within the meaning of federal law.

The U.S. federal computer crime statute, Title 18 U.S.C. 1030, makes it a crime to knowingly access a computer used in interstate or foreign communication "without authorization" and obtain any information from the computer. A separate provision makes it a crime to access a computer without authorization with "intent to defraud" to obtain "anything of value." Fortunately, this provision also specifies that it doesn't apply if "the object of the fraud and the thing obtained consists only of the use of the computer and the value of such use is not more than $ 5,000 in any 1-year period."

The article goes on to point out that the law was never written with WiFi access points in mind, and that it's not going to be used that way. Still, it points out how unintended consequences tend to slip through when broadly worded statutes are written up. The thing is, this has broader application than just WiFi and law - companies often have very broadly written policies - where the intent is to stop people from doing something bad. Written broadly enough, do they also stop people from trying anything new? Something to think about the next time you sit down to write up a policy directive.

Back to the legal issues on this. The article points out something really interesting about the fallout from this:

But wait, you say, I didn't knowingly access the computer without authorization -- there was no security on it. How was I supposed to know that I wasn't allowed to access the WiFi connection? Here is the troublesome part: If you accept this argument -- that by broadcasting a connection you are inviting others to share it -- you end up on a slippery slope. How much security must you have on a system in order to be able to prosecute someone for accessing it without authorization?

That is a slippery slope, no mistake. Now translate that to the cable segment you live on if you use the local cable company for internet access - see how easily you can fall off this cliff? Go read the whole thing - it'll start you pondering this mess...

Vince Bourgon explains why getting things done in the "modern" languages is so painful - virtually nothing has been learned from the the past - heck, MS has even forgotten what made Basic productive...

No interactive interpreter

I think this was one of the biggest annoyances of all. When I learned languages like Python, like Common Lisp, like Smalltalk, it was always possible to easily and interactively test things. The fact that to test simple things in C# I had to build a whole program, write what I wanted to test, have some output functions to see the results, compile and finally run the program. This took time, and when I had a bug, I had to go back to my editor, find the faulty line, fix it, save and try to compile again. This was much slower than using an interactive interpreter. I had never used sockets in C# and had to make a small program to see how they worked and all. Again, an interpreter would've made things easier and faster. If it wasn't for the very complete MSDN documentation, C# would be a much, much tougher beast.

Gosh knows how far I ever would have gotten with BottomFeeder without the power of Smalltalk. Clearly you can do such projects in C# or Java; there are plenty of such readers out there. But it's harder to get things done. When it's hard to get feedback, it's hard to be productive. And then look at this example:

Simple stuff is made complex

My program contains a Hashtable with the keys being school numbers their name (001 - School Foobar) and values being their IP address. When I ran the program for the first time, I realized something that I hadn't thought of: Hastables are unordered. I wanted the school to go one by one, in alphabetical order. I had this line in the program foreach (string key in ht.Keys)

So I said to myself that the simplest thing would be to change the line to:

  foreach (string key in ht.Keys.Sort())

But this resulted in a compiler error. The hashtable Keys properties returns an ICollecton object which cannot be sorted. So I thought, I just need to take the ICollection object and cast it to an ArrayList:

  ArrayList myKeys = (ArrayList)ht.Keys;
  myKeys = myKeys.Sort();
  foreach (string key in myKeys)

But this raised a runtime exception. After some googling around, I found a solution on this page. Basically, I would need to create my own class called IterSort() to sort the keys. Who else thinks this is way too hard? On the other hand, look how I could've done it in Smalltalk:

  
  d := Dictionary new.
  d add: 'Hello' -> 'World';
    add: 'Bonjour' -> 'Monde'.
  d keys class. "This returns the class of keys, which is a Set"

Now that I know it's a Set, I can just sort it by converting it to a sorted collection:

  d keys asSortedCollection.

The whole thing is just so much easier in Smalltalk than in C#.

He's got other good examples, but the two above illustrate something - yes, there are scads and scads of libraries available in Java and C# - this is something that is continually pointed out to me. On the other hand, if you have to constantly plow through crap like the above, I'm not sure the library size buys you as much as you think - especially when systems like VisualWorks already support a sizable proportion of the extant stuff you need. Take a look at his article, and let me know what you think.

Brad Abrams covers some of the TechEd sessions.

There's a Java/Server conference going on - I've been reading the coverage over on the Bile Blog. It would be nice to get an alternative POV :)

Wired News has a report on the WinHec conference (held in Seattle at the same time as StS, actually). I was kind of interested in some conference reporting - something like this or this from StS. However, all I've been able to find is stock media summaries. Were there no bloggers taking notes?

Via Lemonodor

<malaclyps> i'm going to Camp Smalltalk this year
<malaclyps> i believe as a UN Observer
<malaclyps> it's like Camp X-Ray but the interrogators try to get the prisoners to document their code

LOL

Pete Kruckenberg makes some good points while letting a rant go about Java - here's what I mean:

If you can't develop Java code that is 100% compatible with every version of every JVM, in an application that is compelling to be portable, don't bother. Compile it to a binary for the platform that I'm using, and make it look as good and work as good as any other application for that platform.

Ignore the reference to Java there, because it's a universal thing - end users want an application, not an installation problem. I've tried to get there with BottomFeeder - the only place I really miss is Mac OS 9 (I still need access to the hardware). From the few people who have tried downloading Bf for that platform, I know where Peter is coming from.

PR Opinions posits that the wider array of information available (for any and all products) is making the sales cycle longer and more complex:

In the past, I might have got a couple of brochures from some manufacturers, visited a couple of retail outlets and made a decision. Today that purchase process is far more complex.

I'll search for all the manufacturers. I'll go to all their sites and read their literature.  I'll visit the relevant magazines and read the reviews, visit mailing lists, consumer opinion sites. I'll still pop into the retail store and finally I'll make my "educated" opinion. Then, once I've parted with my cash and my post-purchase cognitive dissonance sets in, I'll re-visit my chosen vendor's website to be reassured that I made the right decision.

That is a longer and more demanding sales cycle.

Hadn't really given this much thought, but it sounds right. There's a positive to this as well - in the software space, the "row of books at Borders" problem has been ameliorated somewhat. As more and better information appears online, you can compensate better as a niche player. It takes work, of course, but it can be done. Read the whole thing.

Ted Leung points to some IBM blogs - Grady Booch and a number of other people are listed on the site. Ted is complaining about the RSS feeds being for the current month only. I'm not going to complain about that - the feeds for the Cincom blogs are a rolling snapshot in time. I'll have to trawl through the IBM site and see what looks interesting.

Nasa aims to find out - check out this experiment.

Joi Ito points to an NYT article (free registration required) on IRC - surprise - the Times is convinced that IRC is a huge den of iniquity:

Even as much of the Internet has come to resemble a pleasant, well-policed suburb, a little-known neighborhood known as Internet Relay Chat remains the Wild West. While copyright holders and law enforcement agencies take aim at their adversaries on Web sites and peer-to-peer file-sharing networks like Napster, I.R.C. remains the place where people with something to hide go to do business.

That's right gang - all we do on the Smalltalk IRC is trade illicit copies of movies and games. No technical conversations, no meeting with far flung friends, no ad-hoc support - not according to the Times. It gets worse:

"I.R.C. is where you are going to find your 'elite' level pirates,'' said John R. Wolfe, director for enforcement at the Business Software Alliance, a trade group that fights software piracy. "If they were only associating with each other and inbreeding, maybe we could coexist alongside them. But it doesn't work that way. What they're doing on I.R.C. has a way of permeating into mainstream piracy.''

Ahh, the fine folks at the BSA have been interviewed. These are the people who who help transform your business into a user hostile gang. And the NY Times is enabling that sort of mindset to spread with sludge like this:

When I.R.C. started in the 1980's, it was best known as a way for serious computer professionals worldwide to communicate in real time. It is still possible - though sometimes a bit difficult - to find mature technical discussions among the tens of thousands of I.R.C. chat rooms, known as channels, operating at any one time. There are also respectable I.R.C. systems and channels - some operated by universities or Internet service providers - for gamers seeking opponents or those who want to talk about sports or hobbies.

Still, I.R.C. perhaps most closely resembles the cantina scene in "Star Wars'': a louche hangout of digital smugglers, pirates, curiosity seekers and the people who love them (or hunt them). There seem to be I.R.C. channels dedicated to every sexual fetish, and I.R.C. users speculate that terrorists also use the networks to communicate in relative obscurity. Yet I.R.C. has its advocates, who point to its legitimate uses.

After the obligatory "some people on IRC are ok" comes the slam - and it's quite a slam, making sure to associate IRC users with groups that the mainstream Time reader is going to find unsavory. Here's the thing - IRC is no different from any other human activity. There are nice places and not so nice places. Just as there are clubs where you can go and hear music (and others where people engage in slightly less savory activities) - there are a wide variety of IRC channels. I suppose the Times has to play up the "ugly" as a way of pushing sales. People are people, online and offline...

Via CLS, news of an upcoming STUG meeting in NYC - if you missed Smalltalk Solutions, here's a chance to see one of the talks:

Please join us for our second presentation of the month on May 18th.

Speaker: David Buck
ElastoLab is a shrink-wrapped VisualWorks application that allows kids to design their own 2D scenes that incorporate physics elements like particles, springs, and gravity and lets them see their scenes animate in real-time. Originally written in C , it was later completely re-written in Smalltalk.

David will be talking about the development history and the design challenges in writing ElastoLab. The talk will explain:

• how to interface to the Windows sound facilities from Smalltalk
• how to make graphical applications run quickly
• how to package a Smalltalk application for release
• developing help facilities and guided tours
• using the web toolkit to develop a message board on the Internet for ElastoLab.

A CD-ROM of ElastoLab will be available to all attendees.

Date	May 18, 2004
Location	Suite LLC offices
Address	440 9th Avenue, 8th Floor
Time	6:30pm to 7:00pm -- Open house
Time	7:00to 8:30 pm -- ElastoLab

Directions:
Take E or C train to 34th (Penn Station) walk to corner of 34th and 8th. Walk up one block to 9th.

RSVP is requested. Please send mail to: charles@ocit.com with subject line of: NYC Smalltalk May 18th, 2004.

Via CLS, news of the next STUG meeting in NYC - if you missed Smalltalk Solutions, here's a chance to see one of the talks:

Please join us for our next meeting to be held May ,Tuesday 11th.

The OpenSkills Skillsbase Project
experience report
Bruce Badger: OpenSkills

Abstract: The OpenSkills SkillsBase is implemented using the Swazoo HTTP server running in GemStone, all hiding behind a Squid reverse proxy.

Bio: Bruce is an enthusiastic technologist and the Founder and President of OpenSkills, a global non-profit association of professionals who provide a wide range of open source related services. His strong technical leadership skills have contributed to his success on a huge diversity of IT projects, over a period of more than 20 years. He has built and deployed many Smalltalk systems and libraries over the past 10 years.

Date	May 11, 2004
Location	Suite LLC offices
Address	440 9th Avenue, 8th Floor
Time	6:30pm to 7:00pm -- Open house
Time	7:00to 8:30 pm -- OpenSkills Skillsbase Project

Directions:
Take E or C train to 34th (Penn Station) walk to corner of 34th and 8th. Walk up one block to 9th.

RSVP is requested. Please send mail to: charles@ocit.com with subject line of: NYC Smalltalk May 11th, 2004.

Yahoo points to Cincom's congratulatory message to Alan Kay.

It's been a great show - My talk went well this morning, and I received some very nice feedback - thanks to all for the great questions! It's been good to finally meet the withStyle team face to face - I look forward to seeing the lot of you in Australia, even if I have some trepidation about the vegemite you provided :) It was a great show, and I hope we have as great a time next year.

Brian Rice talks about Slate. Generally works in language research - very inspired by Self - working with Lee Salzman (not here) - designing Slate with him. Looking for flexibility and minimalism. Want to do what Squeak does, but better. Slate is free, under the MIT license. Want to use a lot of the good ideas in Smalltalk, and bring them together. Admits that the number of unique new ideas in Slate is small. Implemented first cut using Lisp. Why a new Smalltalk? Self and Strongtalk promised change, but we ended up with Java instead. The existing ST vendors have customer bases to deal with. Squeak is free and malleable, but has too many small issues - new designs can't tackle all of them. Really wanted to push together the right set of ideas in one place.

Influenced by Self and Strongtalk. Also by CLOS and Dylan. Wanted to combine best ideas from these disparate systems in one place. Slate development started in 2002. Self was not practical - big demo. Squeak was moving in too many directions, in their opinion. Slate the language is based on objects with slots, prototype based language. methods are blocks that close over their arguments, and have a syntax signature that activates them. Smalltalk is single dispatch - Slate is multi-dispatch. Slate specifically allows for object-specific behavior and state, and multi-argument dispatch. They call this combo "PMD".

All arguments are receivers and they play different roles. Objects do not relate to methods in the same way they do to their slots. methods are cooperatively held between many objects. No self/super keywords - not reserved. lookup is accomplished through messages to the context

Method lookup is performed in cooperation with the arguments - dictionary is searched depth first, left to right, methods ordered by their "distance" from the arguments. The distance is "deterministic" and the "closest" method applies. Optimization needed to be done early as a result.

Slate started with Self's inheritance model, using special slots to store delegates. Shared "traits" contain behavior, not state. This was found to be too dynamic. a pattern - does not distinguish enough. Now looking at new models - Looking more closely at what Self did with descriptors. Looking at Squeak traits for ideas.

Wanted to keep the syntax as close to Smalltalk as they could. So what's it look like?

collections 
	addPrototype: #NoDuplicatesCollection
	derivedFrom: ExtensibleCollection.

nd@(NoDuplicatesCollection traits) add: obj
[
	nd include: obj
].

So it looks like Smalltalk, but oriented in a prototype based direction. Macro-methods - syntax parse trees are an object medium for communication. can annotate these with type info or declarations, or describe a pattern that the compiler van recognize and optimize on. There are tools being built for this.

Summary - this is very early development work - the VM has only just been done - it's a work in progress. Plan is to go VM-less and bootstrap.

Smalltalk evolution panel at StS 2004:

Members: Lars Bak, Martin McClure, Vassili Bykov, neil Konz

Vassili: Evolution happens. Works on tools, not the "language part" of the system. Still, gets to be in that area quite frequently with what he does. Pretty much, given the way Smalltalk works, we all end up playing in this area.

Neil: Agree that evolution happens. Especially in Squeak, it moves in a lot of areas at the same time. A surprising number of Squeakers are playing the language design/evolution area all the time. Evolution in how it's being used. While Alan Kay had the initial vision, he's not pushing from that end. He's funding/pushing his own projects - he looks at is as infrastructure. Some are evolving to make it smaller (Squat), make it a Web Services system, Seaside, graphical experiments (Croquet)... No one is selling it - has pros and cons. Good: No one to kill it, can only die through lack of interest. Con: It's a "spare time" thing, people will only work on things of interest to them. Smalltalk has a bright future for server side work and scripting - other scripting things aren't as good

Martin: Smalltalk needs to get better - contradictions:

• Size
• Smalltalk should get larger (Gemstone - bigger repositories, etc)
• Smalltalk should get smaller (embedded systems - like Lars)
• More Innovation, but also more interoperability between dialects. Should be more discussion between implementors on what is happening and what should happen. Too many times we've had slightly incompatible similar ideas.
• More free Smalltalks - commercial Smalltalks need the ideas

Lars: I'm not a language designer - what will get it more accepted? Better support for Scripting - need to be able to use Smalltalk from "standard" file based tools. The other scripting languages (no names :) ) are pretty much all bad. Focus on what Smalltalk is good at - need to quantify it better. Talk about features, not "religion". Should have a Scripting Smalltalk

Q: Eliot "hijacks" session. Smalltalk community is simply that "we're better" - no uptake, turns people off. Need to explain what actual problem we are trying to solve. Want to sell aspirin, not vitamins.... Draws us a picture of where Smalltalk ought to grow. Off into a business model thing....

Lars: Find a niche where you are better than the competition and try to grow there. Don't fight the same battles - find new markets.

Alan Knight: Push simplicity - point out how easy it is to get started. Point out how quickly you can get into the system and start accomplishing things (closer than where step 1 is "create the XML manifest file"

Bob Nemec: We are techies, not marketers. Have the STIC step up more - get the word out.

Neil: Have to reach the decision makers - not just the tech guys.

Me: Get involved - Get a blog, get the message out there.

Sam Shuster: Get better pages to show up for Smalltalk searches on Google

Vassili: How to carry the message - make sure that the message is positive, not snarky or put down -

Dennis Smith: Marketing - there is stuff we can do. Starting with VWNC is not as simple as it could be (ed. - the New Class dialog helps). Generally, the ramp into the product is harder than it needs to be. Say I wanted to introduce Smalltalk to high schools - what can we point to as help?

Martin McClure: Squeakland.org and EToys. This is solved somewhat in Squeak.

Neil: Yes, EToys and the toys associated with it really does work for getting people into scripting - can and is being used to draw people into Croquet. "People don't buy languages - they buy solutions to problems". Got into ST by looking for something like ControlWorks

Bruce Badger: talk to Linux groups, introduce things like Squeak and VWNC to people, show them what you can accomplish with these tools. Show the open source one, show the commercial one - crowd was very pleased

Rich Demers: Wanted a panel on what should be done to evolve Smalltalk, not a marketing discussion. Lots of things have stayed the same since Smalltalk-80 - should we look at new things for Smalltalk? Look to other languages for ideas? Need some forum for talking about these sorts of things - some organizational thing through the STIC?

Alan Knight: STIC is not a faceless thing - it's a known group of people who are quite busy, and spend most of their time organizing this show. After this show we may actually have some money and be able to do some things - but we need help. "Ask not what STIC can do for you".

Martin McClure: Evolving is done in order to survive better. Need to get the word out in order to be able to evolve.

Bob Nemec: There is a large open source community around other things (Linux). Perhaps we should come up with a "common Smalltalk" effort.

Alan Knight: Not true that all the work is in Squeak - Ralph Johnson's Camp Smalltalk effort has worked very well. Lots of open source work in VW as well.

Sam Shuster: Dialect portability - used to do SUnit ports across ST dialects. For a long time was concerned - at this point: "Who cares?" Bob: Risk management

Martin Kobetic: Too short a time to get things done, nothing gets done between the sessions. "What is Smalltalk?" Squeak? VW? There are efforts (like GLORP), but it's fragmented.

Hunter: used to do Smalltalk back in the 80's - now doing financial services, came here because "it's time to do Smalltalk" - web services make it easier, "no one cares if the server is Smalltalk". Offering a clean object platform that can deal with standards based communications are possible. Only obstacle - getting the examples to work are harder than they need to be.

Lars Bak's keynote address on embedded work in Smalltalk. Lars was involved with Strongtalk - Animorphic, was also involved with HotSpot at Sun - now this

How to make embedded systems "servicable" - i.e., how do you update the thing in the field w/o having to recall it? Example - visiting a VC, met an exec with a big car, digital display - "BSOD" on the screen, had to "reboot" the car - the vendor's answer was basically "yeah, so?". With phone users, you can't get updates as you do with desktop clients - phone users will just switch phones. Need a better way to keep these users.

Past VM experience:

• 1986 Beta - 1990 Self
• 1996 Java HotSpot - 1993 StrongTalk
• 2000 CLDC HotSpot - 2002 Resilient

Wanted to sell StringTalk to Wall Street - but the Wall street folks were thinking "Java" thoughts. Went on to Java HotSpot. Now working on Resilient. So the agenda:

• Resilient in embedded systems
• A variant of the ST language - some additional syntax, will explain
• Implementing OS services
• Product licensing

This is a technology preview at the moment. VC backed company. getting second round of funding, so they are moving forward. Today, most of the embedded systems are pathetic - they use C linked to an RTOS kernel. Very slow to build and debug. In this space, short turn-around times are critical - with some electronic toys, times are measured in weeks. Updates are either not possible or monolithic firmware updates (reboot). Typically using unsfae languages, no servicability, very static model. Support is "reboot it and try again". Customers don't like that idea.

Predictions for this space?

• Software quantity doubling annually
• By 2007 it will be impossible to buy a non wireless device
• Device R&D is dominated by software development. True even in "old line" industries like auto

What does inductry want?

• Increased reliability
• Low cost (resource constraints)
• recalling a device (like a phone) can run to $50 per device)
• Dynamic updates in the field
• Real time capabilities
• Rapid development cycles

Is embedded Java the answer? - No

• Does not support incremental execution
• VM spec is very complicated
• Bytecodes not designed for speed and compactness
• Configurations for embedded systems are too big
• CLDC and CDC
• Configurations are growing...
• Resilient is targeting down to 128k size chipsets

What can we do better?

• Dynamic language
• Increased productivity
• Connect dev env to the running system
• On the fly updates

Example - Bang and Olufsen tested Resilient to service and control a digital speaker. Able to do field updates w/o recall to the shop. Customers don't like having to do manual turn-around. Transparent updates possible (as is done with ReplayTV and TiVO devices) - have it updated w/o user having to deal with it.

• Platform for crearing secure, OO real-time software
• Minimal memory
• increased productivity
• Enables correction in the field - with deployed software

Examples - take a snapshot of field system and send back to engineering for analysis. use SMS for pushing updates. Two pieces:

• Embedded Platform
• OO OS - 32K
• Pure OO System
• Platform independent mobile code
• Libs for device drivers, networking
• Unified resource mgmt - everything is in one heap.
• IDE
• Connectes to running system
• Supports true incremental execution
• Full servicability and visibility - can change device drivers as it runs

This stuff can be deployed on small hardware (With Bang and Olufson, they had 256K - so they tossed in a web server so that they could look at the results). Cell phones are another platform - especially the ones not running an OS - can add in this system pretty easily. You can use this on a host OS (desktop) for development purposes. The development environment provides the reflective behavior, reflective ifc in the device - allowing for changes to all subsystems in the device. They have customized Eclipse for Resilient. They have also done this for Smalltalk/X, but did not like the environment. Programming support for debugging, profiling, introspection in the plugin... They built the Eclipse support using the Eclipse plugin support.

The VM is portable and simple. 32 bit VM, compact object model, scalable object heap. new bytecode set for Smalltalk. 20 bytecodes with uniform format. Optimized interpreter, inline caching.

• Unified Automatic resource management

• real time GC
• policy based, user definable
• guaranteed allocation/scheduling behavior per thread/application

Smalltalk with a few twists - trying to make a simple system

• Introduced full syntax for classes
• Allows for File based storage
• Atomic test and store statement
• Namespaces
• Typed LIFO blocks
• Removed
• Pool variables (not useful)
• Class instance variables

Shows us the file format for code - looks pretty simple, only a few nits from the crowd on assignment of stuff. method def:

key	=	(^key)

Critique - use something other than "=" for defining a method. Now, blocks in this system are not full objects, so when using them you have to declare them. Minor restriction. The main thing is, it looks like Smalltalk. The changes are all related to issues surrounding actual issues in this field:

• Device constraints (memory, etc)
• Developer expectations in this field (file storage, using tools like CVS)

Class libraries - minmal set of libraries provided. No reflective behavior - only the programming environment can create a class. #perform: is not supported - makes it easier to determine what needs to be downloaded to the device. Scheduler and device drivers are supported, as are standard network libs (TCP/IP, SLIP, NIC, Firmware). Small collection hierarchy. Shape changes are supported. Example:

• Two kinds of integers
• SmallInteger (20 bits)
• LargeInteger (32 bits)
• Writing device drivers on a 32 bit computer requires 32 bit arithmetic.

Namespaces - Able to modularize code. Classes can contain other classes, which is how namespaces are implemented here. Accessing:

Network::Service::Echo install

Performance - issues

• Allocation of block contexts
• inlining of control structures
• flattening of code (Collections)
• Interpretation overhead
• Slow method invocation (only 32K available here)
• results in breaking down code abstractions
• or apply advanced inlining compiler

Block example - Typed LIFO blocks. Stack allocated contexts require no escape guarantee. LIFO block ikmplementation speedd up block code.

collect: [collect] do: [block] = (self do: [:e | block value: (collect value: e) ].

Sharing methods - 10% of methods can be eliminated by doing this (sharing byte codes). "Super byte codes" - computed based on static bytecode pair histograms. With space for 255 byte codes, and only 20 in the system, can create "app level" byte codes on the fly doing runtime analysis.

The Scheduler is written in Smalltalk - so that's field servicable as well. Very cool. The device driver API is simple, mimics the raw hardware. VM provides an abstraction layer. The resilient VM is 2X faster than the JVM for these devices! Supports:

• Bunch of devices - see the site (below)
• IA32/Linux
• StrongARM/Embedded Linux
• Windows
• Symbian OS
• Mac OSX

tech preview available at http://www.oovm.com. Free for NC, pay for commercial. OOVM is actively looking for initial projects, and will make it attractive for prospects.

And a demo - plugging in his phone to his PC, and connecting to it. Synching dev env classes with the device. Developer gets notified of what's there and what's not. And he's executing code on the device. There is exception handling, very simple, but follows the Smalltalk model, using a Java-like API (throw, try, catch). And there's a Wiki here

Mark Roberts and Rich Demers talk about SmalltalkDoc. Mark started with ST back in the late 70's at PARC. Rich started with VAST back in the 80's. What is SmalltalDoc?

• Standards and Facilities to provide reference documentation for Smalltalk
• Authoring tool in the IDE
• Web Application for browsing

The goal is to separate the documentation from the implementation of the system - allow people to learn w/o reading all the code. The documentation can be gathered from a Store repository by the application. Who is the intended audience?

• primarily new developers
• reach out via the internet
• not a substitute for PDF - an addition to online help

Why Smalltalk Doc?

• Reduce the time/effort to learn ST - get them up to speed quickly
• Provide a simple overview of the environment and lower the learning curve to a learning bump
• Improve the "out of the box" experience for developers new to ST. Motivations:

• Need reference doc - we used to have the "Cookbook" in 2.5, but it was huge, and never updated. The ObjectReference was a stab at doing this
• Emphasis on use of the class library
• "Learnability" vs. "Simplicity"
• Learning the class and pkg library
• Need to clarify the functionality of the system
• One of the big issues is the API - what is it? In many cases, our libraries have no API in the sense that developers in other languages define the term. It's a manual "eyeball" process of inferring the API...
• Making the system more approachable is a key goal

The general issue - we have a gap in knowledge - we doc the system, but do not have a "Users Guide" for new people. Using this:

• Authoring content in the IDE
• Generating content for the web
• Browsing content for the web

Now Mark is going to demo the system. The system is built on a content mgmt system built atop an OODBMS. Presented via a VW web toolkit application. What he's got is a prototype that can produce a doc view of the class library - from the package and class view. Now on to Rich. Hmm. UML diagrams of the domain. I know these are useful, but w/o a camera, I can't convey what I'm looking at here....

They have a browser-like tool for displaying and editing content. Basically, the same information that was available on the web side is available in the browser view. The bottom view is an HTML Pane (Twoflower now - WithStyle eventually? Content entry is text. Interesting flare up of conversation on the concept of entering content - current prototype requires HTML tags - why not Wiki markup? Too much work - they want a WYSIWYG kind of tool in the end. The content will be stored as XML.

Q: How does this information get entered in the first place?
A:: Information gathered automatically (garnered from the Smalltalk system), converted into an XML form, and then translated for display. The idea is to keep all this info with the code so that it gets versioned off in Store.

Q: Does this work at all with the Web Services work?
A:: Huh?

Q: What about using something like the JavaDoc approach?
A: The desire is to integrate this with the system. Should be possible to create a tool to "peel" the doc off from the system. The domain model is tied into the code, so it stays with it. The idea is to keep it that way.

Q: Will there be an interface for end users to "mark up" the documentation?
A: The web side? Sure, that could be added via permissions. The tools themselves will be available for end customer use