http://squab.no-ip.com/collab/uploads/61/IsSoftwareEngineeri...

But as an argument for one paradigm vs. another it doesn't really stand up, because the essay takes its own conclusion (that large systems would be easier to maintain if they were more like Squeak) as a major premise. Him being one of the inventors of the platform, I don't think we can just take his word for it. At a minimum, what we'd really want to see is a large successful enterprise system built on Smalltalk to serve as an instructive example. To my knowledge no such system exists, so we can't really take the paper, insightful as it is, as much more than hopeful musing.

That said, the "bind really late" approach has seen a lot of success. Just not quite so pervasively as the "in all aspects" that Kay advocates in the paper. Nowadays, the standard way to build large systems is to build completely independent modules and couple them on fluid interfaces. Text streams in Unix, REST APIs, and even SOAP are clear examples. What we don't see, though, is a whole lot of reason to think that the languages and run-times on which these modules run must also support late binding and hot-swapping of code at the micro scale, or that we're really suffering for lack of it.

"a fully-integrated, model-driven, automated silicon wafer fabrication facility (fab) ... ControlWorks managed fab saved TI the equivalent of 1.2 fab lines last year. What does a fab cost? roughly $1B!"

http://www.google.com/search?q=ControlWorks+smalltalk

Kapital, 70 developers in 4 locations in 2005

http://www.google.com/search?q=kapital+smalltalk

http://www.google.com/search?q=oocl+smalltalk

Does such a system exist to anybody's knowledge? I've heard that there's a good bit of Smalltalk on Wall Street, but companies don't like to advertise it because it's a competitive advantage.

http://www.google.com/search?q=kapital+smalltalk

To be honest it doesn't seem that you are arguing against this concept that strongly, you're just not overly sold on it. I agree it's good to be sceptical, just as I'm sceptical there is all that much value in static typing in most cases. Having used a statically typed language for years, I've personally found the value to be little and the cognitive friction to be high.

I wasn't using the word 'advertise' to suggest he was getting paid to push it. I was using it in very much the same sense in which you use the word 'sell' here:

> To be honest it doesn't seem that you are arguing against this concept that strongly, you're just not overly sold on it.

To which I respond: Correct. I'd even go so far as to say I'm not arguing against the concept at all.

Considering that all sorts of approaches to software development continue to be extremely popular, including among very smart people, it just seems crazy to me that people get so acrimonious about such issues. Programming is a very wide and varied field. If two developers try something and come away with differing opinions of it, isn't it just possible that those different opinions are both informed, but informed by different experience resulting from working in different problem domains? I'd submit that developers don't give each other nearly enough credit when they offhandedly dismiss each other's sharing of their own practical experience as "FUD".

To bring it back to Kay's paper: He's got some very interesting ideas, but the specific examples he talks about are problems that just don't cause me any stress in my day job. Yet he implies that people in my problem domain are suffering for not using his preferred programming paradigm. Now I don't want to accuse him of attacking me, and I certainly don't want to attack him because I believe that paper represents learned speculation and not a stake in the ground. But it remains true that he's not necessarily coming from the same place that everyone else is, and his experience of what works well does not necessarily translate into a universal best practice.

What makes you say that?

First, I happen to have worked with this fellow before [Hi, John! Long time no see. Fun to come across your post here.] and I'm sure he's quite sincere.

Second, having spent a bunch of time lately in dynamic languages (Ruby and JS mostly), I do indeed miss the automated refactoring tools that existed for Java. It's really nice to be able to rename a method everywhere across the code base without worrying that something else got mangled. I also miss the magic documentation that a type-aware IDE can provide; I spend a lot more time digging through layers of code to figure out what a particular parameter is expected to be.

Not that I want to switch back; I agree that a language with strong type inference is the way to go. But man, I miss the tools.

There are generally very few situations where you have a single method from a single class sprinkled across an entire codebase for a good reason. That always indicates high coupling and design problems. There are even fewer reasons to rename a well designed method. Constant renaming and high-coupling are bad habits that seem to be commonplace when working in strictly static languages and yet they are known to be bad habits even there. At least dynamic languages discourage these anti-patterns. Not to belittle your friend, I found myself falling into these traps constantly when working in C#.

Honestly, what I'm saying is that these problems just are not nearly as significant in say, Ruby, as they are often made out to be by static typing proponents. It's a bit disingenuous to point to these trivialities as reasons why static > dynamic. If it were true then there would be little benefit in dynamic languages. Clearly there is.

More generally, the ability of modern IDEs to manipulate code structurally, and not just texturally, has been eye opening for me.

The theory that you can get good design up front depends on having both a stable problem and a stable solution. Most places don't have stable solutions, because creation of software is usually an exploration of the solution space. (If you don't need to explore the solution space, that often means you should just buy something off the shelf.) Quite a number don't have stable problems, either. Some people have innovative competitors; others are doing startup-ish things.

As Keynes said, "When the facts change, I change my mind. What do you do, sir?" I think that applies to design as well, method names included.

I am reserving most of my replies for the comment section of my own blog, but I couldn't resist say hi to you. I am in fact sick of typing in type labels (so strong type inference is great, it is just finally becoming available to us masses).

Also I would like try defend refactoring. Those that don't think it is important have not seen it used well (there are a lot of trivial uses of refactoring). I remember pair programming with Brian Slesinsky (when the two of you were coaching). We wanted to change some deep functionality of the project. Brian slowed the moment down for a bit and then said something like: "we call this refactor method, then introduce this error here, fix it here and then call this last refactor to clean it up." He was definitely not only doing what the IDE supplied but thinking in a very deep way how to trick the IDE into correctly performing a big change it was not designed for.

I don't think you should post it here if you aren't prepared to discuss it here. That seems disrespectful to the community.

For example, I'd like to hear your response to this objection: http://news.ycombinator.com/item?id=3633596.

Yet it seems to be what the evidence is telling us.

At this point it doesn't make much sense to say that C# is strictly anything. It's perhaps the most obsessively multi-paradigm language out there.

http://wekeroad.com/2010/08/09/csharps-new-clothes/

In case you plan on skimming that and missing the details the tl;dr is that Rob, pushes `dynamic` as far as he can and it still comes up far short of the extensibility and expressiveness of Ruby constructs.

However, I don't find that a problem. I tend to prefer the correctness of statically typed languages these days.