Dan Ingalls videos on Object-oriented programming

Dan Ingalls is one of the fathers of Smalltalk. He worked at Xerox PARC with Alan Kay when the latter invented the language and the OO paradigm during the seventies. Dan was the author of virtually all Smalltalk implementations up to Smalltalk-80, including the first one, using, of all languages, BASIC. As Alan explains in his Early History of Smalltalk, the first proof of concept ST was the result of a bet:

One day, in a typical PARC hallway bullsession, Ted Kaeher, Dan Ingalls, and I were standing around talking about programming languages. The subject of power came up and the two of them wondered how large a language one would have to make to get great power. With as much panache as I could muster, I asserted that you could define the “most powerful language in the world” in “a page of code.” They said, “Put up or shut up.” […] For the next two weeks I got to PARC every morning at four o’clock and worked on the problem until eight […]

After Alan showed up his newly designed language, he was about to turn back to real work, but:

Much to my surprise, only a few days later, Dan Ingalls showed me the scheme working on the NOVA. He had coded it up (in BASIC!), added a lot of details, such as a token scanner, a list maker, etc., and there it was–running. As he liked to say: “You just do it and it’s done.”

Over the next ten years, Dan made (with some help) at least 80 major releases of various flavors of Smalltalk. (in the meantime, he found time for many other things; for instance, inventing BitBLT.)

Picture 1By 1989, Dan Ingalls was working at Apple (applying Smalltalk to things as nifty as Fabrik), and he recorded this video on Object-Oriented Programming. During about an hour, the basic ideas of OO are reviewed, including some clues on how one implements a single-inheritance classes. Like all great ideas, it is surprisingly simple. The guys at PARC did not stop implementing the language, but went on to developing a complete operating system and environment based on it: Ingalls’ take on OO stresses those aspects, explaining how they were trying to tame complexity and how, for instance, garbage collection (which is really orthogonal to OO) was needed. The video contains a coda consisting in a little question and answer session, where typical objections to OO are reviewed. While not earth-saking, it makes for a funny view, and a review of the basics.

Picture 2 Fast forward to last October 25, when Dan gave a talk entitled Seven (give or take) Smalltalk implementations like www.crosscountrymovingcompanies.biz/at Standford. He’s not the only who has gained a fresh new look: his Smalltalk is now Squeak (Dan has been deeply involved in its design and implementation), which he uses to give the talk and demonstrate the joys of an integrated programming ambient. Besides, Dan reviews the motivations and influences leading to Smalltalk, in a guided tour through its many incarnations over the years. There are lots of reminiscences of the Xerox days and his interactions with Alan Kay (including the bet i mentioned above).

Addendum

Early OOTalking about Smalltalk’s early influences, they include, of course Lisp and Simula. But not only them. A delicious piece of trivia that Alan explains in his Early History is his first encounter with an object-oriented design. As it happens, the precursor of OO was an anonymous programmer working for the Air Force around 1960. This unsung hero solved the problem of transporting data files by …

… taking each file and dividing it into three parts. The third part was all of the actual data records of arbitrary size and format. The second part contained the B220 procedures that knew how to get at records and fields to copy and update the third part. And the first part was an array or relative pointers into entry points of the procedures in the second part (the initial pointers were in a standard order representing standard meanings).

From here, Alan took the idea of having procedures attached to objects, without the system needing to know them in advance. Needless to say, Alan thought that was a pretty good idea and, as the saying goes, the rest is history.

But these are only teasers. You should really watch Ingalls’ videos (specially the last one) and read Kay’s article. You will have a great time.

Tags: , , ,

Conjure reaches a baby milestone

The latest conjure48 version at my repository is able to build s42, and run the test suites—doc generation is almost there too.

If you have the s42 source tree, you can try it with the following incantations [1]:

  $ ln -s conjure/examples/s42/build.scm .
  $ ln -s conjure/examples/s42/build.exec .
  $ scheme48
  > ,exec ,load "build.exec"
  > (build-system "s42" "test")

That will run the testsuite. Other goals that can be used instead of ‘test’ are ‘runners’, ‘s42.image’ or ‘doc’. If you take a look at the build script and find it ugly, please keep in mind that this is still alpha code, and that s42 is a rather complex system when it comes to building. This simpler build file for a test C project is closer to what we envision. From here, we’ll be polishing the syntax and interfaces to attain our DSL-for-non-schemers goal.

If you are in Vienna tomorrow, don’t miss rotty’s talk on scheme, s48 and s42 for Debienna, where Conjure will make its world wide debut :-).

—-
[1] There are some tricky issues that you may stumble upon to get there. Please, do not hesitate to contact us at #conjure in Freenode.

Tags: , ,

An Assembly Quiz

Appleassemblyline From October 1980 through June 1988, Bob Sander-Cederlof published a newsletter called Apple Assembly Line. This newsletter focussed on assembly language for the Apple ][, //e, //c, and //gs computers, all of them based on the 6502 processor and its derivatives. Bob was the author of the S-C Macro Assembler, which lived as long as the newsletter, i.e., until 1988.

Since a few months ago, there’s an Apple Assembly Line [online] Archive that includes all the AAL newsletters. It’s very fun, and instructive, to have a look at them, even if you don’t have an Apple ][. You can still pick some Steven Wozniak trick for your assembly programming, or learning how to add or substract one. If you know a bit of assembly, you’ll understand the code quickly (in fact, it looks a lot like Don Knuth’s MIXAL in TAOCP, and i’ve been able to run some code on my MIX simulator with minimal modifications).

If you’re thinking that you will learn little from a twenty years old newsletter, please try your hand at discovering what the DO.SOME.MAGIC subroutine below computes:

  1010 *--------------------------------
  1020 BYTE   .EQ 0
  1030 *--------------------------------
  1040 T      LDA #0
  1050        STA BYTE
  1060 .2     LDX #14
  1070 .1     CPX #7
  1080        BNE .4
  1090        LDA #$A0
  1100        JSR $FDED
  1110 .4     JSR DO.SOME.MAGIC
  1120        JSR $FDDA
  1130        INC BYTE
  1140        BEQ .3
  1150        DEX
  1160        BNE .1
  1170        JSR $FD8E
  1180        JMP .2
  1190 .3     RTS
  1200 *---------------------------
  1210 DO.SOME.MAGIC
  1220        LDA BYTE
  1230        LSR
  1240        LSR
  1250        LSR
  1260        ADC BYTE
  1270        ROR
  1280        LSR
  1290        LSR
  1300        ADC BYTE
  1310        ROR
  1320        LSR
  1330        LSR
  1340        RTS
  1350 *--------------------------------

If there’s some mnemonic that you don’t understand, here you have a complete reference of the 66 instructions understood by the 6502. The solution is somewhere in the AAL archive, but you will have a far greater time if you try to solve this little riddle by yourself. And if you get all worked up and want to try more algorithms for howtobcome real, this page points to some 6502 emulators and assemblers. Have fun!

Tags: ,

Programming in Smalltalk for Spanish readers

Squeak, a World to LearnDiego Gómez Deck is finishing a new book entitled Programando con Smalltalk (Smalltalk Programming), which guides readers new to Smalltalk (but not to programming) into the use of the language and the Squeak environment. The book will be published under a CC license, and its drafts are available online. I just skimmed over the latest draft, but seems a very interesting reading (if you read Spanish, that is; translating Diego’s book to English would be an interesting project). Diego has already coauthored a previous Spanish Squeak book, which was published last year: just click the image of its nice cover for more info.

This book joins the uprising of Squeak’s popularity in Spain, driven by its being used by the local government of Extremadura as the platform for some of its projects. The last one consists of an interactive educational and reference tool that will let users of the Extremadura’s Regional Net to know more about a bunch of topics on physics, chemistry, biology, ecology or society, to name a few. Actually, the tender is still open, in case you feel like trying. Cees’ Blog provides the necessary info (this time in English), including some reasons to not really wasting the time applying.

Tags: ,

Waterfall 2006

If you’re in any way involved in a software project with something to be delivered, please don’t miss Waterfall 2006 – International Conference on Sequential Development. If you’re not, but want to laugh out loud and learn something in the process, don’t miss it either.

And don’t forget to register.

Scheme newslore

Lately, reading comp.lang.scheme is more amusing and instructive than ever. Scheme is (as Albert Einstein would put it) as simple as possible, but not simpler. Or, to use the words of Michael Vanier, it is an LFSP rather than an LFM. Which means that it has its (often necessary) subtleties and shadowy corners. Some newcomers in the newsgroup are making a serious effort at learning Scheme, and stumbling upon those corners, which are being subsequently illuminated with insightful posts. For instance,

When are two objects equal? As you probably know, Scheme comes with several equality predicates: EQ?, EQV?, EQUAL?, =, STRING=?… How so? Aren’t all equal objects equal? Well, as it happens, some equal objects are more equal than others. Perhaps, like me, you think that you understand the differences between those predicates; and perhaps, like me, you’ll discover that you were missing some small print after reading this Socratic dialogue between a hacker and a newbie, which summarises an interesting thread with participants as insightful as Berkeley’s professor Brian Harvey. After reading his posts, you may be interested in viewing his SICP classes too.

Concrete AbstractionsClosures are of paramount importance to functional programming. As a matter of fact, object oriented programming can arguably be described as a poor man’s closure-based programming. Max Hailperin has written today a beautiful overview of what closures are and how they are implemented. Again, i thought i already knew. If you enjoy Max’s writing, this is your lucky day: he is one the authors of Concrete Abstractions, an introduction to CS using Scheme freely available in the link above.

Update: There’s also accompanying material for a course by Max, based on Concrete Abstractions, here and here.

Tags:

Programmers love writing (and mocking) tests

Aggressive unit testing (also known, by those willing to earn some easy money, by the buzzword test-driven development) is about the only practice from XP that i embraced happily in my days as a dot com employee (it was around 2000, and i was working for one of those companies that got lots of funding from avid but hopelessly candid investors to do… well, to do basically nothing).

Those were my long gone Java days, and i got test infected all the way down. That writing tests is a good practice is hardly news for any decent programmer, but what i specially liked about putting the stress on writing lots of tests was discovering how conductive the practice is for continuous code rewriting (count that as the second, and last, extreme practice i like). I had yet to discover the real pleasures of bottom-up development in REPL-enabled languages, but even in Java my modus operandi consisted basically in starting with concrete code (sometimes even a mere implementation detail) and make the application grow up from there. Of course, some brainstorming and off-the-envelop diagramming was involved, but the real design, in my experience, only appears after fighting for a while with real code. The first shot is never the right one, nor the second, for that matter. The correct design surfaces gradually, and i know i’ve got it right when unexpected extensions to the initially planned functionality just fit in smoothly, as if they had been foresighted (as an aside, i feel the same about good maths: everything finds its place in a natural way). When you work like that, you’re always rewriting code, and having unit tests at hand provides a reassuring feeling of not being throwing the baby with the bath during your rewriting frenzies.

Of course, there’s also a buzzword-compliant name for such rewritings (refactoring), and you can expend a few bucks to read some trivialities about all that. (Mind you, the two books i just despised have been widely acclaimed, even by people whose opinion i respect, so maybe i’m being unfair here—in my defense, i must say i’ve read (and paid) both of them, so, at least, my opinion has cost me money.)

Sunit in SqueakAnyway, books or not, the idea behind the JUnit movement is quite simple: write tests for every bit of working code you have, or, if you’re to stand by the TDD tenets (which i tend not to do), for every bit of code you plan to write. As is often the case, the Java guys where not inventing something really new: their libraries are a rip-off of the framework proposed by Kent Beck for Smalltalk. Under the SUnit moniker, you’ll find it in every single Smalltalk implementation these days. A key ingredient to these frameworks’ success is, from my point of view, their simplicity: you have a base test class from which to inherit basic functionality, and extend it to provide testing methods. Languages with a minimum of reflection power will discover and invoke those methods for you. Add some form of test runner, and childish talk about an always green bar, and you’ve got it. The screenshot on the left shows the new SUnit Test Runner in one of my Squeak 3.9 images, but you’ll get a better glimpse of how writing unit tests in Squeak feels like by seeing this, or this, or even this video from Stéphane Ducasse‘s collection.

Of course, you don’t need to use an object-oriented language to have a unit testing framework. Functional languages like Lisp provide even simpler alternatives: you get rid of base classes, exchanging them by a set of testing procedures. The key feature is not a graphical test runner (which, as any graphical tool, gets in the way of unattended execution: think of running your tests suites as part of your daily build), but a simple, as in as minimal as possible, library providing the excuse to write your tests. Test frameworks are not rocket science, and you can buy one as cheap as it gets: for instance, in C, i’m fond of MinUnit, a mere three-liner:

/* file: minunit.h */
#define mu_assert(message, test) do { if (!(test)) return message;  \
                                    } while (0)

#define mu_run_test(test) do { char *message = test(); tests_run++; \
                               if (message) return message; } while (0)

extern int tests_run;

(Let me mention in passing, for all of you non-minimalistic C aficionados, the latest and greatest (?) in C unit testing: libtap) Add to this a couple of Emacs skeletons and an appropriate script and you’re well in your way towards automated unit testing. From here, you can get fancier and add support for test suites, reporting in a variety of formats, and so on; but, in my experience, these facilities are, at best, trivial to implement and, at worst, of dubious utility. It’s the quality and exhaustiveness of the tests you write what matters.

Lisp languages have many frameworks available. The nice guys of the CL Gardeners project have compiled a commented list of unit testing libraries for Common Lisp. In Scheme you get (of course) as many testing frameworks as implementations. Peter Keller has written an R5RS compliant library that you can steal from Chicken. Noel Welsh’s SchemeUnit comes embedded into PLT, and the Emacs templates are already written for you (or, if you mileage varies and you’re fond of DrScheme, you can have a stylized version of the green bar too). Personally, i don’t use PLT, and find Peter’s implementation a bit cumbersome (meaning: too many features that i don’t use and clutter the interface). Thus, my recommendation goes to Neil van Dyke of quack‘s fame’s Testeez. Testeez is an R5RS (i.e., portable), lightweight framework that is as simple as possible. Actually, it’s simpler than possible, at least in my book. In my opinion, when a test succeeds it should write nothing to the standard (or error) output. Just like the old good unix tools do. I only want verbosity when things go awry; otherwise, i have better things to read (this kind of behaviour also makes writing automation and reporting scripts easier). So, as a matter of fact, I use a hacked version of Testeez which has customizable verbosity levels. It’s the same version that we use in Spells, and you can get it here. Also of interest are Per Bothner’s SRFI-64, A Scheme API for test suites and Sebastian Egner’s SRFI-78, Lightweight testing (both including reference implementations).

Lisp testing frameworks abound for a reason: they’re extremely useful, yet easy to implement. As a consequence, they’re good candidates as non-trivial learning projects. A nice example can be found in Peter Seibel’s Practical Common Lisp (your next book if you’re interested in Common Lisp), which introduces macro programming by implementing a decent testing library. In the Scheme camp, Noel discusses the ups and downs of DSL creation in an article describing, among other things, the SchemeUnit implementation. A worth reading, even for non-beginners.

Once you settle on a test framework and start writing unit tests, it’s only a question of (short) time before you’re faced with an interesting problem, namely, to really write unit tests. That is, you’re interested in testing your functions or classes in isolation, without relying on the correctness of other modules you’ve written. But of course, your code under test will use other modules, and you’ll have to write stubs: fake implementations of those external procedures that return pre-cooked results. In Lisp languages, which allow easy procedure re-definition, it’s usually easy to be done with that. People get fancier, though, specially in object-oriented, dynamic languages, by using mock objects. The subject has spawn its own literature and, although i tend to think they’re unduly complicating a simple problem, reading a bit about mockology may serve you to discover the kind of things that can be done when one has a reflective run-time available. Smalltalk is, again, a case in point, as Sean Mallory shows in his stunningly simple implementation of Mock Objects. Tim Mackinnon gets fancier with his SMock library, and has coauthored a very interesting article entitled Mock Roles, Not Objects, where mock objects are defined and refined:

a technique for identifying types in a system based on the roles that objects play. In [9] we introduced the concept of Mock Objects as a technique to support Test-Driven Development. We stated that it encouraged better structured tests and, more importantly, improved domain code by preserving encapsulation, reducing dependencies and clarifying the interactions between classes. […] we have refined and adjusted the technique based on our experience since then. In particular, we now understand that the most important benefit of Mock Objects is what we originally called interface discovery […]

An accompanying flash demo shows SMock in action inside Dolphin Smalltalk. The demo is very well done and i really recommend taking a look at it, not only to learn to use Mock Objects, but also as a new example of the kind of magic tricks allowed by Smalltalk environments. Albeit not as fanciful, Objective-C offers good reflective features, which are nicely exploited in OCMock, a library which, besides taking advantage of Objective-C’s dynamic nature, makes use of the trampoline pattern (close to the heart of every compiler implementer) “so that you can define expectations and stubs using the same syntax that you use to call methods”. Again, a good chance to learn new, powerful dynamic programming techniques.

As you can see, writing tests can be, a bit unexpectedly, actually fun.

Tags: , , , , , ,