Objects, Classes, and Constructors, Smalltalk Style
By Ramon Leon - 20 January 2007 under Ruby, Smalltalk
Objects, classes, and constructors are an interesting thing in Smalltalk. Coming from languages like C#, Visual Basic, or Java, one expects to be able to declare constructors in your classes. You also expect them to be "special" nameless methods that can only be called by the "new" keyword when creating instances of your class. Smalltalk is different, and better, or worse, depending on your point of view.
Smalltalk is a language that "allows" one to write great code. It never feels like it gets in your way, however many things in Smalltalk are done by convention only, so it won't "force" you to write great code.
Constructors in Smalltalk are simply a convention; the language has no "new" keyword. In Smalltalk, your classes themselves are objects, singletons in fact; they are the only instance of their metaclass. This might sound weird, so let's look at an example. Say we declare a Person class
Object subclass: #Person
instanceVariableNames: 'firstName lastName'
category: 'OnSmalltalk'
First, notice that this is simply a method call on the object class (there is no special syntax for creating classes), which itself is an object. This creates two classes in the runtime image, one called "Person", and one called "Person class". The class "Person" is the sole instance of the class "Person class". "Person class" is an instance of the class "Metaclass".
So in Smalltalk for every class you create, an invisible parallel hierarchy of meta-classes is created. These meta-classes are referred to as the "class side" by Smalltalkers, and by the Smalltalk code browser.
The reason I mention all this is because these meta-classes commonly show up in other languages as the "Factory" pattern, a pattern all about object construction. This is important because it's a great way to conceptualize the metaclass, it's the factory for creating instances of the class. To create an instance of our #Person, we do this...
person := Person new.
Notice, #new is a method on the "Person" class, rather than a keyword in the language. It's simply an ordinary method that happens to be named #new. Unlike other languages, constructors in Smalltalk are nothing special, they're simply any method that happens to create and return an instance of a class. Now, we could do this...
person := (Person new)
firstName: 'Ramon';
lastName: 'Leon';
yourself.
But a constructor would really help pretty this up and encapsulate the knowledge about what fields are required for construction rather than forcing the client to individually initialize the object and hoping he does it correctly. So let's write a constructor for #Person, we'll put it on the "Person class", or the Person's class side as it'd normally be called.
Person class>>firstName: aFirstName lastName: aLastName
^(self new)
firstName: aFirstName ;
lastName: aLastName;
yourself.
Notice this is simply an ordinary method named #firstName:lastName on the Person's metaclass. It's pretty much the same pattern as before, but calls "self new", the default constructor inherited from its superclass. I can say self because this method is in the "Person class" It can be used like so...
person := Person firstName: 'Ramon' lastName: 'Leon'.
Much nicer now, a client no longer needs to know what arguments to initialize, he can simply call a constructor, more importantly, a named constructor, not an anonymous one like you'd see in most other languages. Consider the advantages of named constructors with an overly simplistic example (ignoring currency)...
someMoney := (Money dollars: 5) + (Money cents: 5).
Of course any real Smalltalk'er would do this by adding a few extension methods to a few Number classes and writing this instead...
someMoney := 5 dollars + 5 cents.
Also unlike "most" other languages, constructors, being ordinary methods in Smalltalk, can be inherited and overridden so subclasses need not redeclare the constructors of superclasses like C# and Java required.
Constructors are put into the method category "instance creation". Finding constructors for a class is a simple matter of looking at the class side of any class, and looking in this category. If you find a constructor you want to use, highlight it, and press alt+n to see a list of all senders of this method, i.e. instant sample code.
On the instance side of a class, I could, if necessary, override #initialize which is automatically called by the default #new constructor. This is useful when you want to initialize your instance variables on object creation rather than lazily. For example...
Person>>initialize
super initialize.
relatives := Set new.
Some Smalltalk'ers prefer to write their constructors in a different style, one that enforces encapsulation a bit more, by not allowing public setters for all the instance variables, like so...
Person class>>firstName: aFirstName lastName: aLastName
^(self new)
initializeFirstName: aFirstName lastName: aLastName;
yourself.
Person>>initializeFirstName: aFirstName lastName: aLastName
firstName := aFirstName.
lastName := aLastName.
relatives := Set new.
Personally, I don't prefer this style, because it feels a bit repetitive creating essentially two constructors to avoid having public setters for your instance variables. This style feels like the author doesn't trust me to not abuse the class, which doesn't to me, feel like the Smalltalk spirit. It is, however, in common use and you'll see plenty of both of these styles in other people's code.
Often, while growing a program, one will start without any constructors, doing inline cascaded initialization, and only after using the class a bit, will you refactor a few examples into cleaner code using constructors.
To conclude, I hope you'll notice from the sample code shown so far, everything is done using only objects, their instances, and their methods. There is no special syntax or keywords for creating classes or their constructors. In fact, there are only 6 reserved keywords in the entire Smalltalk language, self, super, nil, true, false, and thisContext. By comparison, Ruby has 38, Java has 52, C# about 76.
This should underline just how much more Smalltalk relies on pure OO and message passing rather than special language constructs. By being minimalist and only providing syntax for assignment, message passing, method return, and a few special literal notations for things like strings, arrays, numbers, and blocks, Smalltalk can be any language you want it to be. All of Smalltalk's control and iteration structures are implemented in the library, as ordinary objects with ordinary methods. There's simply no need for so many reserved words.
Smalltalk is not so much a language, as an extensible notation for creating languages. To rip off a famed martial artist, empty your mind, be formless, shapeless, like Smalltalk. If you put Smalltalk into a financial application, it becomes a custom finance language. You put Smalltalk into a shipping application, and it becomes a custom shipping language. Be Smalltalk my friend.
Oh, and to be fair, Smalltalk isn't the only language with this quality, but it's certainly my favorite. Languages that lack this quality, as far as I'm concerned, have no real future.
Comments (automatically disabled after 1 year)
What can I say, I write when the mood strikes.
I think you forgot thisContext as "keyword".
Oops, good catch, fixed.
"Smalltalk is not so much a language, as an extensible notation for creating languages. To rip off a famed martial artist, empty your mind, be formless, shapeless, like Smalltalk. If you put Smalltalk into a financial application, it becomes a custom finance language. You put Smalltalk into a shipping application, and it becomes a custom shipping language. Be Smalltalk my friend."
And this is exactly why Smalltalk has been and will continue to be rejected. No custom languages are needed, what is needed is a common one, and one which does its best to disallow creation of any "dialects" and to make everyone to write more or less (the more the better) the same way.
What it means, language that is needed has verbose syntax which clearly defines most common tasks like iteration or conditionals, compulsory declarations, static typing and explicit interfaces. This language does not have blocks, closures, macros or otherwise definable control structures in any way. This language should be mostly OO, but not OO-fascist, it should be usable in practice.
Java was close, but many things can be improved. Smalltalk is possibly one of the farthest to the best needed programming language.
One, Smalltalk hasn't been rejected, it's it quite wide use and has an active community.
Two, all popular mainstream languages continue year by year to grow closer to the feature set Smalltalk already provides. Ruby has gone mainstream, and to quote Kent Beck, "I always knew one day Smalltalk would replace Java. I just didn't know it would be called Ruby.". So Smalltalk is already being accepted by the mainstream, they just don't know it.
Three, you're absolutely wrong about "language that is needed has verbose syntax which clearly defines most common tasks like iteration or conditionals, compulsory declarations, static typing and explicit interfaces".
Those approaches are failing and lead to massively complex frameworks of accidental complexity, otherwise known as Java and .Net. To quote Alan Kay, "The real romance is out ahead and yet to come. The computer revolution hasn't started yet. Don't be misled by the enormous flow of money into bad defacto standards for unsophisticated buyers using poor adaptations of incomplete ideas."
Java and .Net are popular because massive amounts of money and marketing have been pumped into them by tool vendors who profit from the complexity those languages create, not because they're simpler, or better. Lisp, Scheme, Python, Ruby, and Smalltalk are all better than Java and .Net, and all lack those features you find so necessary.
Dynamic typing (or type inference) "is" the future, not manifest static typing with explicit interfaces. Java, and it's clones, are big heaping piles of crap, well supported popular crap, but crap none the less. They aren't the future, they're simply an accident of history.
"Smalltalk hasn't been rejected, it's it quite wide use and has an active community."
Smalltalk, along with lisp, have been loudly and explicitly rejected over 15 years ago. They have active communities, yes, it's just their use that stops where the real world starts.
"Ruby has gone mainstream"
Now, this is a good one, this joke. Ruby has never been mainstream, nor will it ever be. It had its five minutes of hype created by a misdesigned web development platform, but it is already dead.
You can't make a language or platform mainstream just by convincing Beck, Kay or Fowler. You also have to convince people who sign their contracts.
And not only them, I have yet to see e.g. Apache moving to Ruby, but they are to smart to commit such a suicide, Apache guys.
Every bit of evidence tells, that manifest typing, verbose syntax and compulsory declarations are king. Yes, it's more fun to code Lisp, and Smalltalk probably too, than Java, I admit it. But what really counts is the cost of long term program maintenance, and that's exactly where you need all those declarations, this verbosity. By using languages that do not have it, you're just asking for trouble.
Java may not be the future. All this "make Java more dynamic" crap that is being prepared for Java 7 release is really scary, but see, those "unsophisticated buyers", i.e. the enterprise are sticking to Java 1.4, they are even afraid of such things like annotations - and sure they're right.
Sorry, but I define rejected as not having an active community. A language doesn't need to be used by the masses to be considered successful. Smalltalk, Lisp, Python, Ruby, are all successful dynamic languages in use in the "real world" and all have active communities.
If you think Ruby on Rails hasn't gone mainstream, or is dead, you aren't paying attention, or you've got your mind already made up and simply refuse to acknowledge reality. Yea, it's a web platform, guess what, the web is becoming "the" platform, everywhere.
As for maintenance, static typing being more maintainable is an urban legend, it has no basis in reality. The enterprise, follows... they don't lead. They make safe decisions, not smart ones. The best work gets done in small companies, of smart people, who are then acquired by the enterprise, who frankly can't keep up any other way.
If you follow what's going on in the leading edge research for these "manifest" languages, you'll see that even Microsoft is exploring things like software factories and language workbenches, which are all, in the end, fancy ways of saying DSL's, which are what Lispers and Smalltalkers have been doing and saying for years.
The enterprise, is simply slowly but surely moving towards more dynamic and more flexible languages. They simply work better, and are more maintainable, more flexible, and allow things to be done with minimal effort.
Take a look at any Java or .Net config file, they're already full of home brew dynamic languages cloaked in the guise of xml, and are in wide use in the enterprise. Using real dynamic languages isn't far behind. The better static languages use type inference and do their best to look and feel like dynamic code. Static typing may not be dead, but its current popular incarnation, manifest static typing is certainly on the decline.
Albert, I can't imagine why on earth you're reading a Smalltalk blog. You've clearly rejected any different ways of thinking, so what do you hope to learn here?
Perhaps Ramon struck a nerve with his use of the word "dialect." Perhaps it'd help to think of people creating expressive libraries, rather than new dialects. Do you really think it's bad for programmers to write clear, expressive code?
When you do have a lot of syntax, you end up with something like Java. You end up getting shoehorned into ugly, bloated, inflexible "solutions."
What dynamic languages have shown us, Smalltalk in particular, is that there really isn't much syntax needed for programming. A good programming language is one which is stripped down to the essential elements. This lets us write code that makes sense, rather than patching together a bunch of workarounds.
Ramon: Rejected is, what is rejected by the payers, not by geeky hobbyists, full stop. And Smalltalk and Lisp are explicitly rejected. Yes, you can create a nice success story using Lisp or Smalltalk, but as soon as the enterprise buys you out, the inevitable comes: the rewrite in a maintainable language. Not smart language, not innovative, but yes, maintainable one. Think static, manifest typed, imperative OO (but not fascist OO) one.
As to mainfest typing more maintainable being an urban legend, please stop ignoring facts, they don't cease to exist anyway. All evidence shows that if you have no declaration of what type a variable is, you have to figure it out during code maintenance as soon as you step on it. So this alone is a real maintenance pain. But add to this another thing to figure out: not only actual type, but intended type (the actual used interface) and you're doomed without a declaration for any non-trivial object. Read Cedric Beust's "Perils of duck typing" and you'll know what I mean.
(And a Python maintenance horror story: someone has made a typo and written "none" where they should have written "None" - which later meant several hours of painful maintenance to find it... while a statically typed language where you declare everything would make it virtually impossible.)
Microsoft, they're trying to kill Java with lots and lots of features, crazy ones like lambdas or properties instead of explicit accessors. And know what? It is now clear that the more features they add, the further they are from their goal, killing Java. Too bad Java enters this nonsensical death race noone can win, but look at users, real users that pay the money for development: they are sticking to Java 1.4 and avoid even 1.5 (or 5.0 as Sun's marketing calls it) and for a good reason.
So make your smart decisions, when you run a startup, use Lisp or Smalltalk or whatever you want, you won't maintain it for a long time anyway - you'll go down bankrupt or get bought. And if you get bought, the business that buys you out will pay another money to rewrite your so brilliant code in a less brilliant way, in a less brilliant language, but that will save them another piles of money to spend within subsequent years.
Pat: no "flexibility" is ever needed, what is needed is the inflexibility, so people are forced to use a common language, which is always better than a "powerful" one. Python with their "there should be only one way to do it" could have a chance to become tomorrow's language, but they don't want to introduce static typing, so they've really given up.
People shouldn't be forced to do anything. The language should empower the programmer to express whatever ideas he needs. The "right way" of doing things emerges from use, it's not defined at the getgo. The power in flexible languages lies in making it easy and practical to create new abstractions. Recreating existing abstractions is an obvious misuse, regardless of implementation language.
Our understanding of programming is always changing. Java is a prime example of a language where the designers didn't understand this. Java gives you the right way to do things...but why then are there several design patterns books that work around the language? You might say that it's because the designers forgot something in the language itself, but the key deficiency is not realizing that you can never account for all future uses. Java makes the assumption that it's smarter than me, and you can bet I won't be wasting any time on something that stupid.
Languages shouldn't have an inflexible, correct way to do everything, precisely because there's never a correct way to do something. There's only a best way to do something most of the time at the present time. Any language that isn't designed with this in mind is doomed to endless workarounds or rewrites. Programming languages should evolve with our understanding.
Pat: Java is a good example where designers understood that allowing programmers to create new abstractions creates way more problems than it solves (if it ever solves anything). Look just at Lisp and iteration: you have do and do* which are completely unintelligible, you have loop which was designed to be easily readable, yet grown to a horror its creators don't even understand and now you have iterate which aims at easing pains loop creates but hardly anyone uses it. Lispers are so proud of this ability to define even such basic things like iterations, yet they are themselves the most stunning evidence of why this is a complete failure.
Languages, to be successful have to force their users into a certain way of doing everything, the more they force, the better. And they must force programmer to give every piece of information they have, not for the compiler but for people who will read and maintain this code later. (Python took the first lesson very good, but not the second and they are no success. Manifest static typing and declarations for everything are a must.) I agree, this will not be the perfect, the rightest way of doing most things but it will be very good for most common tasks and quite so for the uncommon.
Yes, it will make design patterns necessary, but this is better to say and hear that we will use the Strategy pattern for example than having to cope with "perfect solution for the problem" which hardly anyone understands or can make any use of. If you don't take this lesson you'll get Lisp or Smalltalk which means a "powerful" language every programmer, so wise as to know that there are others to come to his code, will avoid at all costs.
Albert, you clearly think Java is the right direction, so more power to you. I however, think that thinking like yours is what's wrong with this industry and needs to be changed.
"allowing programmers to create new abstractions creates way more problems than it solves "
I mean WOW, just WOW, I don't even know how to respond to that, seriously, programming "IS" the art of making abstractions. Languages should help the programmer, not hinder him. You're simply wrong and it's clear nothing we say could change you mind on that.
And forcing the programmer to give every piece of information they have, are you kidding? Most of the time, manifest types force the programmer to LIE, and make up shit he doesn't even know to be true yet. Manifest types are a must not, period!
Manifest types prevent quality programming and perfectly valid programs. Try doing a simple dynamic proxy or decorator in Smalltalk, now try doing them in Java, nuff said.
Thinking like yours, will be replaced by attrition rather than argument, as the younger generation comes in and simply replaces you.
"...the inevitable comes: the rewrite in a maintainable language"
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 ;) !]
Isaac, we've been through this already. Yes, the control structures are implemented in the library. Yes, some of them have become so standard that they are optimized by the VM and can be thought of as built into the languages.
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.
"The debugger lies!"
:(, 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.
The truth isn't inconvenient, just argumentative people.
"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.
Ramon, you are making up. What real programming is about is not creating abstractions, but using them. Look at Java - there are some abstractions built in, like classes or methods, or loops and you can use them but it is difficult or impossible to define your own. For example it was hard to define an abstraction to iterate over a collection, and though it was possible, the defined abstraction would have more code than a standard for loop, so everyone was using for. It was one of Java's shortcomings until it was built into the language, but with Java 1.4 it is explicit creation of an Iterator and using it in a loop. Now what would happen if Java made it easy and straightforward to create such abstractions? You'd have zillions of foreach loops, similar but different. One would break on exception, one would ignore it and continue, one would allow modifications of the underlying collection and one would not. And so on. Add possible bugs in many implementations of such foreach loops, and you have, well, lisp in 1980 :) And we still have static typing, if we were to give it up, we also have to count different behaviors when such a loop is asked to iterate over a non-collection. So now we really can have zillions of such utilities and explain how it helps maintenance.
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! :-))))
Albert, yes I read the article. It's clear that you think manifest static typing solves problems for you, and that's great, but in my code, and any dynamic language code for that matter, it's been said over and over again, type errors are just not the problems we run into in code. You're afraid of a boogey man that doesn't really exist.
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.
Ramon: You read the article yet you have no other comment other than "It is trivially fixed"? Yet I ask, come and show how it is trivially fixed when it is unfixable without explicit interfaces. You can't fix it just because the method which is needed (this onPause one) might not be yet used in the version of the library you have, so without explicit interface which tells you this is needed you'll never know. So, this library upgrade, which will make onPause needed in Smalltalk is a major incompatible upgrade just because there was no way to tell users that this will be used. In Java, in contrary the interface could have declared the method, so users would have to provide it and when it's actually used it is just a minor upgrade because everything is in place. Another win for explicit interfaces.
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.
Re squeak, I don't know it, but wasn't it a compiler with some standard library? But what I write about is about some really big project (I doubt any is written in Smalltalk, though) where programmers are allowed to define such constructs as they see fit.
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?
(Sorry for this late injection. I stopped reading at Albert's post from January 22, 2007, 12:19 am. So, if this duplicates what was said later on, then my apologies.)
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.
Albert, what can I say, you "static" guys are scared to death of a runtime error, and you'll trade away the most powerful techniques in programming, just to "feel" safe that you won't get a runtime error.
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.
Isaac, my apologies, seems you are correct, I cannot step into #ifTrue: even in Squeak. My memory was faulty, I thought I had done this before, obviously, I couldn't have. I'll test before opening my mouth next time. ;)
Yes, though not in its current form, Squeak is descended from Smalltalk-80, as is Visual Works. Though they've both evolved down different evolutionary paths, they're still from the original Smalltalk line and both have tons of code that's been in the image from the beginning.
Isaac, I looked around, seems you're a bit of a known troll. I've put you on moderation until you learn to behave and stop endlessly asking argumentative questions.
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.
To A. Bulawa:
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 (tm) 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)
Here here! we need to get rid of this myth that "average" people should be able to program.
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.
"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." I find this is an advantage...
"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 optimizations 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)... :)
Charles, Ramon: Yes, there were some neat success stories of Smalltalk or Lisp companies, it's true. But it is also true that you Smalltalkers and Lispers take those stories and use them like queen's diamons - and for a reason: there are only so few. If I was to look out for a Java success story people would think I'm crazy, just as if I was to look out for trees in the middle of a forest.
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
Albert, let's just agree to disagree, because honestly, I simply think you're wrong.
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: I just read and see but insults. I elect to ignore your "bondage and discipline" and "pessimism and optimism" parts, but you said another thing as if you were the pope speaking ex cathedra, yet this is simply false.
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...)
"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."
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?
Ramon: Companies should invest not in tools or languages, but, above all, in uniformity, yes a moving uniformity but still. And yes, they have to mandate the rules, and it is not possible that everyone loves all the rules the company mandates but it is a must that everyone accept them or go away. Rules are not carved in stone, they may change - but this change must be under control, and may not happen because someone doesn't like some rules, or soon you will have no rules at all. So rules that are decided to have no sense are removed and others are added (e.g. once we decided that every class we create must implement an interface and that this interface, not the class is to be used in formal method parameters or variable declarations - but it was soon found that we've gone too far and this restriction has to be lifted for exception classes, so it was), but it's still decided at least project wide if not company wide.
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?
I think company wide uniformity is a bad idea. Project wide uniformity, yes, company wide, no way. Maybe it comes from my experiences as a contractor, but I think each project should take what worked best from the last, and ditch the rest, continually evolving standards as new tools are found, learned, or written.
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. ;)
[...] Objects, Classes and Constructors, Smalltalk Style [...]
Yikes what a long tiring discussion! :)
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!
Thanks, been too busy to post much lately, but I will keep it up.
albert, i disagree with your assessments.
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...
The Minimalist OO Programming Language
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,
Ramon,
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
Don't know what happened to Albert, but I'm glad you enjoy the blog.
[...] Does it suddenly make a bit of sense why the first member of the xUnit family was, in fact sUnit? My question for the Smalltalk crew is this: before you had sUnit, how the heck did any of you keep your jobs? The production deployment problems must have been Hindenburg-spectacular. I’m just kidding. Actually, it turns out, the Smalltalkers had other tricks up their sleeves to avoid runtime disaster. [...]
Three articles in four days...