The rantings of a beautiful mind

On life, society, and computer technology.

My Photo
Location: Toronto, Ontario, Canada

I live in the Fortress of Solitude. I drive the Silver Beast. My obsession is justice. I used to be a Windows software developer. I retired in 2000 when my stock options helped me achieve financial security.

Thursday, November 23, 2006

Dynamic versus Static Typing

People in the 1960s (such as Niklaus Wirth) pushed static typing in languages like Pascal. What evidence was there at that time that the lack of static typing was causing problems in software development? How many millions of lines of code, or how many software projects, did they look at to arrive at this assessment? (Yes, it’s a rhetorical question.)

So for the last four decades, we’ve lived with that static typing legacy, not ever questioning whether it was truly a good thing or not. And now we see anecdotal evidence from the Ruby and Smalltalk communities that perhaps static typing was not the great defensive facility that computer scientists made it out to be. Have we all been blinded by conventional wisdom?

Shouldn’t somebody make a detailed study of this question??

Tuesday, November 21, 2006

Creeping Featuritis

From my perspective, Java, C#, and C++ all belong in one category: statically typed, feature-rich, straightjacket programming languages. The static typing imposes a complexity and messiness that outweigh any safety benefits. The innumerable features also needlessly add complexity to the language, making them a poor substitute for “metaprogramming,” which is a powerful facility found in Smalltalk, Lisp, and other dynamic languages. The end result is a basic lack of flexibility and versatility which leads to my term “straightjacket.”

In other words, Java, C#, and C++ are, in my opinion, mere variations of a basic language paradigm. To compare the languages among themselves and say that one is “better” than the other because of this feature or that is a silly exercise in semantics...they share the same essential drawbacks, after all.

We need to get away from static typing. We need a minimalist language, one not encumbered by numerous features of convenience. Language designers just can't help "evolving" their languages by continually adding more and more features. For example, look at C# and Ruby. Beware of Creeping Featuritis.

Sunday, November 19, 2006

More on Project Risk

I share Joel’s sentiments, I really do. I’m not suggesting that enterprises jump whole hog into using a “non-mainstream” language, but they should at least give promising tools a try, starting with pilot projects to suss out any problems with scaling or performance. To continue to play it safe all the time is to miss out on potentially valuable opportunities. No guts, no glory—even in business, this aphorism applies...

Of course, I’m not saying that enterprises should suddenly abandon their Java/C++ teams. All I’m saying is that they should examine new opportunities to improve software quality, efficiency and economics of development. Start with pilot projects and if that produces impressive results, try larger projects. It has to be transitional.

But concerns about social dynamics and internal resistance imply that everyone should stick with Java/C++ for geologic ages. Not allowing for the possibility of improvements makes for dinosaurs and we all know what happened to them.

You can’t allow your staff’s beliefs about Java/C++ to stop you from moving toward better alternatives, not when the potential economic/business gains may be colossal. Change for change’s sake is not good but neither is stagnation.

Train your staff in Smalltalk. Do it in phases or do it in segments of your staff. There are ways to manage resistance.

But don’t let ignorance about the virtues of dynamically typed, purely object-oriented, meta-programming language tools stop you from discovering revolutionary improvements in the software development process. We are on a potential cusp of history...

On 11/19/06 12:02 AM, "nonpartisanartisan" wrote:

Selecting a simpler language is fine ... if you can find sufficient staff trained in that language. If I needed a team of 40 engineers trained in Smalltalk who could communicate and bond with each other I would have a very hard time recruiting these people to begin with. I would be up Sh!t Cr33k without a paddle.

Moving to a new language has a social dynamic of internal people resisting change and hating external people brought it to replace them.

Experienced C++/Java programmers are suddenly "new" inexperienced Smalltalk programmers. High stress. Or else replaced by external people - huge morale problems internally.

Having a limited supply of people, abandoning your own staff and their beliefs in what languages are good, making them feel inadequate helps morale and moves the project along?

Movie Review: Casino Royale

I’ve been a big James Bond fan all my life. Having seen every film in the franchise, I can tell you with absolute confidence that Casino Royale is the best Bond movie ever made!

To start with, the script is delightfully good. Penned by Canadian Paul Haggis (Crash; Million Dollar Baby), the story is rich with character and emotions. As a result, this is a much darker film than any previous Bond flick. Dark, gritty, with lots of feelings. It reminds me of Batman Begins, another movie that hearkens to the early days of the protagonist, also in dark and gritty tones. Do I detect a pattern emerging from Hollywood?

This is a Bond unlike any other that came before. He lives up to his professional status as Her Majesty’s Secret Service assassin. He kills in cold blood. He looks for all the world like an ordinary man, not even a particularly handsome man (his nose is rather large, his ears are like Prince Charles’, his head reminds me of a mantis head). If not for his incredible physique (which puts even Sean Connery’s to shame), it’s difficult to see his attraction to women. Perhaps it’s his ruggedness and assertiveness that confers on him a sort of je ne sais quoi. At any rate, Daniel Craig pulls it off as a very convincing James Bond.

The story is based on Ian Fleming’s first Bond novel of the same name which follows Bond’s ascension to double-oh status within MI6. This was before the vodka martini that is shaken, not stirred. Before the pimped-out Aston Martin ride. Before the fancy gadgetry from the genius of Q. Before his cold-hearted womanizing. Before his flirting with Moneypenny.

Bond’s mission is to “turn” an international financier of terrorists by cleaning him out at a high-stakes poker game in Montenegro. By bankrupting this man, named Le Chiffre, MI6 hopes that the threat of torture and death at the hands of Ugandan thugs will force him to seek refuge with MI6 and help them in the war on terrorism.

A fine example of how this film departs from the usual Bond formula is a scene where Bond is stripped naked and tortured (having his genitalia pummelled). Now I know that in the last Bond film, Die Another Day, Pierce Brosnan was also tortured. But there, the torture was not graphically displayed as it is here (no, we don’t see his genitalia but boy do we feel the torture!). The scene reminds me of how George Clooney was tortured in Syriana.

The movie also brings us very close to the person that is James Bond. He suffers great emotional loss and Daniel Craig displays this extremely well. This makes Craig the best thespian of all the actors who have played the role. (Sorry, Sean!)

But for those who hanker for the previous Bond movies, we still have some of the great Bond elements. Two Aston Martins are featured, including the brand new (and gorgeous!) DBS. We have two excellent Bond women. Judi Dench returns as M (most would not mention Judi Dench, but for me her presence adds a lot to the film). The exotic locales and beautiful photography are here too. And, of course, we have lots of great action.

Before Casino Royale, my favourite Bond was Sean Connery. He defined the role. He looked the part. But now I have to say, Daniel Craig is a better Bond. With Craig, the franchise has been given new life, new energy. It’s a fresh beginning and I am very impressed.

This is one of my very favourite movies of the year. It may well be one of the year’s biggest box office hits. And that would be well-deserved.

Saturday, November 18, 2006

Project Risk

Gartner’s numbers are from 2002, but they pretty much apply TODAY as well. Java, Visual Basic, and C++ are still the most prominent of the mainstream programming languages. And the stats on failed software projects couldn’t have changed much in the last 5 years...

Depending on your definition of “failure,” anywhere from 40-70% of all software projects fail to satisfy their key requirements—either they come in very late, or very over-budget, or they just don’t meet end user expectations. “An inordinately large number of large-scale Java projects have been failures.”

Now, far be it from me to blame the failures on the language tools. There are many reasons why projects fail, and very often the finger points to bad management or bad communication or bad analysis. The choice of language tools rarely contributes to failure (though it may cause teething problems and the like). It stands to reason, then, that choosing a non-mainstream language should not significantly increase project risk (unless you choose something really far out on the fringe, like OCaml, Erlang, Haskell, or Lua).

[As an aside, I suggest that Smalltalk is a better choice than Lisp because, while Lisp is not a fringe language, it is quite alien-looking compared to most other languages. At least Smalltalk resembles English in its syntax and is thus extremely readable.]

But why choose an alternative to a mainstream language? Java, Visual Basic, and C++ have been amply proven in the field, and there are huge ecosystems surrounding these languages. Skilled people in these areas are easy to find.

The answer is high productivity, quick and easy prototyping, lower programmer stress, and lower defect rates in the software, to name a few advantages. Some of these help to shorten a product’s time to market. Others improve the chances of meeting end user expectations. But in particular I want to touch on lower programmer stress...

Using a language tool that is simple and easy to master helps to avoid the cognitive effort in managing the complex of language features found in today’s mainstream languages. There is no question that this cognitive effort—subtly, cumulatively, and over time—contributes to programmer stress. People in the software engineering field know exactly what I’m talking about (or perhaps not—it may be too subtle for them to notice). But even if they don’t notice, the stress is still there, and the long-term consequences may include burn-out or job-hopping.

Choosing a language tool that addresses a programmer’s cognitive nature would preserve the efficiency (and sanity) of your programming staff. It may help to reduce turnover and perhaps even improve morale. How can this not be good for your software project?!

With all due respect to Joel Spolsky, he’s dead wrong. Choosing a mainstream language does not significantly improve a project’s likelihood of success, and as Gartner’s data show, it may actually worsen the chances! Choosing something like Smalltalk does not entail greater project risk, and it promises benefits that absolutely cannot be found in today’s mainstream languages.

Java EE 5 Simply Too Complex

Java is too complicated. (And don’t get me started with C++.) While enterprises may feel Java is the safe choice, they’re also putting you programmers through the wringer...

Life is too short to work so damn hard.

Projects Do not Fail for Technical Reasons

They Fail for People/Communication Reasons.

What the analysts and pundits don't take into account is how technical choices aid or impede communication. One of the largest problems faced by IT shops is churn - there is always a new silver bullet technology that will solve all the problems. What this means is that most IT shops never gain enough expertise in any given set of tools to be truly productive; they are always moving on to new tools that will theoretically solve the problems better than the old ones.

What developers need is tools that will help improve communication - both between themselves, and between their customers. If the technologies they choose to implement in are complex, then developers will consistently be speaking jargon - solving technical problems instead of business problems. If, on the other hand, developers are given tools that are not complex, they will spend more time solving (and discussing) business problems instead of technical issues. To use a trite example, simpler tools will allow developers to discuss requirements instead of compiler errors. Tools that mostly get out of the way and allow developers to express the intent of their customers are better; tools that layer on complexity and arcane rules stand in the way, and prevent or delay these expressions of intent.

One thing to bear in mind is research from psychology. People can, on average, keep 7 (+/- 2) things in mind at once. Adding to the number of things that need to be kept in mind is not really possible - it's a human limitation. Choosing tools and/or processes that insist on throwing complexity directly in the face of a developer are as sure a recipe for failure as is possible - simply based on the reality of human capabilities. What does this mean? It means that choosing a strict process with many steps and lots of documentary steps is not going to work - the sheer complexity of the process will over burden the average developer. Likewise, choosing a set of development tools that require a steep learning curve will add problems. It will take longer for developers to internalize the rules well enough to be productive. It's a simple fact that projects will not normally be staffed with as many experienced people as you would like - so choosing technologies that make things simpler will get you started sooner.

Where does this drive us?

Processes - pick an agile methodology. A heavyweight, process driven methodology will wear developers down and prevent progress.

Tools - pick an agile toolset. A set of complex tools will likewise wear developers down and prevent progress.

What satisfies these?

Visit the Agile Alliance for tips on process. For tools, take a look at Smalltalk. It's no secret that the Agile Alliance leaders are virtually all from the Smalltalk world; there's a reason for that. Smalltalk is simple and powerful. A beginner can learn it in minutes, and an expert can express a design clearly and tersely. One complaint you'll hear is that Smalltalk has a large learning curve. And Java or C# don't? Smalltalk has 5 reserved words and syntax that fits on a 3x5 card. C# and Java have 50+ reserved words and very complex syntactical rules. It simply is not the case that Smalltalk is harder to learn.

- James Robertson

Thursday, November 16, 2006

No guts, no glory

Joel Spolsky says:

Before you flame me, Ruby is a beautiful language and I'm sure you can have a lot of fun developing apps it in, and in fact if you want to do something non-mission-critical, I'm sure you'll have a lot of fun, but for Serious Business Stuff you really must recognize that there just isn't a lot of experience in the world building big mission critical web systems in Ruby on Rails, and I'm really not sure that you won't hit scaling problems, or problems interfacing with some old legacy thingamabob, or problems finding programmers who can understand the code, or whatnot.

Well, interfacing with old legacy thingamabobs is a typical problem nearly all software projects face. Using Java or C++ certainly doesn’t obviate that. And whether you are using Ruby or Smalltalk, this certainly is not an intractable problem.

And is it true that Java scales well for all types of software projects? I don’t see why Ruby or Smalltalk should have greater scaling difficulties. (In fact, the experiences of Smalltalk enterprise customers show otherwise.)

As for finding programmers who can understand Ruby code, there appears to be a LOT of them around the globe, given the rapidly increasing popularity of the language. Unless you are expecting high turnover rates in your software project (suggesting you have other, more pressing problems), this shouldn’t be a major concern.

So while Ruby on Rails is the fun answer and yes I've heard of 37 Signals and they're making lovely Ruby on Rails apps, and making lots of money, but that's not a safe choice for at least another year or six. I for one am scared of Ruby because (1) it displays a stunning antipathy towards Unicode and (2) it's known to be slow, so if you become The Next MySpace, you'll be buying 5 times as many boxes as the .NET guy down the hall. Those things might eventually get fixed but for now, you can risk Ruby on your two-person dormroom startup or your senior project, not for enterprisy stuff where Someone is Going to Get Fired.

Joel assumes that choosing to develop in a non-mainstream language entails greater risk than any other kind of risk that software projects inevitably have. Is this a reasonable assumption? What evidence can anyone provide?

There probably aren’t enough Ruby projects to offer a good statistical sample. Perhaps this is what enterprises want to see in the way of proof before they accept the risk of using Ruby. But such proof won’t be forthcoming unless or until enterprises take it upon themselves to explore the wonders of dynamically typed, purely object-oriented language tools, such as Ruby and Smalltalk.

I share Joel’s sentiments, I really do. I’m not suggesting that enterprises jump whole hog into using a “non-mainstream” language, but they should at least give promising tools a try, starting with pilot projects to suss out any problems with scaling or performance. To continue to play it safe all the time is to miss out on potentially valuable opportunities. No guts, no glory—even in business, this aphorism applies...

Wednesday, November 15, 2006

Playing it Safe

The safe answer, for the Big Enterprisy Thing where you have no interest in being on the cutting edge, is C#, Java, PHP, or Python, since there's so much evidence that when it comes right down to it zillions of people are building huge business-critical things in those languages and while they may have problems, they're not life-threatening problems.

Joel Spolsky talks about playing it safe. For the enterprise market, which is pretty conservative, it's all about making safe choices when it comes to software development projects. It's hard to argue with that. However, with that kind of thinking, we miss opportunities to significantly reduce the time to market of deliverables, the cost of code maintenance, and the labour cost of software engineers. For example, Smalltalk is often lauded for its extremely high productivity, helping to complete software development three to five times faster than using Java or C++. How much is it worth to a company to hire far fewer developers to do the same amount of work? Or to get a product to market much sooner?

Joel says Java and C# are safer because it's easier to find project experts with lots of experience in these languages. There's no question this can be advantageous but let's not overstate it. Having a Java expert on a Java project does not guarantee its success. But having good engineering talent (regardless of programming language) who's not afraid of change does help.

Joel says Java and C# are proven, with huge numbers of successful projects based on these languages. But I can show you eminently successful Smalltalk projects too. Just visit: Cincom VisualWorks has been successfully used in many enterprises, including recently:

  • Adventa Control Technologies
  • Federal Express
  • JP Morgan
  • Penn State University
  • Scarborough Research
  • State of Wisconsin Department of Revenue
  • Texas Instruments

For proof that Smalltalk is great for web development, look at, which was developed entirely in Smalltalk and Seaside (the Smalltalk equivalent of Ruby on Rails).

I harp on software tools a lot, but I also know there are other reasons for missed deadlines and slow development. For example, marketing and sales departments overpromising on what you can deliver, poor project scheduling or resource allocation, inadequate requirements gathering, weak analysis, etc. But these are issues that cannot be easily fixed with technology.

The application of superior tools, on the other hand, can relieve a very significant bottleneck. It has been my experience that more than half of the software lifecycle (including maintenance) is spent in the trenches, coding, debugging, testing. Anything you can do here to improve productivity pays off big time. And it’s so easy! Just look around you for language tools with a proven record...

Like Smalltalk.

The Only Sensible Choice

As a language, Ruby can be pretty accurately and completely described as a dialect of Smalltalk with Algol-inspired syntax and some scripting-friendly extensions. If this is going to be the new mainstream, I’m sure any Smalltalker would agree, we could do a whole lot worse. But here’s the rub: all those goodies you get with Java would, at least temporarily, disappear. Ruby has no bytecoded VM, no JIT, and no IDE that can hold a candle to Eclipse or, say, VisualWorks. There’s nothing wrong, particularly, with emacs and interpreters, and working in Ruby is still a pleasure, but there are definitely projects for which the immaturity of the implementation and environment get severely in the way.

Also, “Beyond Java” looks like a book worth reading...

Bruce Tate has an intriguing notion about the future of Java, and it's causing some agitation among Java developers. Bruce believes Java is abandoning its base, and conditions are ripe for an alternative to emerge.

In Beyond Java, Bruce chronicles the rise of the most successful language of all time, and then lays out, in painstaking detail, the compromises the founders had to make to establish success. Then, he describes the characteristics of likely successors to Java.

C++ too damn complicated

C++ containers are like three-ring binders: they generally hold objects from a single class (or subclasses of that class). These containers are less flexible than Smalltalk’s, but safer, for any code that attempts to add an object of the wrong class to a C++ container fails to compile. This safety comes at a price, though, because you need to develop a class of container specialized for each kind of object you intend to hold—a SetOfWhale as well as a SetOfInteger. A C++ language feature (templates) simplifies the definition of such container classes, but container libraries in C++ still tend to be unwieldy, complex, and difficult to write. The need for fast, robust containers has spawned a cottage industry for container libraries. Sometimes these libraries are called foundation libraries, to acknowledge their essential place in object programming. Sadly, foundation libraries are sometimes not interchangeable [Standardization will help. The ANSI C++ standard now specifies a Standard Template Library.], because they are often integrated into larger libraries or frameworks that provide other services like windowing or communications or persistence. By contrast, every Smalltalk dialect includes an integrated foundation library—the subclasses of Collection. This library cannot be decoupled from Smalltalk because so much of Smalltalk itself is built using collection classes.

- Chamond Liu

Templates are one of the many, many reasons why C++ is such a bitch to program in. The C++ language itself is inordinately complicated, and as if that weren’t bad enough, the C++ infrastructure is a cumbersome morass of complexity. No wonder C++ software development is so costly and time-consuming!!

And now we see that Java and C# are headed in the same direction.

I’m not saying you should never use C++, but you had better have a damn good justification for it. Use the right tool for the right job. Make sure your reasons are not half-assed.

For most applications, Smalltalk is the right way to go...

Monday, November 13, 2006


The only obstacle to Smalltalk adoption is that people are not comfortable with pure Object-Oriented Programming (OOP). Smalltalk demands that you think entirely and purely in terms of objects and classes. You need to feel totally comfortable with object-oriented design. Hence, the reason I’m reading Chamond Liu’s book “Smalltalk, Objects, and Design.”

I love this book!! It is so well-written, so easy to read, and so elucidating. It may well be the best book on Smalltalk and object-oriented design ever written!

I’m paying a lot of attention to this book because I feel that I need to establish my mindset in a totally and purely object-oriented way. I have to eat, sleep, and think objects and classes. For over twenty years, procedural programming has been drilled into my consciousness, and I’ve got to completely shake that.

I believe that if you establish this object-oriented mindset and then practice with the Smalltalk class library, you will quickly become proficient. Smalltalk is the perfect OOP language, much more so than Ruby or Java or C++.

I highly recommend Chamond Liu’s book. Well worth the purchase price:

Monday, November 06, 2006

Smalltalk -- some early thoughts

Here's a very good blog about one person's first impression of Smalltalk: Smalltalk -- some early thoughts.

I love this comment:

There's no native Regular Expression support. There's a regex library which sucks rubber donkey lungs ('Hello World' regexMatchAll: 'l*'. causes an infinite loop.)

Better than “camel piss”...

Rails versus Seaside

This is a pretty good blog: Rails and Seaside.

On balance, I think, Seaside is superior to Rails. Not that either is perfect, though.