Learning Smalltalk?
If you are interested in learning Smalltalk, this post may be of interest - it links to this article by Wilf Lalonde - which introduces Smalltalk based on a presumed knowledge of Java and/or C++. Looks pretty good.
If you are interested in learning Smalltalk, this post may be of interest - it links to this article by Wilf Lalonde - which introduces Smalltalk based on a presumed knowledge of Java and/or C++. Looks pretty good.
I just picked up the Evanescense album Fallen. It's quite good; not exactly what I had expected after hearing the song "My Immortal" on the radio. It has a harder edge to it, and a surprising take on the popular song. The 4th track is "My Immortal" - but it's an acoustic rendition. Much softer, much slower - no big uptempo at the mid point of the song, just the same basic sound on a piano. The funny thing is, the pop track is on the CD, the 12th track - but the liner notes don't mention a 12th track. Interesting. I'm still not sure which rendition I like better. One thing to note though - "My Immortal" is not a happy song. I guess I hadn't paid that much attention to the lyrics before, but I have now. It's a very haunting track, and the acoustic version makes that very obvious.
I introduced a nasty bug in the dev stream of BottomFeeder the other day - it's been fixed. Here's a method I had for caching GUIDs from items that we've already seen:
oldItems: aCollection ^self moduleDictionary at: 'oldItems' put: [aCollection]The problem ought to be obvious, but it was a simple typo on my part - I was thinking of #at:ifAbsent: (which takes a block). Now, I suppose the static typing advocates will rush out at this point and tell me "if you had type checking..." maybe. On the other hand, testing is what solved the problem for me. Simple mistake, simple fix - it just wasn't clear what I had done to myself before I did some real testing. Note to self - more tests
The last three days have sported some pretty odd (for Maryland in August, that is) weather. Highs in the 70s, with low humidity. It's like late September weather - or the kind of weather I'd sometimes see in the summer in NY after a strong set of thunderstorms. It's a nice break from the typical August heat and humidity though - I'm enjoying it while I can. I'll be out grilling steaks in a couple of hours, and entertaining family, so blogging will be light. Back to the grind on Monday.
Dan O'Brien has an outsider's take on Camp Smalltalk. Makes me wish I'd had time to go, but I was in Australia then...
Scoble points to this fascinating little story on how malware and spyware gets onto unprotected systems. It's a fascinating story, and explains why you really want to be careful out there...
If you grab the dev updates for BottomFeeder, you may have noticed a few odd things over the last few days. First off, you should be aware that the dev stream updates are not guaranteed to be stable; I put them out as much for feedback as for anything else. In any event, I've been mucking around with the code that determines which items are new/old over the last few days, so you may have seen a bunch of old items listed as new. The good news is, I've got the issues sorted out now, and the size of the cache (old item cache) for a feed is no longer related to the code that identifies new/old items. So you shouldn't have to keep large cache sizes simply because a feed has lots of items in it. On the other hand, it's still dev code; be aware that changes are still likely to happen.
So I spent the last two days (well, part of them) at a game convention north of Baltimore. Huge thing - more board games and board gamers than I've ever seen in one place (including Gencon). I was able to take a second place in Puerto Rico last night, and a first today - I would have been in the semi-finals (right now, actually)...) - but we have relatives coming into town, and I have to prepare. Took my daughter, who came in a respectable third (only 4 points back) in her PR game this morning. We'll both go to a similar Con in November if it works out with her school schedule. Fun stuff - there's a ton of variety in board games these days. If you still think of only Monopoly and Risk when you think of board games, you should have a look here
Keith Ray has some interesting thoughts on whether software is "engineering" in the commonly understood meaning of the word. Check it out.
This is cool - A Canadian group is vying for the X-Prize. Maybe now that various private sector outfits are trying to get "out there", we'll see some actual progress on space exploration.
Whistle boy wants us to look at IBM's problems in the application server space. Hmm. Perhaps that 10,000 seat swap-over of Solaris to Linux at Lockheed should be engaging more of his thinking. When you work for a dead company walking, I guess all you can do is Whistle past the Graveyard. I guess this is just Schwart'z way of saying "pay no attention to what's behind the curtain". Specifically, he doesn't want anyone to remember that Sun is only in the black due to Bill Gates' charity....
The next release should see a lot better HTML rendering - I'm going to work with Michael to get part of WithStyle integrated. That will replace the Twoflower HTML widget, and give us the ability to render CSS properly - browsing inside bf will be a lot more pleasant. This move will also mean moving to a cleaner version of my Http package - Michael built a much cleaner implementation of my library last year, and using that will make the internal API of bf (and the blog poster) a whole lot simpler. This migration will take a bit of work - but it should mean a better tool on the far side.
I was really looking forward to this series - I like SG-1 a lot, and was hoping this show would pan out. At the same time, I know that most spinoffs suck eggs. I have been pleasantly surprised by the show so far. The cast seems to have gelled - I like the fact that they aren't just clones of the SG-1 cast in a different place. The personalities are different, and the dynamic is different. It's a good mix, and so far it's worked. This show looks like it will fill that SciFi gap I've been feeling. Certainly "Enterprise" isn't going to do that - not unless someone books Berman a one-way ticket to Elbonia....
If you are looking for Smalltalk work, call KSC. They are hiring for a number of positions.
Everyone and his brother has commented on this essay by Paul Graham. Most of the commentary has been positive; Eric Sink is one of the few who's had a contrary opinion. I've been looking at the essay, and I have to say that I've got a few problems with his essay myself. Let's have a look at his notion of why you want hackers (as he descibes them, top notch developers):
It's pretty easy to say what kinds of problems are not interesting: those where instead of solving a few big, clear, problems, you have to solve a lot of nasty little ones. One of the worst kinds of projects is writing an interface to a piece of software that's full of bugs. Another is when you have to customize something for an individual client's complex and ill-defined needs. To hackers these kinds of projects are the death of a thousand cuts.
Ok, let me be extremely clear here - he's full of crap on this. What he's saying is that problems that actual users care about are uninteresting. This doesn't really jive with his assertions that startups are a great place for hackers. Why not? The best startups (you know, the ones that succeed) - pay attention to their early clientele. In fact, they often build stuff more or less exactly to the specifications of their early clientele. The minute you stop fulfilling end user needs is the minute you stop making money.
Now, Graham's assertion is that you can "protect" your great hackers by having them build "tools". That sounds nice - until you ask: "Who are these tools for"? Well, they are going to be for some set of users (Internal or external). If your hackers aren't paying attention to the users, then they are going to end up building a bunch of over-architected crap that no one wants or needs. Trust me on that last point - I was at ParcPlace, and got exposed to plenty of "hackers". We had some really brilliant people back when I joined ParcPlace in 1993 - and the ones who Graham would call "hackers" were typically the least useful developers. They would wander off and build things they thought were highly interesting - and that no one else wanted.
I recall one of our hackers touting some great browser extensions he had in 1994. I publically ripped him a new backside - because he had done all the work on the legacy browser, not the new one that was coming out for VW 2.5 (in the then new GUI toolkit). This would be the equivalent of one of our (Cincom's) engineers proudly touting some additions to the GUI builder (current) after Pollock had shipped. Cool? Maybe. Also completely useless.
That's the trouble with Graham's idea of a hacker. He elevates the sort of developer that lives off in the clouds, building their own idea of perfection without regard to what anyone else might need. You know what? I don't need that kind of guy on my team - Graham can keep him. I want the kind of people we have on the Cincom Smalltalk team now - extremely bright, highly motivated developers - who listen and respond to customers. Are they perfect? Heck no, no more than I'm a perfect Product Manager. We know who pays the bills though. I'm not sure Graham gets that part.
Here's exactly where he gets it wrong:
The distinguishing feature of nasty little problems is that you don't learn anything from them. Writing a compiler is interesting because it teaches you what a compiler is. But writing an interface to a buggy piece of software doesn't teach you anything, because the bugs are random. So it's not just fastidiousness that makes good hackers avoid nasty little problems. It's more a question of self-preservation. Working on nasty little problems makes you stupid. Good hackers avoid it for the same reason models avoid cheeseburgers.
Bull. I'd actually say it's almost completely the other way - if you go in and fix the nasty, stupid UI bugs you learn something about what your users (you know, the people who pay your salary) want. You learn the difference between adequate work that people accept and great work that makes people happy. Look at the difference between the VW tools in VW 5i.2 and every release since then, for instance - the "polish" that's been added (mostly by Vassili) has been more important in many respects than the added functionality. Appearance matters - a nice UI differs from a bad one in the same way that a person with a shower differs from the one without - while a shower doesn't make you any smarter, it certainly makes you easier to be around. Save me from developers who don't want anything to do with the user community. I'll happily load down any of my competitors with them.
Infoworld points out the obvious - handhelds are a niche market. The problem is simple - these devices are neither fish nor fowl, and people can already use their cell phones for all the things a handheld promises. Once you've covered address book and email, you've covered most of what people want to do with these devices. There's a similar issue with tablets, IMHO. Now, if the hardware cost of tablets equalizes down to the level of a standard notebook, tablets may become ubiquitous... but it won't be because people are actually looking for a Tablet. It'll be more along the lines of "oh, it does that too? Cool".
Loudthinking points out a possible problem for MS - Longhorn is looking like more of a problem than a solution to some people. The early adopters are already moving - for all the noise about tablets, take a look around at the next trade show you attend - it's likely that you'll see more mac notebooks than you might expect. I've said before that the issue Longhorn will face is not the actual cost of migration - it's the perceived cost of migration. if the meme gets around that "it's not worth the trouble", then MS is going to have a problem on its hands.
Travis notes that VisualWorks on OS X has some problems. We recognize this, and are working on addressing the problems. The stability issues should be fixed in 7.3 - we have a solution in mind, and the VM team is working to implement it. We understand that this has been a great source of frustration for Mac users, and we apologize for the difficulties.
I understand what the feds are trying to do by insisting that net based phone calls be traceable - they are trying to keep up with shifting technology. The fact of the matter is that they are grasping at dust. It's not as if VOIP is my only option for net communication. I can use various IM systems, I can use IRC. I can create my own chat system easily enough as well; there was an Opentalk demo of a peer to peer chat system 4 years ago, slapped together in a few hours by one of our tech sales people. It's simply too easy to establish a communications channel on the net. The feds are going to have to accept reality, and realize this....
Apparently, it's not just Linux and software that have problems with patent law. medical research is hitting patent walls as well:
More and more diseases are being linked to genes, but making tests for the afflictions runs the risk of violating a gene patent. Researchers currently count on good will, but new laws may be needed.
Interesting
Some of the people commenting on this post (in email as well as actual comments) were skeptical - "who are they going to sue", was the common refrain. What they forget is that perception is reality in these cases. Witness Munich's backing off of linux, for instance. Now, for all I know they've run into user pushback and are using this as an excuse. This is what they are saying though:
As previously mentioned, there is a rising concern that software patents could stifle development of open source worldwide. FFII has complete coverage of what is going on in Europe." (FFII stands for Foundation for a Free Information Infrastructure.) Reader jmt(tm) writes "The call for bids was supposed to be published in late July, but the Munich Green Party had pointed out about 50 possible patent conflicts which the city wants to evaluate before moving on."
The actual threat is far less relevant than the perceived threat in cases like this...
Apparently, Schwartz's last missive fueled a bunch of speculation that Sun might acquire Novell (talk about the walking dead buying the shambling dead is always interesting, I guess). In any event, it managed to move Novell's share price - see the Business Week article. Dare Obsanjo also noticed the post, and had this to say about Sun (amongst other things - read his whole post):
It is definitely amusing to see Sun scramble to stay relevant as they realize that their hard ware is overpriced and they can't figure out how to make money from Java's popularity. If not for the billions they have stashed this would definitely be a company in its death throes.
I have another thought - Schwartz wasn't that widely criticized for this post (which some might interpret as a passably successful attempt at stock manipulation). What would the press and blogosphere reaction be if Ballmer or Gates made similar comments, I wonder?
Not only is MS entering the blog server space, they are starting in Japan - I guess that means that they'll get the i18n stuff down early. Spotted in Phil Ringnalda's blog
Over the last few releases, we have shipped a separate, localized to Japan version of VW - no extra charge to customers, but fully localized. The 7.2.1 version will be ready in about 2 weeks or so. Things will change with 7.3 - we will have all the message catalogs for the product shipping - and we spent the 7.1 and 7.2 releases ensuring that strings were replaces with UserMessages. So starting with 7.3 (in the fall), there will be no separate version for Japan. Instead, it will be part of the core product.
The other day, Ralph asked me about the upgrade tool in BottomFeeder. Well, until this evening it had mostly been a component piece of Bf, not easily reusable elsewhere. I think I've fixed that. I just spent some time refactoring the tool and splitting it out of the bf bundle (which makes it entirely possible that the upgrade tool will be used to upgrade itself sometime. Such is Smalltalk :) ). The code is in the public store as PatchFileDelivery.
One thing you'll notice is the existence of PatchManager and PatchManagerUI, which I don't really use. That's an artifact of the way I used to deliver bf updates. The more current classes of interest are UpgradeManager and UpgradeManagerUI. Here's how I use them:
First, I set up an XML Manifest file on the server. I use the XML Configuration Files package in the public store for that:
defs := OrderedCollection new.
list := #('dev\Emote-Support.pcl' 'dev\ExtraEmphases.pcl' 'dev\VRCommonDialogs.pcl' 'dev\Http-Access.pcl' 'dev\PatchFileDelivery.pcl' 'dev\Browsing-Assist.pcl' 'dev\OSTimeZone.pcl' 'dev\XmlRpcClient.pcl' 'dev\XML-Configuration-Files.pcl' 'dev\BottomFeeder.pcl' 'dev\TwoflowerBundle.pcl' 'IRC-BottomFeeder-Plugin.pcl' 'Pongo.pcl' 'Blog-Tools.pcl' 'WinMineGame.pcl').
names := #('Base Component, Icon Support' 'Base Component, Font Support' 'Base Component, Dialog Support' 'Base Component, Http Support' 'Upgrade Tools Support' 'Base Component, Browser Support' 'Base Component, Local Time Support' 'Base Component, XML-RPC Support' 'Base Component, Upgrade System Support' 'Base Component, Main Application' 'Base Component, HTML Browsing Support' 'Plugin, IRC Client' 'Plugin, MSN IM Client' 'Plugin, Blog Posting Tool' 'Plugin, Minesweeper Game' ).
descripts := #('' '' '' 'encoding priority fix' 'Refactored Patch File Code' '' '' '' '' 'remote browsing includes top 5 items' 'encoding changes' 'Fix for settings reading problem' '' 'preview load could fail, fixed' '').
sizes := list collect: [:each | each asFilename fileSize].
allows := #(true true true true true true true true true true true true true true true ).
list do: [:each | | version nm timestamp properties index |
properties := [CodeReader new readInfoFromFileNamed: each]
on: OsError, CodeReader fileFormatSignal
do: [:ex | ex return: Dictionary new].
version := properties at: #version.
nm := properties at: #parcel.
timestamp := properties at: #timestamp.
index := list indexOf: each.
comp := ComponentDefinition
parcelName: nm
parcelFilename: (each asFilename tail asString)
version: version
releaseDate: timestamp
descriptiveName: (names at: index).
comp description: (descripts at: index).
comp fileSize: (sizes at: index).
comp allowDynamicLoad: (allows at: index).
defs add: comp].
(defs at: 12) isPlugin: true.
(defs at: 13) isPlugin: true.
(defs at: 14) isPlugin: true.
defs last isPlugin: true.
"now save it" file := Tools.XMLConfigFileSupport.XMLConfigFile filename: 'upgradeBtf.xml'. file saveObject: defs. file saveConfiguration.
That saves a configuratioin file to disk - the plugins/main components thing is Bf specific, but it's not really essential to the package. To open the UI and check for upgrades, this is all you need to do:
loader := Patch.UpgradeManagerUI new. loader viewer: self. Cursor wait showWhile: [loader doUpgradeCheck]. loader open
Of course, to specify where the upgrade information lives, you need a settings file that looks like this:
[Settings] patchSiteUrl='http://localhost/patches/' patchSiteFilename='patches.xml' patchDir='patches' saveDir='app' upgradeURL='http://localhost/upgrades/' upgradeFilename='upgrades.xml' version='1.0' isOnline=true
By default, the code will look for a file called 'patches.ini'. You can also hand the manager object (the domain underneath the UI) settings in code; there's an API for that. That's pretty much it; Assuming that you have Http access to the remote server, you now have patch file delivery.
Sam Gentile points out one of the issues when dealing with Windows CE and the .NET compact framework:
There are a whole lot of things different about programming for mobile devices with the CF versus the desktop framework.
Of course, if you use Cincom Smalltalk for Windows CE, you merely need to worry about the form factor (i.e., the screen layout) and the transient nature of connectivity - There are no differences between Smalltalk for any other platform and Smalltalk for CE. Binary portability means binary portability....
In support situations, one thing that tech support likes to get is a reproducible error - it's hard to diagnose a problem that can only be vaguely defined. It can get even harder if the problem only crops up under a set of circumstances that are fairly unique to a specific installation. Enter the Smaltalk image - here's a message I got from a customer:
Yesterday, we were having a subtle CORBA issue.
The problem occurred when processing CORBA events from a device in our lab ( an Alcatel 5620 Network Management device in case you are interested).
The developers were able to step through the code in our lab environment with all the devices we typically connect to in play, and at the point of failure, save the image.
They then sent the image to CINCOM for further analysis.
At CINCOM, they brought up the image, and continued the investigation (from precisely the point of failure), identified the problem, and between the two of us, a fix was determined.
The fix was then applied to our dev environment, and we were back in business.
Less than 24 hours start-to-finish.
I contrast this with Java, where we have previously spent many weeks trying to come up with a 'reproduction scenario' that the Java vendor could then use to debug the problem outside our labs!
When in doubt, send the image - that way, the support guys can see the actual problem in the actual running environment. That's one of the values of having an image.
For the last few years, we've spent a few weeks each summer paving something - a patio, walkways, or - last year - digging up the patio to lay pipe. We bought more brick this summer, in order to lay down even more walkways (soon I won't have any grass to cut - just weeds to burn between bricks). However, the bricking project was placed on hold the wife decided that we needed to paint the kitchen. Billions of little paint chips later, we had two colors picked out. No simple monochrome job for my wife - two tone with a wallpaper border.
The taping alone took a day (have you ever looked at your kitchen and considered the pre-paint taping job? Makes me wish I had forked over the money for a paint job by the builder). Now it's mostly done - the border still has to go up, but the painting itself is all done. Then there's the cleanup, and bringing back in all the stuff we moved out. Paving stones might actually be less work...
Ryan Lowe played a round of Extreme Golf last weekend. Can't say that I've had to look in a tree for a club before :)
Here's the real risk that Linux faces - patent law. Companies like IBM, Sun, and Microsoft have been filing software patents pretty aggressively for years - it's not inconceivable to consider the possibility of MS deciding to make a patent claim (of course, who they would make such a claim against is an interesting problem all by itself). Take a look at this:
'Linux potentially infringes 283 patents, including 27 held by Microsoft but none that have been validated by court judgments, according to a group that sells insurance to protect those using or selling Linux against intellectual-property litigation.' Dan Ravicher, founder and executive director of the Public Patent Foundation, conducted the analysis for Open Source Risk Management. OSRM is like an insurance company, selling legal protection against Linux copyright-infringement claims. It plans to expand the program to patent protections."
Patent use as a business weapon is nothing new - I wouldn't be surprised to see this sort of thing at all.
Aaron Brady is impressed by Squeak Smalltalk, but asks: "Apart from legacy, why do people still use Smalltalk"? Well, that clearly gets into advocacy - have a look at dynamic updating updating in BottomFeeder - end users can load updates without having to restart. I do the same thing for this blog server. Dynamic typing makes the language much easier to develop in (similar to Python in this regard). The Smalltalk image is implemented in itself, which makes it much, much easier to develop tools in Smalltalk - developers commonly extend their own environments. Why use Smalltalk? Probably the best answers can be gleaned by reading the blogs here and see what the community itself has to say.
Jonathan Schwartz is a wonder. Here he is, one of the head honchos at "Red Ink 'r Us", and he's telling us that IBM is in trouble. Hmm. From IBM's latest earnings report:
ARMONK, N.Y., July 15, 2004 . . . IBM today announced second-quarter 2004 diluted earnings per common share of $1.16 from continuing operations compared with diluted earnings of $.98 per share in the same period of 2003, an increase of 18 percent. Second-quarter income from continuing operations was $2.0 billion compared with $1.7 billion a year ago, an increase of 15 percent. Revenues from continuing operations for the second quarter were $23.2 billion, up 7 percent compared with the second quarter of 2003 revenues of $21.6 billion.
And Sun's latest report?
Sun Microsystems this week reported a profit of $US795 million or $US0.24 per share in the fourth quarter, compared with a loss of $US1.039 billion or $US0.32 per share in the same quarter of last year. Total revenue for the quarter, which ended June 30, was $US3.11 billion, up 4.3 percent from the year-earlier quarter, Sun said in a statement. Sun's profits were buoyed by the nearly $US2 billion it received as part of its legal settlement with Microsoft earlier in the quarter. Discounting the Microsoft money, Sun reported a net loss of $169 million or $0.05 per share.
That's right - had MS decided not to create another charity case, Sun would have had yet another consecutive red quarter. With that as a premise, let's see what brilliance Schwartz is brimming with today:
A few years back, IBM and HP both hopped onto the social movement called linux. It's a wonderful movement. But the bad news for IBM is that the vast majority of enterprise datacenter deployments are now occurring on Red Hat's linux. 100 to 1, depending up on where you look. And with Red Hat increasing price, while adding in an application server that competes with WebSphere, IBM's finding itself in the uncomfortable position of having lost control of the social movement they were hoping to monetize. They're beginning to look like the IBM of Mr. Akers's era - having missed the forest for a tree, and finding themselves without an operating system.
IBM has been among the most aggressive (and ironic) in positioning itself against the world of "proprietary" technology - in stark contrast to its history as the world's most pernicious patent litigator. It's against that backdrop that IBM brags about its "thousands of programmers working on linux." But ISV's can't build their business on a social movement - they have to pick a base software distribution and web service stack. And with most enterprises having picked Red Hat on IBM's recommendation, IBM now clumsily realizes it's invited the fox into the hen house. With Red Hat running on the majority of IBM's proprietary hardware, Red Hat can now direct those customers to HP and Dell. Even Sun.
It's amazing to me that he gets paid for this level of obtuseness. Sun pretty much created the shovel operation that plows money to IBM - Java. IBM has nearly half the application server market (to Sun's just about nil) - and Schwartz wants us to believe that IBM is in deep trouble, while Sun is all set to cruise forward on the commodity rails they've set up. Dream on. Here's the gist of the delusion that Schwartz has set himself:
IBM is in a real pickle. Red Hat's dominance leaves IBM almost entirely dependent upon SuSe/Novell. Whoever owns Novell controls the OS on which IBM's future depends. Now that's an interesting thought, isn't it?
Yeah, right. Last time I looked, IBM was happy to sell you Websphere (for huge gobs of cash) on just about any platform you wanted it on. Sun is the company that desperately needs you to have a Sparc box running Solaris; IBM just doesn't care. We (the Cincom Smalltalk team) are in the same position (so far as concern, that is) - VisualWorks runs everywhere, we don't care what hardware you buy. Ditto IBM (on a much larger scale, obviously). Ironically, what's the main reason that IBM can not care about the hardware - Java. Who created the commodity space that shovels money at IBM and away from Sun? Oh, that would be... Sun.
Keep whistling past that graveyad Jonathan. At least you're entertaining the rest of us while you do it.
LtU links to a PDF of Alan Kay from the History of programming Languages. Good stuff.
I've talked quite a bit about Dynamic Updating (one of the niftier features of BottomFeeder). Bf implements updates on a package (parcel) basis - you can download updates I make available on the server, and they ca be loaded on the fly (or at startup). I've been asked a few times about making the package that does this available; it's always been available - the package PatchFileDelivery is in the public store. However, it's been fairly tightly tied to BottomFeeder. I've refactored the package this morning - it should be possible to make use of it outside Bf now - you'll need the latest version, which should have its pre-reqs properly set.