You must have touched this entry because it showed up in Bloglines. I enjoy reading and rereading Smalltalk ’stuff’ to keep it fresh in the noodle (going on 10 years since I’ve written any serious Smalltalk code).

I had to stop reading the comments and probably missed out on some gems because of the one person with the closed mind. Did anyone correct him on the point of having a maintainable language? It’s the not the language that needs to be maintainable, it’s the design, it’s the vision of the application. The language aids in this endeavor (or hinders depending on your point of view and language of choice). For me, Java (and all C-based languages) hinder this process because it forces the developer to concentrate on the compiler and not the solution. That is why I have such an affinity to dynamic languages (that and I spent the first 5 years of my career writing Smalltalk applications); Ruby and Rails is going to be my ‘gateway’ language back to Smalltalk. ;-)

Plus, about your point about the applications existing as an extension to the language is powerful when you consider most business applications share a common vocabulary and purpose.

I wish the gentlemen luck in his endeavors. He is indicative of the type of people that love to argue for arguments sake.

Love the blog - keep up the great work!

Cheers,
Mel

from http://onsmalltalk.com/programming/smalltalk/objects-classes-and-constructors-smalltalk-style/

Smalltalk relies on pure OO and message passing rather than special language constructs. By being minimalist and only providing syntax for assignment,

everything is accelerating… 10 year software product life cycles and long project time lines are a thing of the past…

to be relevant and compete, businesses will demand (by any means) accelerated software development cycles and they will find PEOPLE that can deliver. the PEOPLE are already starting to choose dynamic languages like python,ruby, and smalltalk.

the very simple, consistent, and dynamic nature of smalltalk allows the “average” coders to be “smart” coders.

want proof *smile* ? try smalltalk… i dare you…

A while back I promised myself one thing - never argue about static manifest typing vs dynamic typing with people who have only used one of the two “ways”. It is like talking to a fish about the sky IMHO, no offense intended.

One fact that I am not sure has been mentioned is that Smalltalk actually EXCELS with large complex systems. There are lots of examples, one that can easily be found on the net is the Kapital system. I have also worked in a few larger systems and it has always been much smoother compared to for example java.

Finally, I have also taught OO and Smalltalk and one important aspect is that Smalltalk actually makes average programmers much more productive - which is really important in larger teams.

Oh well, whatever. Your blog is great Ramon, keep it up!

There’s nothing worse than being stuck with old standards that make things harder than they could otherwise be because of new capabilities that didn’t exist when the rule was made. I believe in continual learning and continual evolution.

“I haven’t met two “smart” persons who, looking at another “smart” person’s (or of anyone but themselves) code wouldn’t start whining in terror at that “dumbass” who wrote this “ugly, unintelligible, duct-taped piece of shit”

I think you’re confusing “smart people” with “prima donnas”. Truly smart people rely heavily on logic, inevitably arriving to the same basic conclusions, and though differences arise, are able to appreciate others code, even when its not exactly how they’d have done it.

As for Google, they’re growing like mad, and need manpower like mad, Java is the largest pool of decent programmers (vb’ers might outnumber them but the Java guys are generally smarter imho), they have to move towards it to continue growing. But they didn’t become the success they are “on Java”.

Clearly you think the enterprise approach is correct, for the enterprise, clearly I think that’s why startups do most of the innovation in this industry. While I appreciate your opinion, and the discussion, neither of us going to change our minds, and I’ve grown bored with the topic. I look forward to your comments on future articles, even if we don’t agree. ;)

It is wise to hire guys you call average and it’s unwise to hire guys you call “smart”, unless you’re a startup. And one thing more - I haven’t met two “smart” persons who, looking at another “smart” person’s (or of anyone but themselves) code wouldn’t start whining in terror at that “dumbass” who wrote this “ugly, unintelligible, duct-taped piece of shit”. So, in fact, I might safely tell that there are no smart programmers at all *evil grin*. But this is a fact that those “smart” guys can do work impressingly fast, and, if you point a shotgun at them, even fix bugs from time to time, so they are good for startups.

Re Google and Yahoo: This is exactly what I’m speaking of! Google was a startup created by some smart guys who noticed that search could be done better. And not only that - when they were starting most search engines’ front pages were loaded up with “portalose” and they were not, their front page was light, their result pages as well. So they have obviously won. (The only difference is that they didn’t decide to sell.) But mind now: Google is, very slowly yet inevitably, moving towards… Java; Python is still dominant there, yes, and it will be for years, but though they have so much money they can hire most of the smartest guys on the planet, and let them spend a day every week on whatever they want, yet pay for it, they are moving towards Java. Guess why *smile*?

That about sums up where we disagree. You think companies invest in languages and tools and need to mandate them as standard. I think that’s why the enterprise world sucks so bad, they haven’t accepted that “people” are the real investment.

Hire good people and keep them, let them choose their own tools, and get the hell out of their way, that’s what it takes to get things done well. They don’t resign because they have to follow rules, they resign because they can’t get anything done because the rules are often ignorant, arbitrary, and deeply ingrained to the point that change is impossible because so many mediocre people’s jobs now depend on the bureaucracy that they won’t let it change.

There’s nothing wise about employing a herd of average programmers to do what two smart ones could do in 1/10 the code, time, money, and effort. There’s not a shortage of smart people to hire, only an overabundance of ignorant managers who think programming is typing and they can just throw more monkeys at it to get it done.

BTW, I’m not the pope, but this is my blog, so I think it’s OK to express my opinion with as much authority as I like, especially since I’m right. ;)

Oh, there was an interesting article recently contrasting two huge companies competing with this same basic culture clash we’re having now. Yahoo did it your style, Google did it mine. Guess who’s dominating that market now! How do you explain the success of Google when so much of how they work directly conflicts with what you’re saying is necessary?

To some extent, people might be allowed to choose their own tools, but only through an accepted procedure within a company, ie. a programmer proposes to use X for a project, managers and other programmers comment and discuss and then a decision is taken (well, a negative decision might be taken much earlier, e.g. because of the X’s license). What people must not be allowed is to choose their own tools individually or even in teams, ’cause that’s a sure recipe for a disaster.

Been there - a project started using java.util.logging as a logging framework, then some people were moved to another projects, other people came and they decided to use log4j and even started to refactor earlier code to log4j, but they had no time to do it once and for all - and some modules’ writers disliked both, so they have just written their own file loggers and used those. So we had just that: chaos. And it weren’t only loggers such a disaster, nearly everything was written by programmers so smart as to think their way is the best, the only one. But with four average programmers we managed to clean it up and now it’s doable to maintain that code further.

I have no problem with smart (as in: I’m an evil genius) guys, BTW. As soon as they get to know they have to follow they rules, they choose to resign. Because serious programming has no place for cowboy coders, sorry. And those “averages” - yes, maybe they aren’t so brilliant, maybe they don’t do breathtaking solutions in hours, but I prefer calling them “wise”, because they know they aren’t the only ones that will use those solutions, so they *choose* to play by the rules.

A startup is different; most projects I work on are planned for 10-15 years of life (and thus maintenance), startups need to quickly dominate the niche they found empty, faster than anyone else and it’s usually decided after a year or two if they succeeded or failed. When they succeed, the enterprise buys them out and rewrite their code *smile*. So it’s good for a startup to use Lisp or Smalltalk or Ruby because they just need to be fast, but when it stops being a startup it’s better off to use a maintainable solution, not quick one.

(On the rest, I think we really can agree to disagree…)

You have a very pessimistic view of the future of programming, and think bondage and discipline languages are the correct path. I think that path is already dying out, and is the reason most of the interesting stuff done in computer science was done 30+ years ago in Lisp and Smalltalk.

I have a more optimistic view, I think the future of programming involves a resurgence of these style of languages, I think Ruby’s already starting that trend, I think Java and C# are struggling to keep up by adding those missing dynamic features version by version, getting closer and closer to almost what was available in the early 70’s in Smalltalk.

I look around and see Java and C# being used mostly in enterprise scenarios where tech people aren’t allowed to choose their own tools, a sure recipe for disaster. In startups and small businesses (which are the majority of businesses) I see the trend for dynamic and productive languages like Ruby, Python, Lisp, Smalltalk, Pearl, PHP, and JavaScript. Having worked in the enterprise for several years, I strongly think the enterprise approach is just wrong, and doomed to failure.

Ramon: First, please, let’s not get personal. I have never sent my CV to you so please don’t tell me what I have programmed in. Second, please stop making straw men - I never said that static typing is an antidote against bugs, in fact I think advocating static typing as a recipe against errors is doing it harm. I am convinced that unit tests are a far better way and static typing adds very little here, so we can see it as a very degraded kind of unit tests (though it has an important property: ensured 100% code coverage).

Now please do believe that runtime errors also do happen in Java apps, though not as stupid ones as misspelling ‘none’ for ‘None’. But when a runtime error happens to me, I look at the tests, at the sources and at the log message or the exception stack trace. If I still don’t know why the error happens, I know there is something wrong because that obviously means that I don’t understand how the code works and how it should work. That is why I tell you I find debuggers bad. Of course I’ve never worked with a Smalltalk debugger, but I have worked with Lisp ones and imagine Smalltalk debugger is similar. I never let the debugger “help” me find the bug, that’s what I meant. I think it’s the bad way, I prefer to sit down for some more time and work hard to *understand*. But the time has shown, I can now fix most bugs in my code without the debugger faster than most of my coworkers with it.

As to ifTrue: this is wrong that you can write correct code which is just ignored because some other code has been “optimized”. I don’t know what else is so “optimized”, but I do know, that if VM developers decide to “optimize” some method name I use in the next release, that means a hard time for me trying to figure what happened that my methods no longer are called. And that’s simply atrocious.

The free market did reject PHP if you don’t see it. Of course, from the Smalltalk standpoint it has wide wide acceptance, but it has been, in fact, rejected. It’s a very good language to write simple three-page application but no more, and though there are some successful apps in PHP it’s still nothing that real big money is paid for. Only Java and C# count.

jRave: But look even at evolution and the humans - humans are slow, weak, defenseless, if some alien biologist looked down at earth some 50k years ago, they’d think humans are doomed to extinction, but they were not, just because they had brains which made them king of the earth, but this alien would see no brains, just a lamentable creature which can’t even climb trees anymore. And the same could be argued for programming languages, if we were to follow your metaphor: Java and C# compared to dynamic languages are slow to write code in, unimpressive and very strict on the programmer so for you as this alien they may look doomed, but they have something you don’t see: good, valuable verbosity which serves as a communication tool, often for people who have never otherwise communicated or never will. Now why the humans dominated the planet? Because they had brains, yes, but really because having brains let them learn to communicate, work together and learn from each other. And the same is with languages, but more: the more they enforce communication, knowledge sharing the better they are. And it even holds further: a human would certainly lose a fight against many an animal, I mean really a fight: strength against strength, teeth against teeth, claws against, er, nails. But humans are who keep tigers and lions in cages, not the other way around, aren’t they? Look now: a “dynamic programmer” will certainly win the race against a “static” one when they have a nearly equal start, yes, but what really happens is that such “races”, though they let create nice success stories and make big money for some individuals are no longer significant because we “static” guys have created such an environment that, with exception of some very uncommon situations, there is no equal start - when the “race” starts the static guy has already won.

If you were to ask me about a successful language 20 years from now, how it will look like, I would tell that it will be mostly like Java 1.5, though with some things different:
* no annotations, but some, like ‘@Override’ will be promoted to keywords
* properly implemented generics, with runtime checking
* most of reflection removed, with exception of loading classes, instantiating objects; maybe method calling, but restricted to accessors
* no exception chaining
* no anonymous objects of any kind but numbers,
* only interfaces and primitives allowed as formal method parameters, no concrete classes
* more common control structures in the core language, other as hard to implement as just impossible.

I even try to implement some of those as rules in projects I work on and it’s very successful so far - we’re slower to start but the more time passes the faster and more agile we are and coming back to the code 2 years after the project was finished because a bug has shown and the customer demands we correct it is nearly no pain it used to be before.

(And think: I really hated this evolution analogy so far, but you’ve shown it to me, that it is so nice… *smile*)

Ramon: you might not want to accept it but what static languages do is make “average” guys better than you smart ones because they make commonness prevail over power. Not only they have better start - static languages are faster to learn, and unprecedented interest created so many good code just begging to be reused (especially for Java) which means real competitive advantage, but by simply following the rules they may (and probably will) write nd maintain better code than people smarter than them in more powerful languages.

Cedrick: No, I’ve never used Smalltalk, though I’ve used Lisp quite heavily - are their debuggers similar? In fact, I still do, as a hobby - and when I decide to start a startup it will certainly use a dynamic language even though I know that if someone bought this my hypothetical startup, they’d have to rewrite the entire code. But that would be their problem, I’d be already on some tropical beach by then… *smile*

“And even if I could, I still can’t see what type the original author intended to use.”
you see it generally in the initialize method, or in the getter (if lazy initialization)… Also, method name carry some information (enough for me about the type)… (from the more general anObject to the more specific aPoint, anInteger, aFigure ….)
Smalltalk is plenty of such conventions (ST Best Practise Pattern is the book about that) which are not compulsary but recommended… You’re free to use them or not… Dynamic is all about freedom, hence some pains especially at start since you don’t have a process to follow or code to copy/paste and adapt (you don’t have strict walls guiding you).

“Besides, I think that except some very special situations (like dealing with external hardware) you shouldn’t use the debugger and if you ever need it, it’s a clear sign that you have screwed up your unit tests. The only situations I allow myself to use the debugger are those when writing unit tests is impossible.”
Wow… I think we don’t speak here of the same debugger ! And I’m sure now you only have a superficious knowledge of ST systems…
ST 80 is an interactive development environment (SMALLTALK-80: the interactive programming environment - ISBN:0-201-11372-4) and the debuger is probably the best example of it…
In ST, it’s very common to write unit tests calling methods that doesn’t exist yet, then you write them on the fly in the debugger, step by step…

“Ramon: I see you write that you can’t redefine ifTrue. But you lie! You can redefine, yet the redefinition will be ignored by the compiler because it is somehow “optimized”. You knew that but I didn’t - and if I did such a thing for whatever reason it’d cost me hours of pain… ”
except, it’s clearly said in the method comment… “Execution doesn’t actually reach here because the expression is compiled in-line”.
But, I agree all this optimisations stuff and primitives calls makes the understanding of the system a bit difficult… but only if you go at a very low level ! Something wich is to me very very hard in static language… My squeak image is only 50Mb (plenty of packages and programs, networking, web server, seaside, scriptaculous, magritte, pier, interactive GUI, cryptography, ORM, etc etc…) and I’ve learned a lot (really a lot) since I’m using it… If you want to go low level, you can really easily (maybe at the price of some headaches ;) ) but you can…). Note I’m not a programer, some basic knowledges on C, C++, Java, Php before (mechanical engineering school), all seemed to me boring, repetitive and obscure, and now that I use ST, I just wish I had done CS studies !!!

My final 2 cents… :)

ps: About #ifTrue:, I put a self halt in the method and funny optimization stuff
true ifTrue: [1] does’t stop and answer 1 but it stops if I use the autocompletion stuf (hitting tab)… :)

The truth is hard to take, but average people aren’t intelligent enough to apply logic effectively to the level required by a computer. It takes skilled labor, by very smart people, to do it right. Anyone who isn’t smart enough to handle the “power” of abstraction without killing themselves, isn’t smart enough to be programming professionally anyway.

A programming language should be an enabling mechanism. It should allow the developer the freedom to invent creative and reusable solutions to problems via the power of abstraction. Any language that can’t create reusable abstractions to common problems tersely, isn’t worth using.

If all of your programs look the same, you’re doing it wrong. You’re repeating yourself, you’ve become a for loop. If you can’t build upon your own previous work, you’ll never be able to build upon the work of others effectively and you’ll never be a great programmer. Abstraction is what programming is all about, if you’re afraid of it, find another career.

Your arguments against new abstractions marks you as a specimen doomed to extinction - without evolving and adapting to rapidly changing environment organisms tend to quietly extinct. And plainly stupid imho.

You are saying that we should stop evolution and stagnate. Ok, you allow chosen few (who as everybody are not omniscient and certainly don’t know yesterday what anybody will be trying to do tomorrow) to steer the “evolution”. But the problem lies in people themselves. Some are trying to do what they are not capable of. Some are hiring those guys and than realize that all thay can safely let them do is to reuse patterns.

Just imagine that instead of 20-30 code-monkeys only able to use existing paradigms (carefuly explained to them, as they wouldn’t be able to grasp it on their own) you can hire 2-3 smart guys who will write elegant solution that a) fits your needs. b) can be easily extended/changed (by another smart guy, see what I’m trying to tell you ?), because smart guys know what they are doing instead of just copy & paste code they barely understand.

_PROGRAMMERS_ should be allowed to change virtually anything (and it’s a _GOOD THING ™_ some languages don’t force you to rewrite the compiler in order to extend them) standing in their way to get the job done. Those calling themselves programmers after doing a “hallo, world” tutorial should be shot on the spot, because they are the troublemakers (and trying to maintain their code ? nah, thanks a lot.).

people who apply pre-made solutions without understanding them, the problem domain and without ability to come out with solutions of their own are not programmers.

So just hire a few competent guys, give them a tool which won’t stand in their way and prepare to be impressed. Of course those mentioned monkeys won’t be able to maintain that code, they would have to understand it, but just stick to the rule and hire a competent guy to do it.

Maybe this link will give you the insight where the roots of behavior such as yours may lie. (http://dept-info.labri.fr/~strandh/Teaching/Langages-Enchasses/Common/Strandh-Tutorial/psychology.html)

If you don’t like what I have to say, then go read someone else’s blog, I have better things to do than spend my time arguing with you over pointless and trivial points.

I’m a Smalltalker, we live in the “runtime”, we don’t fear runtime errors, we fix them on the fly as they happen.

Smalltalk libraries are used by other Smalltalkers, when they upgrade to a new version of a framework, they expect these things to happen. They don’t fear them, they simply fix them on the fly, run their unit tests, confirm their applications still work, and move on.

If they find a runtime bug in production (they also fix it on the fly), and they write a unit test to prevent this bug from ever happening again.

As for #ifTrue… there’s nothing wrong with it being optimized by the VM, you shouldn’t ever need to redefine true and false anyway. That it silently ignores your redefinition, doesn’t concern me in the least, It’s not a problem that I’d ever run into.

As for the free market.. uhh… have you missed the fact that PHP is huge, hello, dynamic language. The free market has not ruled manifest typing is king, the free market goes with whatever works, as it always does.

Squeak by the way, is an implementation of Smalltalk, and it’s huge, far larger than any program you’ve probably ever worked on, and has had hundreds, possibly thousands of different programmers working on it for more than 30 years. So tell me again how dynamic languages aren’t suited for maintaining large complex programs with lots of developers?

I believe your conclusions are simply wrong, and your fears about “safety” and “maintainability” are unfounded. You’ve clearly never really programmed in a dynamic language for any significant period of time. I however, have programmed in both static and dynamic languages for quite a while, mostly static believe it or not. I’m telling you from my own experience, dynamic languages are far easier to maintain and develop. If you choose not to believe that, then so be it. Please continue to fear dynamic languages, less competition for me.

Albert, if “rejection of a programming language” is defined as you have defined it, then you must agree that Smalltalk is alive and well. Lam Research has a $64B market cap. Many of their products are built with VisualWorks. I cannot think of a more appropriate success story. JP Morgan has an active VW community, although I am not familiar with their use. Last I looked, they were a pretty big company.

There is plenty of room for competing languages in the enterprise software world. The payers out there don’t care what language you use — only that you get the job done on time and within budget. I’ve made a good living using Smalltalk. It is not my hobby. I have other, non-programming-related interests to fulfill that need.

Ramon, I am one of those “Old Dudes” that appreciates your blog. I was directed here by Runar Jordahl’s blog. I look forward to reading your posts.

But is it maybe the case that programmers are wise enough to use standard routines even when they aren’t perfect for the problem, they’re just sufficient?

BTW, you didn’t comment on the ifTrue issue. How is it on earth even possible that a language which aims to be seriously taken lets you “redefine” a method, takes its definition and does NOTHING. Not a single warning but the method is never called, it’s simply ignored. That’s just plain ridiculous.

And that’s what the ultimate judge - the freemarket - ruled: manifest typing is king.

Most of the problems manifest types solves, are created by manifest types in the first place. When manifest types get out of the way, the style one programs in changes to take advantage of a dynamic languages nature. The problems solved by manifest types simply aren’t that interesting to us, type errors just aren’t the issue you and Cedric Beust make them out to be, they’re trivially fixed.

I’m not willing to give up things like dynamic proxies, decorators, and doesNotUnderstand just to avoid silly mistakes like sending the wrong type to a method that wasn’t prepared for it.

As for programmers going crazy with abstractions and ruining the language, the existence of Squeak Smalltalk proves that is also a straw man, and not something to be concerned about. Bad code is easily deleted. I simply don’t believe that only the compiler writer should get to determine what control structures are available to the language. Every programmer should have this freedom.

Java has got it wrong by not having such a foreach loop in the first place, but has got it right that it made homebrew implementations hard and, in fact, nonsense - as they would be harder to use than explicit coding such a loop using existing abstractions. So now I have no problem - I see what is written and don’t have to dig which one of 100 foreaches in the project is this one?! See, it really helps maintenance.

And re manifest typing, have you read Cedric Beust’s article I pointed you to? I don’t want to repeat him so please read it and comment, instead of repeated shouting “four legs^W^Wmanifest typing bad!”.

Cedrick: With a debugger I will see the actual runtime type of a piece of data, yes. But it is the type in a given program execution, in another execution, under different conditions a piece of data assigned to the same variable might be of another type and I cannot examine all possible executions. And even if I could, I still can’t see what type the original author intended to use. This is why I really need an explicit declaration and no type inference, even if it’s possible statically.

Besides, I think that except some very special situations (like dealing with external hardware) you shouldn’t use the debugger and if you ever need it, it’s a clear sign that you have screwed up your unit tests. The only situations I allow myself to use the debugger are those when writing unit tests is impossible.

Ramon: I see you write that you can’t redefine ifTrue. But you lie! You can redefine, yet the redefinition will be ignored by the compiler because it is somehow “optimized”. You knew that but I didn’t - and if I did such a thing for whatever reason it’d cost me hours of pain… And now look at what would be if it were Java. Even if a method named ifTrue is being optimized away, you can define so named method for an unrelated type and it will work. And for a method to be optimized in such a way you have to declare it final, so redefinition on a subtype is not possible. See? Another obvious sign that manifest static typing rocks the world! :-))))

“What if I define String>>ifTrue:”

What’s the point, we know #ifTrue is optimzied out, define String>>myIfTrue: instead.

I never once said you could redefine existing language elements that are optimized. I just said those elements are defined in the library, which they are, and were, before being optimized.

The point is you can define “new” control structures the same way. So I have no idea where you’re going with this.

“Truth in place of your Truthiness”

Now that’s funny, Mr Colbert would be proud. See, toss in a little humor here and there, and I’ll enjoy talking and even disagreeing with you, but you don’t usually do such, you’re just combative, which is no fun.

:(, you’re just so disagreeable.

“I just put “self halt.” into True>>ifTrue: but it hasn’t changed the behaviour of True>>ifTrue: why is that?”

Well duh, that won’t work, it’s optimized out, obviously, but put a self halt before the call to #ifTrue: and you can step into it just fine. Any more straw men?

“Yes Ramon, Smalltalk is still “in use” - don’t you think saying “wide use” should mean something more than just “in use”?”

OK, how’s this… Smalltalk is in “wide enough use”, for me! You happy? Now, do you have something useful to contribute, rather than just arguing, as you always seem to do? Arguing bores me.

This doesn’t however change the fact that conceptually and syntactically, they are in the libraries. The code is still in the Smalltalk image, and the unoptimized version is still used when debugging, so you can step through them, even #ifTrue: and #ifFalse.

Smalltalk has been around for more than 30 years, if it weren’t in use, it wouldn’t still be alive and kicking with several active implementations and communities. If you don’t want to call that “wide” use, then so be it, I’m not going to argue.

maintenable language means here a language with lots of manpower avalaible (whatever the quality… the more, the better…).Did you notice it’s even more maintenable if done in India.

look at dabbledb, done by 2 (clever) guys… maybe it’ll be bought and done in another HUGE framework, but I would really be curious on the figures…

“Not smart language, not innovative, but yes, maintainable one.”
I think you’re really wrong here… Once you’ll understood how to use a debugger in smalltalk, you’ll really see what a really good maintenable language is (just inspect the living code, and you’ll see the type) ! For your information, there are also type inferer… and last, unit tests seems to be a better tool for maintenance than static typing…

“As to mainfest typing more maintainable being an urban legend, please stop ignoring facts, they don’t cease to exist anyway”.
sure it’s a good reason…

“So this alone is a real maintenance pain”
yes I hate reading too…;).

My naive vision is that static typing is good for C, for system programming, real time, specific performance related issue… but sure not for businness apps… Static typing is a legacy of the outdated punched cards…

Smalltalk is a nice and smart language as few others and it generally attracts smart peoples (I don’t count myself as one :) )… and probably the danger is that it’s not accessible to everybody, then you won’t easily find the guidance… (except effort like Ramon’s Blog, so please continue!). Actually, my main critisism is Smalltalk (&co) are too elitist and the entry fee is high :). Hard time for a noob…so for the majority of programmers out there

Cédrick
sorry for the troll ;) !