Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

ziggy (25)

ziggy
  (email not shown publicly)
AOL IM: ziggyatpanix (Add Buddy, Send Message)

Journal of ziggy (25)

Thursday September 16, 2004
11:06 PM

On Learning Smalltalk

[ #20911 ]
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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • ziggy++
    Terrific summary, thanks.
  • 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 [perl.org], a bit in Scheme [perl.org], and have a whole host of other languages that I've programme

    • 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. :)

    --
    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
    • 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. :-)
    • 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.

      Actually, it's not a simple cause-and-effect relationship.

      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 de