Then head over to Ted's blog. Be forewarned; some of these are real groaners :)
I've spent a few days at The Beach Club (a very nice Disney Resort) with the family and a few friends. The pool here is fantastic - here's a shot from a friend's digital camera (it's a huge pool; this doesn't do it justice):
And here's a shot we got in the Animal Kingdom - is the tiger dead or alive?
I have more pics and comments, but no time at the moment. I'll post some more tomorrow.
The Mars Rover problem from last year has been diagnosed - it was a file system error:
The problem, Denise said, was in the file system the rover used. In DOS, a directory structure is actually stored as a file. As that directory tree grows, the directory file grows, as well. The Achilles' heel, Denise said, was that deleting files from the directory tree does not reduce the size of the directory file. Instead, deleted files are represented within the directory by special characters, which tell the OS that the files can be replaced with new data.
Nu Cardboard makes a wish for new methods in one of the core Java classes:
If I could add one thing to Java, it would be to add first() and last() methods to the List interface. I know it's not going to happen, for all kinds of good backward compatibility reasons, but it sure would make some of my code easier to read.
Hmm - if you have a fetish about any Java code ever written at any time (past or present) running on any given JRE, then this is a problem. Of course, under those constraints, progress is well nigh impossible. This goes past "conservative" and straight into "hidebound"...
Tim Bray has some interesting thoughts about dynamic languages:
First, we should get serious about dynamic languages. I totally don't see any reason why we shouldn't try to become a world leader in this space. They are the only thing on the horizon that's going to steal mindshare from Java in the enterprise IT ecosystem, and geeks love 'em so we should lead not follow.
Hmm - here's a thought Tim - you can become leaders in this space when the JVM stops sucking as a host for dynamic languages. Since the JVM seems to be locked in a stasis chamber, that's unlikely to happen. If Tim Bray wanted to do some positive good, he could raise this as an issue inside Sun. I have full faith in Sun being stupid about this - while MS seems to actually have a clue about this stuff:
I think that the threat from IronPython is much worse than the Bill describes. Not only does IronPython have the potential to make scripting on the JVM DOA, it also has the power to destroy Python as we know it. Jim Huginin is going to work full time to improve dynamic language support on the CLR. What happens if Bill is right and IronPython is the upgrade path for VB.NET and ASP.NET? Microsoft will start throwing large amounts of resources at IronPython. I find it hard to believe that the Python community will be able to keep up with Microsoft if they choose to do that. If Sun "gets behind Jython", you can expect a similar activity to emerge around Jython. Even worse would be for Jython development to be taken over by the JCP, all need to be compatible with CPython eliminated. Now you have two new dialects of Python, diverging from C Python and almost certainly in incompatible directions.
Watch MS make whatever changes are necessary to the CLR to make Python work well, while Sun leaves the JVM in the stasis chamber.
This story asks the question - why do hotels charge for broadband use (which nearly every guest wants), and not for pool use (which few use, and is more expensive)? Well, the question answers itself, of course - we'll willingly pay for fast access over dialup....
Julia Lerman talks about code obfuscation tools for .NET, and makes a point I have to disagree violently with:
I *know* that obfuscation is another level of security that we can all leverage. I *know* Microsoft has made it really easy by putting this "lite" (Community Edition) version into Visual Studio.NET. So, raising my hand, yet again as a typical developer - writing custom corporate applications that are not being put out in the market place - why have I never touched it, used it, thought about it?
yeah, security via obscurity has worked so well in the software industry. Access to sources helps - both in security terms, and in transparency terms (to developers). Obfuscating code just tells future developers that you don't care and want their job to be hard. Here's the point - no code is ever going to cover all possible use cases. Allowing other developers to extend and understand is a good thing. Final classes - bad. Final methods - bad. Code obfuscators - obnoxious.
This is one item that ought to bubble down to the bottom, and fast....
I've been working on a simple ToDo list tool as a BottomFeeder plugin. I should emphasize simple. It doesn't have a tray icon, it doesn't beep or do anything special when a ToDo comes due; I may add some of that later. For the moment, it merely adds a simple UI that allows one to edit/add/delete todos, and manage them in a simple RSS file - which can be subscribed to in BottomFeeder. If it tests out ok, I'll post it up as a plugin, available through the normal update channel.
The upside is that Microsoft is now doing what was once unthinkable: trimming down a product to what users need. After two decades of bloating Windows and insisting that one size fits everyone, Microsoft is finally acknowledging that not all users require all that expensive complexity.
And that's cause for optimism, even if it's based on something that exists only on the other side of the globe. After all, if Microsoft debloated its software for them, why not for us?
De-bloated? They crippled it, they didn't lighten it. Limiting the number of open windows and disabling some networking options isn't de-bloating - heck, I bet most of the functionality is still there - it's just been routed around. Making a lighter product would take MS significant time, and this isn't it. But heck, they don't have to - they've got gullible analysts out there picking up their talking points for them...
There's a bug somewhere in the updating code for BottomFeeder - it doesn't raise its head often, but when it does, it leaves a feed empty (of items). Somehow, during the update of a feed, an exception is being improperly handled, and a feed that was in mid update is being left empty. Worse, the "Regenerate Feed" option also had a bug in it. That's been fixed in the dev update stream. Meanwhile, I have to track down the actual problem. Never a dull moment :)
Well, today marks pretty much the end of summer vacation. My daughter had orientation over at the Middle School; she got her locker and homeroom assignment. Sure, there's the weekend coming up - but the it's back to the school year.
This summer went by really fast for me - probably because of all the travel. I was in Florida for a week in June, in Australia for nearly 2 weeks in July, and then back to Florida for a week (until Tuesday). Our penultimate day at the Beach Club showed how the summer was ending - the pool went on winter hours (closing at 8 pm instead of 10). The local pool is on short hours now as well, and closing completely by Labor Day.
So now it's back to serious work - even though we don't get time off like the school kids do, the summer always feels slower. Work slows down, lots of people are away. Expectations are lower, things get pushed off. Now it's ramping back up - I leave for Germany on September 7th for the end of ESUG, and then have to get into some pretty heavy business planning. I guess it's not unlike what kids get - the Fall is "back to work" time.
Scoble talks about his reading/blogging process and gets to his link blog here:
Then a tool named "OutlookMT" takes over. It is a .NET app that watches the Blog This folder, and posts anything dropped in it.
Now, notice that's all I do. Just drag-and-drop. No editing. No commenting. No linking. OutlookMT does it all.
See, that's a problem. I read blogs precisely because I like the editing function provided by the author. If you're just throwing links at me, you aren't providing any value. This is why I unsubscribed from Scoble's link blog - it's a huge wad of links with no commentary - so there's no way for me to tell whether or not there's anything of interest to me at the other end. To a large extent, blogging is about editing - you're trying to get other people interested in something. That takes effort - it's not going to happen simply by tossing links over the wall. I understand what Scoble is trying to do here, but it's not working. There's only so much one person can do - this is why magazines (and newspapers) have writers and editors....
Mark Baker quotes Uche on web services:
But putting the misery of these experiences aside, I'm surprised at how little I've had to worry about SOAP. As it became clear to me that Web Services were becoming a menace to much of the goodness wrought by XML, I worried that I would be forced to do a lot of gritting my teeth at work while I accommodated clients' insistence on WS. This hasn't turned out to be the case. In several cases where WS "end points" have been suggested, I've been surprised at how easily my suggestions of a REST-like alternative are embraced (the fact that I could usually whip up running code in hours helped a lot).
There's a simple reason for this - Web Services are the new CORBA. Setting up an RPC system is hard to do right, without regard to the form of the technology. I hear constant nattering about how Web Services are "easier" and "better" than CORBA - but there's really only one difference: With CORBA, you had to go deal with the security/IT folks about opening a port in the firewall. With Web Services, port 80 is already open. That's it. And even that's getting hairier - there are XML routers out there that filter on specific schemas - yeah, that'll be optimal on the network. WSDL = IDL, and SOAP = IOP. It's all the same stuff. I cheerfully await the next great RPC mechanism that will be touted as easier than Web Services...
There's an interesting thread in comp.lang.smalltalk on the practice of coding inside the debugger. If you read a few messages in, you'll see that there's a complete misunderstanding of how Smalltalkers are able to work - the thought process of those advocating unit tests over everything fail to grasp one simple thing - in Smalltalk, when a unit test fails - you are able to jump directly into the debugger to see why it failed. You can then fix the problem (with all the in memory objects available) - and try the test again. That's the essence of TDD in Smalltalk. It's just too bad that developers using other languages have such sub-optimal choices....
It's official - Smalltalk Solutions 2005 will be in Orlando, Florida - June 27th to June 29th (with onsite registration open on Sunday, June 26th). We are still narrowing down the specific hotel, but the timing is set. I'll be handing out announcements at ESUG in 2 weeks - mark your calendars!
David Buck is giving some OO courses in Ottawa this fall (October). Follow the link for details.
Stephen Denbeste has an interesting reaction to the responses he gets to his posts - they've made him tired of the whole blogging game. Now, mind you, I attract a small percentage of the traffic that DenBeste does - there just aren't as many people who are fascinated by my insights into OO/Smalltalk/marketing as there are people who follow politics. Still, I have a small idea of what he's talking about. Whenever I post something that is critical of Sun and/or Java, I get a number of comments and email along the lines of "you're just bitter that Java ate Smalltalk's market". And whenever I post something critical of Microsoft, I get a similar number of "you're just a Microsoft basher" comments.
Now, maybe I'd react differently if I started getting the volume Denbeste gets... but I don't think so. In my line of work (Product Management, and before that, Sales Engineer/Consultant) you tend to get flack. The job is to go out and convince people that your product (Cincom Smalltalk, in my case) is the best thing since sliced bread, and you're going to take flack for that message. It more or less comes with the territory. Yes, the kinds of attacks that come from political posting are going to be nastier and more vituperative - but so what? To be blunt, if you can't take the heat that comes from expressing an opinion, how do you expect to convince anyone?
A question that often comes to me in email at this point is "well then, why don't you have a separate blog where you post about politics?" People who know me well know that I have fairly strong opinions in that field, and I spend a fair amount of my time exchanging email with people who do post on politics. There's a simple reason I choose not to enter that fray - I'm purposely trying to limit my public persona to Smalltalk, OO, and the technology business. If I started posting on politics, it would distract from the message I try to put out here. I suppose you could look at that as a cop-out, but it's not. It's enough work to argue over static/dynamic, live debugging, and the whole Smalltalk "image" concept without having some readers immediately discount what I say simply because they think my politics are wrong. If I'm going to have an argument in technology arena, I'd just as soon have that argument stay in the technology arena.
I hope Denbeste comes back to the blogosphere - I enjoy his writing, and I find pretty much everything he writes to be thought provoking. There's a phrase covering this situation - "don't let the a******* get you down". It's a good way to think about blogging.
Sam Griffith Jr. has a nice post up on what sets Smalltalk apart:
Having experienced the joy in programming in both the Lisp and Smalltalk worlds, it is very easy to get used to the power of being able to view, inspect, browse and change everything in the system. One of these days, I hope to see the OS's that we have begin to come close to what we had in the past with Lisp machines and Smalltalk systems. Once OS's include dynamic languages in the core and expose everything as real objects that those dynamic languages can work with in a concrete way, we will be close. The power is unbelievable and allows so much. It is very great to see the current trend of the old guard of C++ and type safety starting to really embrace dynamic systems and to admit that unit testing and test-driven development really are just as stable in reality and have quicker turn-around time and more power per code unit. This brings our future closer to where those in our past have already been. Kay, McCarthy, Moon, Kaehler and all those who used and pushed dynamic languages and systems have seen and invented the future, and that future is fully dynamic.
There's much more, including some examples of using a workspace to learn Smalltalk - and introducing the Browser. All the examples use Squeak, as does this tutorial he points to. Another good introductory resource - this blog Sam pointed to. As Sam quoted from there:
I repeat: "Smalltalk is different, everythings an object. It's not file based, you can't just go around defining a function," Methods must be attached to a class (or an instance). Smalltalk is different, it's powerful, and foreign to most programmers, because most of us are file oriented and not truely object oriented. We create what is supposed to be object oriented code in a file oriented world. Smalltalk isn't that way. You add methods to real classes that are instances of a Metaclass. Your code is an object and even the text you type in when selected and inspected give an object back and you can ask the editor your using to compile the code, run it and give you back the instances, or you can select parts of the text to see what types of objects they are. 5@5 being an example. Inspect it and you'll find out it's a Point instance. Read more to see how I tried to explain that to someone confused about Squeak/Smalltalk and how I tried to help him realize that OO isn't just a language, but when taken to it's logical extent it is the environment, and everything in it
The all embracing nature of an image based environment is often difficult to get across - the development paradigm is just so different from what most people know. Something similar happens when the debugger comes up - in Smalltalk, and exception gives you the debugger, which is itself a browser. This leads to people talking past each other when discussing debugger based development - for Smalltalkers, TDD and the debugger are natural fits. In most other languages/systems, they just aren't. Since Smalltalk is so different this way, it can be very difficult to get people past the first step. Once they have that "aha!" moment, it's all good. getting there can be an adventure.
There's another thread in comp.lang.smalltalk on debugging and testing. There's a level of misunderstanding between Smalltalk developers and people who've never used a language like Smalltalk - you'll see that in comments like this:
Debuggers are great tools, the but the thing to ask whenever you want to use one is why it isn't easier to just write a test case. In some projects it is. In others, well, we all know when we are working in a project like that, but there are things that we can do to make it easier.
It's not that debuggers are bad, its just that they can desensitize us. It's like downing a beer and sleeping on the beach; we shouldn't be surprised if we wake up with a sunburn. We can start to think that our code is pretty good when in fact its really pretty lousy because we've ignored concrete evidence that it could be easier to understand and test.
Now, I know why people who mostly work in languages like C# and Java say this - their debuggers are forensic tools - the patient has died, and the best that you can do is figure out what killed him. Smalltalk developers have a different tool at their disposal - the Smalltalk debugger
The Smalltalk debugger is both a debugger and and code browser. With Smalltalk, the developer becomes a surgeon - the patient isn't dead, he's been sedated. We can look at what's wrong with him, and fix him up while we look at him - in the debugger. That's why most of these conversations end up with people talking past each other. In Smalltalk, we can write the test - and when it fails, we end up in the debugger - from where we can patch the code (or the test, depending on circumstances) up and move along.
David Moschella of ComputerWorld has some timely points to make about IT and their interactions with the rest of the company - and it's going to require a lot of adaptation on the part of IT:
Do the employees in your organization ever complain that they have better technology at home than in the office? Do you require them to access corporate systems via a dedicated PC as opposed to any Internet-connected browser? Do they ever use their personal Internet e-mail accounts for business and laugh at the limitations of Microsoft Exchange or Lotus Notes? Do they sometimes shake their heads wondering why, if they can set up a wireless LAN at home in a few hours, corporate IT says wireless systems in the office are too complex and risky?
That's one issue for IT shops - the glass walls are gone, and the end users are getting to be experienced enough to know when they hear BS back from IT. Just about everyone I know has a story that fits into that paragraph. The problem is that the end user community is setting up their own (wired and wireless lans), dealing with things like GMail, and working with video and audio applications. Formerly patient users are now able to ask "why not?" far more convincingly than before:
The ramifications of this are now becoming clear. IT departments have become accustomed to treating employees like children who must be told what they can and cannot do. But many employees want to be treated like consumers, given choice and flexibility in their use of IT. If they are going to work at home and lug around dual-use work/personal devices, these devices will have to meet their personal standards, not just for functionality but increasingly for style and fashion as well. Requiring every employee to accept the same generic IT capabilities will become almost as absurd as requiring that every employee drive the same car.
That's what IT departments are facing - and the ones that want to succeed are going to become more flexible towards the user community. The ones that don't are going to cost their companies money.
Charles Miller makes some funny points about software development - Java and Ruby in particular.
I guess I'm not the only cynic on the MS announcements about Shorthorn - Charles Miller is desperately looking forward to the new photo experience as well :)
Phil Ringnalda says out loud what I've thought many times - and I'm sure many others have as well:
After just a few months, 3% of my unimaginably huge 1GB GMail storage has been used up by atom-syntax. If you are among the people whose name I can search on and be shown "1-20 of hundreds" of messages, if your typical quote:content ratio is huge, if every single thread of a hundred or more messages (there's at least one such burning all the time) prominently features you, you, you, you might want to consider whether this mess would clear up if someone took you out and shot you. Lord knows the rest of us are considering it.
No kidding. The thread on dates alone...
Everyone else has commented on the Longhorn decisions - but here's something I'm wondering about. MS has announced that the file system (WinFS) will be missing from Longhorn, and will "ship later". Hmm. I don't think you ship a file system as a set of dynamic updates to the OS - I mean seriously - outside of a major upgrade, how many people are going to take the time to install it? I'd say that it's entirely possible that WinFS will never ship. Why? Look at the timelines:
XP SP 2 - shipping now
Longhorn - shipping 2006
Longhorn is still two years out (at least - I wouldn't discount the possibility of further delays). MS isn't going to want to ship a disruptive upgrade too soon after Longhorn either - which puts WinFS out until something like 2008-2009 (at the earliest). Now, what's the liklihood that it'll survive that long without some MS development group deciding that they have something better between now and then? I'd say pretty slim.
I just upgraded my mobile phone, and decided to make it a camera phone while I was at it. So I got a Samsung sch-a610. It's not a great camera, but I'm not all that concerned - it was inexpensive, and it will work for what I want (quick shots to send by email or post here on my blog). I noticed that Verizon now has cheaper calling plans as well, so I saved a few bucks while I was at it. We'll see how it goes.
I think Marc Hedlund hates Word more than I do, and he's figured out the general issue that I've only mentioned examples of:
Microsoft hires very smart engineers -- I would say the smartest in the business. When they see that some number of their users have some writing problem they believe a computer could be trained to solve, they do a better job than anyone at writing the code to solve that problem. They talk all the time about "knowledge workers" and their needs. What the Word team lacks, in my view, is an awareness that, when a user is trying to get his or her own work done, the user is always smarter than the technology. Assuming that smart people aren't their market is the surest way to produce a bad word processor, which is exactly what I think they've done.
MS' Word team has decided that they know what I want, and they are really, really wrong If I could buy Word for Windows 2.0 today, I'd happily give up all the "progress" in the newer versions.
Blaine explains why many Java developers think Smalltalk is old and out of date:
So, why do the java developers think their tools are ahead of ours? Eclipse looks mighty pretty and it has a lot of great features. But, pound for pound, we have the same features and more. We have a live world to play in. Eclipse is nothing more than a painting of the world. We are the real thing! I can change the object inspector in the IDE and no shut down! Any change to Eclipse and I have to shutdown and restart. So, why are java tools considered better? The only thing I can think of is the looks. At work, we use VisualAge and well, VisualAge looks old. I'm trying my best to tell them not to judge a book by its cover and there's a reason a lot of people think it's cool. But, they have this notion that us Smalltalkers are just old technology guys hanging onto our past for dear life. It saddens me that they see me this way. I love new technology and I'm constantly studying new languages. But, so far, the one I am most productive is Smalltalk. Period. End Of Story. Ruby and Lisp are great too, but I can still code faster in ST. I would still pick any dynamic language over java/C# any day of the week.
So, here's the rallying call. How do we make Smalltalk not seem old. I think despite it's age, it's still far ahead of the game in a lot of areas and where we lack, we can quickly close the gap. Let's get rid of this stigma that Smalltalk is old technology. We are the future NOW!
Well, might I suggest that you show them a Smalltalk environment that is still under development - Cincom Smalltalk, or Dolphin. I can't speak to Dolphin's recent improvements, but For CST have a look over here. There's been a lot of work done, and there's a lot of work being done now. We have a development roadmap that covers the next few years - so you'll continue to see a lot of cool new things. If you want to impress the developers, show them what's being done, and what will be done - not what was done quite some time ago.
The next release of BottomFeeder should see a raft of improvements. I'm in the process of moving the Http code over to use NetResources - a package written by Michael Lucas-Smith. It's basically a cleaned up, better version of the Http-Access package that I've been using. This should result in some cleaner code, and better performance when fetching cached items (and a smaller footprint - this package does disk caching instead of the all in memory job that my package does). After that, the big job comes up - WithStyle. I intend to replace the Twoflower browser component with WS - and that should give a major usability boost. WithStyle handles CSS, and does a generally better display job. A fairly large amount of massage code that I've done to work around Tf limitations will come out as well.
These are fairly major revisions, and will require a fair bit of work on my part. I'm just starting on it now, and the whole thing will require testing before I let it out - even in dev. The end result should be a much better tool though - so we have something cool to look forward to.
If you are on the dev update stream for BottomFeeder, then you'll see a new update available this afternoon. There's an option on the item menu to spin an item out into its own window. I am still thinking of making a tabbed browsing kind of thing for the main Bf window, but doing it this way was far, far simpler given some of the existing code. See what you think.
Well, here's a gift idea for the geek who has everything - a Swiss Army Knife that comes with a USB drive. The drive itself detaches so that you can board a plane without hassles. Looks pretty cool.
One of the commenters in this thread said the following (as to why Java developers dislike Smalltalk):
The main reason most programmers dislike Smalltalk is *because of* the dynamic nature of the environment. If you hack away at your environment all the time, not only do you not get any work done (see "Macdinking" in the Jargon File), you end up shipping the workbench to the customer because your app won't run otherwise. Java IDEs produce code that can be run with a standard JVM.
Hmm. I guess BottomFeeder doesn't exist then. Separating tools from application is not as hard as the commentator makes it out to be. What his argument boils down to is this: "Protect me from myself, because I am not responsible enough to deal with power tools".
As to this:
It's not a matter of ignorance. Basically every professional programmer knows Smalltalk, from reading Design Patterns if nothing else, and quite rationally chooses not to use it. Making a prettier GUI isn't going to change that. We're not idiots, and we're not shallow, and the pompous attitude that we are makes us treat you with contempt. We chose the best tool for the job, and it wasn't Smalltalk.
Seriously, you're going to have to wait for me to get off the floor, where I'm suffering from a serious laughing fit.... Ok. I've traveled extensively, and attended a number of trade conferences over the years. The best you could say is that most programmers have heard of Smalltalk. Most of them couldn't identify code as Smalltalk code if their lives depended on it - not because they are stupid, or uninterested - simply because they haven't encountered it. It's possible that Lisp is less well known, but not by a lot.