Talk Like A Duck: Category war_stories

Essence, Ceremony, and Deja-Vu

Rick DeNatale — Thu, 21 Aug 2008 14:13:00 -0400

Stu Halloway just pointed out an interesting article on a Scala blog.

Stu asks us to consider whether making a Scala object an application by extending a trait, as described by the Scala article, affects the question of essence vs. ceremony. It certainly does cut down on boilerplate code.

Although this appears to be part of the standard Scala library, it is documented in such a way as to discourage its use, for the same reasons given in the article.

What strikes me is that the reasons seem to be tied up in language implementation and in particular the ways of the JVM. Perhaps this is an example of how the JVM, at least as it is today might be a good, but not the best platform for dynamic language implementation.

Putting on my old curmudgeon’s hat, this strongly reminds me of the early days of PL/I. The earliest PL/I compilers were notoriously bad at generating efficient code for subroutine linkage. PL/I was designed for the IBM/360, which used a subroutine calling mechanism entailing chaining invocation frames in a doubly linked list rather than on a stack. The brute force way to do a call was to perform a system getmain (OS/360 for malloc) at the beginning of a subroutine, and a freemain(free) upon return. This was fairly expensive.

As a result of this, early PL/I programmers were admonished not to use subroutines/functions, or at least to use them sparingly.

This is not bad language design, it is bad implementation.

And perhaps it is just one example, or maybe there are two here, one in Scala and one in PL/I, of how well meaning decisions based on the characteristics of the implementation at hand, particularly when compounded can give us magnificent complexities, that we really don’t need.

How Did You Get Started in Programming

Rick DeNatale — Sat, 07 Jun 2008 23:14:00 -0400

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.

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

Rick DeNatale — Wed, 21 May 2008 16:58:00 -0400

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.

Cool, but Stupid, Things I've Done

Rick DeNatale — Sat, 17 Nov 2007 06:18:00 -0500

Cones
© Eric Castro

One of the things about working with software is that you can pretty much do anything you imagine.

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.

Visual VisualAge

Years ago, my position at IBM gave me the opportunity to visit other companies pushing the envelope in software development. One such visit was to a small company in Santa Barbera, CA called Expertelligence, which at the time produced a version of common lisp for the Macintosh called ExperCommonLisp

There I met an interesting young Frenchman by the name of Jean-Marie Hulot, who showed me a user interface tool written in ExperCommon Lisp.

Sometime later I ran into Jean-Marie again at a meeting with Steve Jobs at NeXT. Steve had hired Jean-Marie. The interface tool had been ported to Objective-C and had become the NeXT interface builder. It lives on to this day as part of the XCode tools for Mac OSX.

I was impressed by what I'd seen, but by then I'd been working with Smalltalk for a while. The visual construction of the UI was cool, but I didn't like the idea of being dumped back into the mundane world of compilers and make. After having seen "Paree" in the form of the Smalltalk development environment, it was hard to imagine staying down on the farm.

So, I thought, why not make something like the interface builder inside the Smalltalk environment, and a quick prototype was born.

For some reason, I dubbed this the "Application Builder" with the idea that the combined UI Builder/IDE was for building more than just UIs.

Well, after I showed the prototype around a bit, I got to show it to Earl Wheeler, who was the IBM executive responsible for IBMs software tools strategy (AD/Cycle). He apparently liked what he saw, and funded a Smalltalk project based on my prototype. This opened the door for the IBM Smalltalk products to come.

Rather than getting intimately involved with the product development group, I stayed in advanced technology research.

When Earl took on Smalltalk, the last thing he seemed to want was to introduce a new language. But, because of the visual UI construction in my prototype, he rationalized "positioning" Smalltalk as a "generator." Perhaps as a result of this, the product team got quite carried away with visual construction and made the project a complete visual programming language, and the product was dubbed VisualAge as a result of a christening contest among the development team.

In retrospect the streass on visual programming wasn't so smart. The resulting programs were hard to understand, debug and maintain. Ken Auer recently observed that it produced a lot of "Smalltalk" programmers who didn't learn Smalltalk.

It also had a marketing effect on Smalltalk. After IBM came out with VisualAge, ParcPlace renamed their ObjectWorks family of products as VisualWorks.

IBM did eventually release IBM Smalltalk, unbundled from the visual programming componentry.

Too Much Transparency Considered Harmful

Sometime later, I had another "cool idea" and led a small development team to turn it into a product. The idea was transparent distributed execution of Smalltalk programs, and the product was the IBM/Smalltalk Distributed feature.

This was, if I may say so, a technical tour-de-force. Completely written in Smalltalk, the feature allowed Smalltalk programs to comprise objects on different networked machines. It was much more transparent that other distributed object technologies like Rubys DRB, Javas RMI, or Corba. Everything worked off of Smalltalks reflection capabilities, there was no IDL. In fact we named it Smalltalk Distributed to distinguish it from HPs Distributed Smalltalk which was 'just' a binding of Smalltalk to CORBA.

And the development environment was fully distributed as well, without too much work on our parts. For example the regular Smalltalk debugger was able to follow execution threads (in Smalltalk threads are called Proessses) from machine to machine and back again. A Smalltalk block containing a return on one machine could be called from a method on another machine, and the distributed stack would unwind just like it would on a single machine. Normal process synchronization techniques would work as well.

The key to making this work was implementing what I called a "logical" process which associated each Smalltalk process with a single local process on each physical machine involved in the logical process. The Debugger worked, because the Smalltalk debugger is, at heart, a process inspector, and by making the logical process mimic a normal process, the debugger was none the wiser.

This was really cool technical stuff, but in reality it turned out to be stupid because making distributed method sends so transparent hides important facts such as that there can be orders of magnitude performance differences between a local and remote send and, probably more importantly, there are failure modes (like network outages) for a remote send which just don't occur for local sends.

So just like cases where a building owner decides that it's prudent to put some obvious visual clue on a large floor-to-ceiling window to keep people from trying to walk through it, sometimes it's better to eschew transparency and make the programmer deal with reality rather than perception.

To paraphrase Kent Beck...

Rick DeNatale — Sun, 02 Sep 2007 17:35:00 -0400

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!

Nobody Could Count Beans Like IBM

Rick DeNatale — Sun, 02 Sep 2007 16:52:00 -0400

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.

After the Hoedown is Over, Part 1

Rick DeNatale — Tue, 14 Aug 2007 11:03:00 -0400

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.

Deja-Vu All over again

I was just a little surprised how often Smalltalk came up during the weekend.

The first instance was in the keynote talk by Bruce Tate, well known as a Java apostate in which he explored the current state of Ruby, how it got where it is, and where it might go in the future.
This was in part a cautionary tale, and the fate of Smalltalk in the mid-late 1990s loomed large.
As one of those heavily involved in the Smalltalk community as a developer and evangelist for IBM, I found it interesting to get an independent perspective.
Ken Auer gave a talk on Saturday called “Does Ruby have a Chasm to cross?”

So another independent perspective on what happened to Smalltalk, this time from someone with known credentials as a key member of the Smalltalk community when it was booming. Ken and I go back quite a ways.

Ken worked at Knowledge Systems Corp back then, which as a company which provided intensive training in object oriented development using Smalltalk via an apprentice program. Clients would send small development teams to KSC to work on the clients project with the assistance and mentoring of KSC folks. Efforts such as these were important seeds for what we now know as the agile movement.

Ken got a lot of things right about what happened to Smalltalk, although I could add some details and corrections from and “inside IBM” perspective, which might be food for future articles.

Finally, I “organized” a birds-of-a-feather session covering “Ruby for Smalltalkers, and Smalltalk for Rubyists” which was well attended and turned out to be mostly a few old IBM Smalltalkers like me, Fred George, and my “evil twin”, Pat Mueller responding to questions from Rubyists about Smalltalk.

Testing Workshop

Stepping back, on Friday morning, Bruce Tate, Chad Fowler, and Marcel Molina jr. ran a charity workshop on test driven development, with proceeds going to the local food bank.

Although I’m a pretty committed test-driven developer, I found the session very informative, and got a new appreciation for the use of mocks, not only to allow testing before all the code is written, but to keep tests independent even after the components being mocked exist.

Watch this space

This article has already gotten long enough, I expect to post more about the events of the past weekend in the near future.

The other Dave Thomas and the Birth of the Agile Alliance

Rick DeNatale — Mon, 09 Jul 2007 13:17:00 -0400

“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.)

Agile Alliance got started and the writing of the “Agile Manifesto”

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.

“Big Dave,” not to be confused with Dave Thomas of the Pragmatic Programmers, has been one of the movers and shakers of the object-oriented technology community for many years, and doesn’t always get the credit he deserves, particularly now that he has “retired” to the Carribean island of Anguilla. He might not be as visible now as he was in the heyday of OTI, but he’s still active. Had Anguilla been easier to reach, the Agile Manifesto would have been written at Dave’s place instead of in Utah.

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

Punch Card Tales

Rick DeNatale — Wed, 27 Jun 2007 17:02:00 -0400

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.

Tale #1

When I was an undergraduate, I used to spend all my free-time (and much of my non-free time) at the University computer center. There was a large room for student use with keypunch machines on the walls and worktables in the center.

One of my friends was a graduate student who was working on a team writing an Algol compiler as a term project. They had broken down into teams, lexical analysis, parser, code generation ,etc. They were in the middle of integration.

The “source code control system” was a large punch card box. For those who haven’t seen them these are long corrogated cardboard boxes which hold a big stack of cards and have a lid hinged in the back.

The team was making a series of debugging runs, they would take turns carrying the box to the room with the card reader and offer the contents to the god in the mainframe as their latest ‘sacrifice.’ When the listing came back, they would spread it out on the table and figura out what to do next.

This wasn’t ‘pair’ programming, it was ‘septet’ programming.

I was sitting at a nearby table helping another student with a homework assignment, and glancing occasionally at the compiler team.

The guy with the card box came back from the reader to see his team-mates vigoursly discussing something they had seen in the last run. He was carrying the box in front of him, his fingers wrapped around the bottom, and his thumbs holding the lid down. He walked up to the table gaining interest in the discussion. As he leaned over the table, he absent-mindedly rotated his wrists and relaxed his thumbs!

They spent the next hour or so trying to ‘revert’ the deck from the last listing.

Thank God that today we’ve got cheap hard-disks and subversion!

Tale #2

Same time frame and place.

Tom was another graduate student friend. He was an older guy who had come back to school after spending some time in the trenches in Texas. Back in the early 1970s there was lots of data processing done by what IBM called “Unit Record Shops.” Tome had worked in one before coming to graduate school.

In IBM parlance a punched card was a unit record since the file record (I guess we’d call it a row in SQL these days) and the physical unit, the card, were one and the same.

Unit record shops, didn’t have computers, which in those days were investments on the order of a million dollars, give or take an order of magnitude or two. They did everything with decks of punchcards and machines which sorted, collated, or printed them. These machines were ‘programmed’ by connecting holes in plugboards with wires.

Tom said that once he’d accompanied his boss to a trade show. The boss, like many others, didn’t have a really good grasp of the technology his business used.

The boss saw Tom on the show floor and told him, “Tom, come here, you’ve got to see this!”

He led Tom to a booth where a “booth babe” was loading a rainbow-colored stack of cards into the input hopper of a machine, and pushing the start button at which point the machine put all the blue cards in one slot, the yellow cards in another, and so forth.

Tom couldn’t figure out why the boss was so impressed, surely he’d seen sorting machines before. After all they has several of them at work.

Then the boss showed his hand.

Tom, I’ve seen lots of fancy machines in my day, but this is the first one I’ve ever seen that could sort by color!

Even today, it’s too easy to create demos with lots of flash and no substance.

Good News

Rick DeNatale — Fri, 22 Jun 2007 10:29:00 -0400

Recently on gluttonous, Kevin Clark announced that Powerset is going to launch their front-end on Ruby. It seems that they were already pre-disposed to a major ruby comitment having built a sizable Ruby talent pool for their internal applications.

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.