Talk Like A Duck

How Did You Get Started in Programming

Posted by Rick DeNatale Sun, 08 Jun 2008 03:14:00 GMT

Joe O’Brien wrote an article about How he got started in programming.According to Joe, this is a meme started by Michael Eaton, and Sarah Dutkiewicz. It seemed like fun, so here’s my story, in the same form used by Michael and Sarah.

How old were you when you started programming?

I would have been 18 or 19. It was my freshman year in college (1970/71), but I can’t recall whether it was first or second semester, and my birthday is in December.

How did you get started in programming?

Let me go back just a little bit. When I was in high school, I was very interested in music. I’d played in various rock and blues bands since junior high. My high school in Connecticut was part of a program which taught electronic music. This was a time when synthesizers were just coming to the fore. Walter (now Wendy) Carlos’ album “Switched on Bach” had come out in 1968 when I was a high-school sophomore.

So I started at the University of Connecticut in the fall of 1970 and enrolled in the Electrical Engineering School, with the sole intention of becoming the next Robert Moog. All I really wanted to learn was how to design voltage-controlled oscilators and amplifiers.

One of the courses which all freshman engineers at UConn had to take was a 100 level CE course which consisted of one-half semester of “Engineering Graphics” i.e drafting on a board with a T-Square, Triangles and French-curves, and one-half semester of Fortran I programming on an IBM 1620.

That course got me hooked on programming, and my musical career ended in a hurry.

What was your first language?

As I mentioned it was Fortran I, but I quickly became one of those guys who wanted to dabble with every programming language I could get my hands on.

What was the first real program you wrote?

It’s been so long that I can’t really remember. One of the things I remember from school was writing a compiler as a class project. I also remember a computer architecture (hardware) course, taught by grad student with a recent math MS, who I baffled by designing a computer for the term project which had a very simple hardware design, because it was micro-programmed so the main part of the design was actually firmware. The poor guy didn’t really know what to make of it.

What languages have you used since you started programming?

This is probably not a complete list but:

• PL/I
• Snobol
• Lisp 1.5
• Formac
• 1620 Assembler Language
• PDP 8/5 Assembler Language
• IBM System/360/370 Assembler Language
• APL
• PL/S – an IBM internal mid-level language akin to C but with a PL/I like syntax, and a later variant PL/AS
• Basic – on the APPLE ][
• UCSD Pascal
• C
• Class-C, an object oriented C variant similar to Objective-C which I invented for use within IBM
• Object Pascal (using MacApp)
• C++ (as little as possible)
• Smalltalk – my first real love
• Java – mostly because I had no choice
• Ruby – my current love
• JavaScript – which I’ve decided is my language of the year for 2008.

If you knew then what you know now, would you have started programming?

Only because I can’t figure out how to become a real Rock Star.

If there is one thing you learned along the way that you would tell new developers, what would it be?

Try to get a broad a picture as possible of programming, try to use your knowledge of other languages enhance your learning of new ones instead of inhibiting yourself by misunderstanding how the languages differ from the ones you’ve already used,

What’s the most fun you’ve ever had … programming?

The most enjoyable aspects of programming are the social ones. I was doing pair programming before anyone had coined the term. I remember sessions where two or three guys were working on something, one working the keyboard, one the mouse, and maybe a third kibitzing. Beyond that it’s great to hang out with other programmers whether at local groups or at a conference like OOPSLA or RubyConf and talk about the craft of programming, maybe over a beer or two.

Posted in war_stories | no comments | no trackbacks

What Would You Miss If You Had To Stop Using Ruby and Go Back to Smalltalk?

Posted by Rick DeNatale Wed, 21 May 2008 20:58:00 GMT

Last night, James Robertson from Cincom, presented Smalltalk and Seaside to the Raleigh Ruby Brigade.

It was an interesting deja-vu experience, since in my younger days, part of my job with IBM was evangelizing Smalltalk, much as James does today. It was interesting to see what has and hasn’t changed. For the most part the things about Smalltalk which were blessings and curses (or many times both) haven’t changed. The IDE is still powerful. It gets much of it’s power from Smalltalk’s model of how source code and run-time implementation objects like compiled-methods, classes and metaclasses interact, but the consequence is that there aren’t really Smalltalk source files to use with popular editors like VIM or EMACS or Textmate. The question came up about whether the Smalltalk IDE supported the notion of giving the code to an external editor, and the answer was that the size of a typical Smalltalk method, which is the unit of editing, was so small (10 lines is a long Smalltalk method) as to make it ‘moot.’ I used to get the same kind of questions and give pretty much the same answers.

One area where Smalltalk really does excel is in it’s debugging and inspection tools. The same implementation object model which enables browser features, like finding all senders or implementers of a message using structural rather than textual searching, also allows live debugging, where you can not only inspect the run-time state at a breakpoint, or when an exception occurs, but actually make changes to the running code, and compile those changes, at which point the VM prunes the invocation stack down to the point of the change and allows you to restart from that point. Protestations from TDD/BDD adherents that you don’t need no steenking debugger if you follow TDD practice, the Smalltalk debugger was tool much favored by the very people, like Kent Beck, who invented TDD. Many Rubyists who were around for more than a year or two had an anti-debugger attitude, generated more, I suspect, by the lack of a decent Ruby debugger than any real hatred of debuggers.

Now that ruby-debug has been around for almost two years, the situation is much better. Ruby has a fairly competent debugger which allows stepping through code. It’s still hampered by Ruby’s rather simple run-time meta information, being forced to work on a line-by-line mode, rather than being able to step through individual expressions as can the Smalltalk debugger. And we’re still a long way from the live surgery capabilities I described. Perhaps as Ruby VM implementations mature we might see some of these advanced features emerge, perhaps this is something which the Rubinius implementers might also take as an inspiration from Smalltalk. This is one of the main things I miss from my Smalltalk days.

On the other hand, at this point in time, I’m really much happier working in Ruby than I think I would be were I somehow forced to work in Smalltalk again instead. Much as I love it, Smalltalk is now my second favorite language.

At one point last night, Brian Adkins asked me the question which is the title of this article. I think it’s a fair question, and I’m not sure I know exactly, but let me try to answer it.

What I’d miss from Ruby

I’ve said this before, but one of the things I like about Ruby is that it is more dynamic than Smalltalk in ways which I like, and cuts back on other aspects of Smalltalk which I don’t think are really that important.

One of the things I like about Ruby is the elimination of variable declarations. A good example of this was that during the Seaside demo last night, James showed how interfacing to the database requires attribute instance variables in model objects to be declared. Now the IDE provides tools for helping with this, you get prompted with a list of column names and can add them one by one just by clicking buttons. Contrast this with ActiveRecord where model objects just acquire instance variables dynamically at run-time. Now I know that some prefer more explicit mappings, but personally I feel that the dynamic mapping provides much more capability for much less ceremony.

The ways in which Ruby is more dynamic than Smalltalk seem to me to provide better facilities for building low-ceremony architectures and artifacts like Rails, Rake, etc. There are more dynamic languages than Ruby to be sure, such as Self, and from what I can sense JavaScript, but Ruby seems to strike a very nice balance.

Much has been made of the legacy of Smalltalk in pioneering metaprogramming, although some Lisp guys might quibble with that, and in truth, most Smalltalk metaprogramming was only used to support the IDE and never put to use by application programmers. Alan Kay used to say that he was disappointed that no one seemed to make new classes of Behavior (which is the superclass of both Class and Metaclass in Smalltalk). I know he said this to some of us at an IBM internal conference, which at least led to Dave Smith and Jerry Archbald developing a “behavior of behavior” tutorial which ran for several years at OOPSLA. But Rubyists have taken metaprogramming much further than I recall from my Smalltalk days.

On the other end of the scale, Smalltalk as James pointed out, as I used to, has a very simple syntax, a few reserved words (self, super, nil, true, and false), three types of messages (unary, binary, and keyword), two operators (:= for assignment, and ^ for return), and a few more things for defining block literals.

Now when I was doing James’ job, this got mixed reactions. Some people took to syntax like:

topLeft = Point x: 3+2*5 y: 15

While others found it just a little too strange, something which we Smalltalkers just couldn’t get.

Another thing which put off newcomers to Smalltalk was that, because of the simplicity of the language, and the lack of any form of operator precedence (remember the only operators are := and ^), that subexpression 3+2*5 evaluates to 25 and not 13.

Ruby trades off a little simplicity and does provide precedence between messages which seem like they should act as operators.

I’m not saying that Ruby is without quirks, just that different people react to different quirks in different ways. If you don’t like what you perceive to be the quirks of any programming language, you won’t be convinced, even by the most ardent supporter of those quirks.

One of the interesting effects of the Smalltalk syntax was that, as we observed back in Smalltalk’s heyday in the Enterprise (late ‘80s-early ‘90s), it seemed that a lot of COBOL programmers seemed to take to Smalltalk. We used to think that Smalltalk might actually become the 21st century COBOL, until the “Enterprise” got wooed away by EJBs and the like. The same things which made Smalltalk approachable by COBOL programmers made it seem weird to those who looked down on those COBOL programmers as “trade-school” programmers.

Another much-touted feature of Smalltalk, is that everything is done by message sending, even control flow. In Smalltalk a if/then/else control flow is achieved by sending an ifTrue:ifFalse: message to a boolean object as in:

 ^(x = 0) ifTrue:[a] ifFalse:[b]

Smalltalk evaluates this as if the the expression (x = 0) is evaluated by sending the message with the selector = and argument 0, to the object referenced by x. The result of that message, an object of course, is then sent the message with the selector ifTrue:ifFalse: and the arguments [a] and [b], which are two blocks. What happens is up to that object. Typically that object is either true (the sole instance of the class True) whose ifTrue:ifFalse: method evaluates the first argument, or false (the sole instance of the class False) whose ifTrue:ifFalse: method evaluates the second argument. Very neat and conceptually clean. It allows you to define your own control flow methods.

Ruby on the other hand compiles if statements and their kind as tests and branches, much as a C compiler would. We trade off a little flexibility for performance.

But, in my experience, that flexibility rarely got used in Smalltalk. Not only that but, in my day at least, the Smalltalk compilers would also compile ifTrue:ifFalse: to a test of the result of the ‘receiver’ and a branch. In fact I just tried defining a FakeBoolean class with an ifTrue: method and when I try to use it I see this:

That NonBooleanReceiver exception is like seeing the Wizard of Oz behind the curtain, this notion of no control flow, just messages is actually a bit of an illusion.

Again, while Ruby doesn’t even pretend to implement all control flow by messaging, it provides most of what the underlying Smalltalk mechanisms are really used for in the form of blocks used to implement iterators.

There are other aspects of Smalltalk which are both blessings and curses. The fact that Smalltalk has a persistent run-time image, containing all the development tools, which can be saved along with its state of execution, and restarted is quite powerful, alien to many programmers, and can drastically change your approach to deployment. Back when I was doing Smalltalk we always struggled with issues like the footprint of the image, how to strip out the development tools before deployment, and start-up time. Some of these problems might seem to be less severe with today’s hardware, but they are still issues.

I feel that I might be coming across a little too harshly on my old friend Smalltalk. It still provides a great programming environment, and serves as a source of inspiration which shouldn’t be overlooked, and I hope to see some of the powerful development tool features from Smalltalk appear with help from support in some of the emerging Ruby implementations. I’m glad to see that it seems to be making somewhat of a resurgence, along with dynamic languages in general. But for me right now, while I wouldn’t be unhappy if I had to go back to Smalltalk, but I feel happier with Ruby.

Posted in ruby, war_stories, smalltalk | Tags debugging, seaside | 5 comments | no trackbacks

Cool, but Stupid, Things I've Done

Posted by Rick DeNatale Sat, 17 Nov 2007 11:18:00 GMT

Cones
© Eric Castro

Many of these things can be cool.

And many of them, particularly in retrospect, can be less than brilliant.

Here are two of the more visible cool, but stupid things I've done in the past.

Posted in war_stories, smalltalk | Tags smalltalkdistributed, stupidity, visualage | 1 comment | no trackbacks

To paraphrase Kent Beck...

Posted by Rick DeNatale Sun, 02 Sep 2007 21:35:00 GMT

I’m catching up on my RSS feeds this afternoon, and I just ran across the latest from John Lam. Which exposed an interesting coincidence.

Oh yes, Merlin is the original code-name for our team, which was originally IronPython but has now expanded to include the Dynamic Language Runtime and IronRuby.
- John Lam

The codename for IBM’s original VisualAge project was “Camelot.” Various subcomponents and follow-ons were dubbed with various names from Arthurian legend. For example, there were components with names like “Lancelot” and “Guinivere.”

Sometime after the initial success of VisualAge, it was decided that IBM would actually produce a separate Smalltalk language and IDE packaging, a product which was originally named “IBM Smalltalk” at launch.

But during development IBM Smalltalk had Arthur’s wizard as its namesake. As usual there were tee shirts, and this article starts with a picture I just took of my copy of the IBM Merlin Tee, which my wife still uses as an exercise tee. And in case you can’t read them, the words in the crystal ball read “think BIG/TALK small” a combined reference to IBM, Smalltalk, and I suppose, Teddy Roosevelt. Now old Merlin might look more like a Swami than the wizard of Camelot, but here’s the proof from the front of the shirt:

So to paraphrase my old buddy Kent Beck, I knew that Microsoft was trying to implement Ruby, but I didn’t know it would be called Merlin!

Posted in ruby, war_stories, smalltalk | Tags ibmsmalltalk, ironruby | no comments | no trackbacks

Nobody Could Count Beans Like IBM

Posted by Rick DeNatale Sun, 02 Sep 2007 20:52:00 GMT

In my thirty-two year career at IBM, I can’t begin to count how many times I was bothered by the IBM software development process.

When I started, in 1974, I found myself trying to swim under the waterfall. Everything hinged on “Requirements Documents,” “Initial Functional Specs,” “Design Reviews,” etc. Managers were constantly wanting line of code estimates. Far more effort was wasted on process rather than progress. Sometimes the process overhead was fatal. My first project at IBM was part of IBMs major initiative in the 1970s to replace the IBM/370 with a new system called “FS”. One of my heroes at the time was John Sowa who worked in the architecture department and whose role seemed to be the resident iconoclast. In one of his memorable memos available on his web site, John made the observation that the system architecture specification comprised fifteen registered IBM confidential documents, each with an individual need to know. A fact which effectively prevented anyone in the company from understanding the system and its problems.

So, it should be no surprise that I came to an appreciation of what are now called agile methods, early on in my career, and fought for the processes and technologies which enable agility inside IBM, and evangelized such approaches to IBM customers.

Fred George was one of my allies during part of this struggle. Fred was a middle-level IBM manager who came to the IBM lab in Cary, NC about the time we started using Smalltalk, and I was developing a prototype application development tool which morphed into VisualAge. I worked in Fred’s organization and claim influencing him on dynamic OO technology, and agile methods.

Fred now works for ThoughtWorks, and blogs about agile methods. Recently he has been writing about how to push back against bean-counting. I get the sense that Fred shared many of my frustrations with the old IBM process.

Posted in war_stories | Tags agility, IBM | no comments | no trackbacks

After the Hoedown is Over, Part 1

Posted by Rick DeNatale Tue, 14 Aug 2007 15:03:00 GMT

The first Ruby Hoedown, sponsored by the Raleigh Ruby brigade, has finally come and gone. I had a great two days, saw some old friends, and made lots of new ones.

Here are my initial thoughts after more than a bit too litle sleep after a night trying to root out werewolves.

Posted in ruby, war_stories, smalltalk, rails | Tags history, rubyhoedown | no comments | no trackbacks

The other Dave Thomas and the Birth of the Agile Alliance

Posted by Rick DeNatale Mon, 09 Jul 2007 17:17:00 GMT

“Uncle Bob” Martin of Object Mentor just published an article containing his personal recollection of how the

... Dave Thomas of OTI fame. (We call him “Big Dave” to differentiate him from the Pragmatic Programmer of the same name.)

He gives a bit more background than has previously been told. Of particular interest to me is the role of “Big Dave” Thomas, the founder of OTI in kick-starting the organization.

I’m proud of my experiences working with and for “Big Dave” and to count him as a friend.

Posted in war_stories | Tags agilealliance, davethomas, oti | 1 comment | no trackbacks

Punch Card Tales

Posted by Rick DeNatale Wed, 27 Jun 2007 21:02:00 GMT

For some reason, talk on ruby-talk brought up old computer stories. David Black related a story told him by a former boss about a “photo op” in a company computer center triggering failures when the photographers’ flashes upset the optical sensors in the tape drives.

Since I’m sitting in a hospital cafeteria this afternoon waiting to see my wife who just had some surgery. I figured I might amuse myself, and hopefully you gentle reader with some old mainframe war stories.

Posted in war_stories, humor | no comments | no trackbacks

Good News

Posted by Rick DeNatale Fri, 22 Jun 2007 14:29:00 GMT

Prior to making the final decision to go all out with ruby for their front-end launch, the did some due diligence which included investigating the facts behind the recent furore caused by an interview with one of Twitter’s developers.

So they went to Twitter’s lead developer, Blaine Cook to get the straight dope.

Quoting Kevin:

The simple fact is that Ruby wasn’t the source of Twitter’s woes. As it often happens with rapidly growing sites, they ran into architectural problems. Some design decisions don’t hurt until they reach a massive scale and at that point you have to rethink your approach. In an email he writes:

For us, it’s really about scaling horizontally – to that end, Rails and Ruby haven’t been stumbling blocks, compared to any other language or framework. The performance boosts associated with a “faster” language would give us a 10-20% improvement, but thanks to architectural changes that Ruby and Rails happily accommodated, Twitter is 10000% faster than it was in January

That last sounds quite true and corresponds to my experiences in the past with Smalltalk. I used to tell IBM customers that almost all performance comes not from the language but from application design, and that using a dynamic language which allowed the application to be developed in what’s now called an agile development process allows major performance gains through refining, refactoring, and retuning the system as both business and performance requirements get uncovered/discovered.

That’s as least as true of Ruby as it was of Smalltalk 15-20 years ago.

Posted in ruby, war_stories, best_practices | Tags evangelism, performance, rails | no comments | no trackbacks

Another Take on Design Patterns

Posted by Rick DeNatale Tue, 19 Jun 2007 20:48:00 GMT

Most programmers these days are familiar with, or at least aware of the now classic “Gang of Four” book Design Patterns: Elements of Reusable Object-Oriented Software.

One of the recurring arguments about design patterns is how they relate to individual programming languages. The “Gang of Four,” Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, were by majority, proponents of strongly typed languages. Ralph was the sole representative of Smalltalk and the rest of the dynamic object oriented languages. As a result, The GOF book had and has more resonance with the C++ community and it’s successors. Although there are some Smalltalk examples in the book, many of the patterns express things which are easier, and in some cases unnecessary to express in a dynamically typed language. I find this a bit ironic, since the whole patterns movement seems to have started when Ward Cunningham and Kent Beck, two of the best known Smalltalkers, discovered the work of architect Christopher Alexander and thought that his approach to building and municipal design could be translated to the design of software.

As I was browsing today, I was reminded that there is another “Design Patterns” book, “The Design Patterns Smalltalk Companion” by Sherman Alpert, Bobby Woolf, and Kyle Brown. Which might be of interest to not just Smalltalkers but also Rubyists, since it approaches the subject from they dynamic language point of view. It’s not easy to find, but Amazon has a few copies in stock.

Sherm was one of the researchers in the IBM User Interface Institute which was housed in the same building where John Vlissides and Richard Helm of the “GOF” worked, the IBM Watson Research center in Yorktown Heights, NY. I spent quite a bit of time with Sherman and the rest of the UI institute team under John T. Richards back in the late-1980s to early 1990s. Bobby and Kyle were OO consultants, who I also knew through Knowledge Systems Corp.

You never know what you might learn from the old Smalltalkers.

Posted in war_stories, smalltalk, best_practices | Tags books, design_patterns, gang_of_four, IBM | no comments | no trackbacks