Hm. The Smalltalk thread continues. Thankfully, it hasn't degenerated into a flame war.
Ovid says in a comment:
In fact, the only reason SmallTalk really interests me right now is the "pure" OO model that I keep hearing people talk about. However, I'm brushing up on my Java because that's where the bulk of the work is. Until I hear convincing arguments about how SmallTalk can improve my professional life, I'll probably just wonder about it. I have a pretty active social life, so I don't have as much time for research as I would like.Ovid, let me tell you without reservation, learning smalltalk will improve your professional life. Here's why.
First of all, in The Pragmatic Programmer, the authors recommend learning a new programming language every year, just to stay sharp. Ideally, you would learn the syntax, the programming model, write a few beginner programs and finish a non-trivial application. Find out how it feels under your fingers. Get exposed to some new ideas. See which ideas look good but really chafe, and which ideas look bad but work quite well in practice. Your goal isn't to beef up your resume, but to learn and adapt.
Realistically, doing all that work is time consuming. I've been doing my best to follow the intent of this dictum, and I try to read about one text per year on a language I do not use, or haven't used in years. Once you've done the grand tour of programming (procedural, recursion and functional, OOP, and declarative programming), it should be easy to pick up some of the basic insights a new language brings. It may take weeks or months for the ideas to fully sink in, but in time they will. You'll start looking at your code differently, and start seeing better ways to write in the language of your choice that make your programs more robust and less tedious to write.
Yes, this is the Evelyn Wood School of Learning a Programming Language. That's OK. You'll learn something, and there's nothing preventing you from going back over a text, like SICP, a second or third time. Or taking an opportunity to write a little app with Rails instead of Mason.
That aside, the second key point: if you are going to try and learn a new language to broaden your horizons, pick something different. Most programming languages out there today inherit something from the big Ur-language known as ALGOL. If you've learned one ALGOL derivative, you've learned most of them. So, for example, if you already know C, spending time on Pascal isn't a great investment. Better spend your time on something very different or unique, like a Lisp, Smalltalk, Forth (including PostScript), Self, *ML, Haskell or Prolog. There are many more ideas to mine there than there are in the language next door.
Third, with all of the programming languages out in the world today, there are very few great languages -- stuff that lasts for decades. Many of those great languages are sui generis, like Lisp/Scheme, Smalltalk and Forth. These languages are a programmer's Latin, Greek, and Aramaic. Many of the ideas that come into Objective-C, Java, Ruby and Tcl can trace their origins back here. If you want to learn a new language, focus here before you kick the tires on something newer like Python, PHP, Tcl or Ruby.
Fourth, why Smalltalk? Even if you don't fire up an image, the whole model behind the language is wonderfully elegant. Sure, there are warts in there (like the lack of an if statement), but every language has warts. Get over it. Look for the deeper values like Collections, blocks and metaclasses. Stare at it long enough, and you'll wonder why any method in an object oriented system needs more than ~ten lines of code. And the whole thing will be much easier to understand than you ever thought it could be.
One last note. On the local XP list, someone mentioned cyclomatic complexity as a means to identify complex code in a project that needed to be refactored. However, in an object oriented project, cyclomatic complexity doesn't work, so someone offered lines per method as a suitable replacement. If most of your code is hovering around the 10 lines/method, you know methods that are 50+ lines long desperately need refactoring.
This metric and the associated style of development come from Smalltalk. Had I been stuck in a rut writing 500-line Windows event handlers in C (with case statements -- YUCK!), that suggestion would have floated over my head. As it stands, I'm using that style to guide me in refactoring procedural code into object oriented code at work right now. I'm moving Tcl code into XOTcl, but it doesn't matter -- I'm programming as if I were building a system in Smalltalk, and the new system is much better for it. The codebase could just as easily be in Perl or Java, but the approach remains the same.
Learn Smalltalk. I assure you, it will improve your coding life, even if you never manage to use it professionally.
Sure, there are warts in there (like the lack of an if statement)...
That alone makes me interested. I can't tell you how many times I've stared at if {...} else {...} statements in code that are better handled via polymorphism or dispatch tables but I don't have the time to refactor them.
As for learning a new language, I suppose you're right and I should give it a try. So far, I've done a fair amount of dabbling in Prolog, a bit in Scheme, and have a whole host of other languages that I've programmed in (Java, C, COBOL, Easytrieve, Focus, 6809 assembler, etc.) I think all of these languages have benefitted me, if only to teach me what not to do -- COBOL being a prime example.
As for why I've never dived (dove?) into Smalltalk, I can't say. There's much about it that appeals to me. Maybe it's the "tuits" thing. Yeah, that's it.
Re:No "if" statement?
zatoichi on 2004-09-17T21:29:04
I love its simplicity in this:
ifTrue: [ doSomething ]
ifFalse: [ doSomething ]Using it like this:
(3 < 5) ifTrue: [ Transcript cr; show: 'It is true.'. ]
ifFalse:[ Transcript cr; show: 'It is false.'. ]Cincom has a non-commercial version that you can get. I am *learning* it next.
So if I read you right, learning Smalltalk will make me write smaller (by LOC) methods? That's a goal I'd like to achieve, so maybe I'll learn it.
Oh, and Forth is Postscript? Thanks; I didn't realize. I thought it was just open firmware.
Re:Small methods
Aristotle on 2004-09-18T07:07:55
Forth is not Postscript. Postscript is like Forth, except it has some "list as first class objects" ideas thrown in. It's a strange world, foreign, difficult, but also exotic and occasionally very beautiful.:-) Re:Small methods
ziggy on 2004-09-18T18:54:12
Actually, it's not a simple cause-and-effect relationship.So if I read you right, learning Smalltalk will make me write smaller (by LOC) methods? That's a goal I'd like to achieve, so maybe I'll learn it.Learning how to write smaller methods is a result of learning how to write good abstractions. If you get a good Smalltalk text written by someone who really understands the principles of writing good abstractions, then you should be able to see what good code looks like, and hopefully absorb good design. Thankfully, most material written about Smalltalk is written by people who have a better-than-average ability to write good abstractions.
But you don't need Smalltalk for that. You could learn how to write good abstractions from reading SICP and perhaps watching the lectures. Or any other good text for that matter, regardless of language. (If I knew a good Haskell, O'Caml or Ruby text with the same bias, I'd heartily recommend them as well.)
So, basically, writing good abstractions is something that people at the top of the bell curve do well. These people also tend to use (and often create) programming language that make it easier to write good abstractions.
I like to joke about Forth, because Forth is so esoteric, overlooked and unappreciated. But one of the best things about Forth is that it forces you to write good abstractions. The penalty of writing bad abstractions is pretty severe, and is easily the difference between a program that works, and a program that will never work.
