Lambda the Ultimate

Well, according to the Stroustrup presentation you just linked to, Dijkstra was associated with ALGOL. Not to mention that (IIRC) it was for his work on ALGOL that he received his Turing Award.

Thanks :-)

The exact quote from Kay is: "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind." But it's a slide presentation, so the comment was likely elided, though the jest of the quip is fairly encompassing about claims of ownership of a term. Of course, naming something is not always the same as creating the idea that is being named. I think Stroustrup's remark also has to be placed in the context of the amount of criticism C++ has received from the Smalltalk camp. Both were derivatives of Simula and were not particularly influenced by each other (Objective-C would be the C based language most influenced by ST). C++ is actually a lot closer to Simula than is Smalltalk. And I guess it should be mentioned that Kay has also quiped that he should have used the term Message Oriented Programming to better differentiate what Smalltalk accomplishes.

Personally, if I were to take offense at the slides, I'd probably say that Lisp was given less credit than it deserves - confining Lisp to the domain of a PL for AI will grate the wrong way for most Lisp advocates. But then I don't expect to see Stroustrap give a totally objective reading of the history of programming languages, as his direct experience is along the lines of Algol, Simula, C, and C++. Only brief mention of Functional and Logic PLs (Scheme, Prolog, ML and Haskell are important forces in the market place of PL ideals).

A very similar quote can be found in one of the classic Alan Kay stories (not that wiki is an "authoritative source", obviously).

Seeing as the this is a set of slides, which were probably used to accompany a verbal presentation, I don't think you should be so quick to pass judgement on the authors though.

"Seeing as the this is a set of slides, which were probably used to accompany a verbal presentation..."

It shouldn't have been posted as a front-page story here if the intent is to present serious content relating to programming languages. Think of it as my way of asking that random slideshows not be posted here just because they're associated in some way with a programming langauge or PL creator. I'm not sure *they* would want that, either.

"...I don't think you should be so quick to pass judgement on the authors though."

You may be right there. It doesn't deserved to be judged as if it was in a major public speech or the introduction to a book, as it was not intended for same context or the same number of people. On the other hand, I mentioned that I wouldn't take the *presentation* seriously, not the author. How that judgement reflects on the author is really up to the reader.

Ehud has seen enough of my posts over time to realize that some of my stories are good and some not so good. Oddly enuf, my good stories get much less comment than my mediocre ones, and my theory has always been that people are more forthcoming in their opinions when they don't feel threatened.

Although I certainly don't think the slides were anywhere near the quality of many of the technical papers posted on LtU, I also don't feel that LtU is exclusively geared to content that is totally rigorous in the mathematical sense. Yes we have our share of papers that should keep us busy for the next decade or so. But LtU is a discussion forum for all things related to programming languages. History just happens to be one of the ideas that Ehud was interested in generating a bit more discussion - and I think this particular item has yielded some interesting viewpoints on Pascal, Smalltalk and Apple.

As for Stroustrup, he's a big boy, having been flamed in many a place, in much more intense ways. I doubt he cares how we use or abuse this particular material. And if he didn't want people to use it as a resource, then he shouldn't have bothered posting it on the world wide web.

My personal suggestion is to not take this internet stuff so seriously and to expend energy fighting battles that are more worthwhile. If you like the more technical papers on LtU, the better way to go about it is to ignore the stories you don't like and engage in the technical discussions that interest you. For example, why not spend more time on my CP story that has a higher quality of links, rather than waste time on what you consider to be a low quality story?

I found the slides to be interesting, and am glad that you posted the story. I think the key is to look at the slides not as an objective (pun intended) history of programming languages, but as a presentation of Bjarne Stroustrup's perspective on that history. Which is an interesting thing in itself. The fact that, to take one example that someone else here already raised, Stroustrup gave such a small amount of attention to Lisp helps us to understand why C++ is the way it is.

LtU is a discussion forum for all things related to programming languages.

Right. And I trust the judgement of our contributing editors, who go to the trouble of posting for our benefit, in choosing interesting items worthy of attention, even when they are not scientific papers. Many such items were posted here over the years, indeed they include some of the more interesting things I stumbled across via LtU (course pages, demos, tutorials, movies etc.)

Personally, I see no problem with this item.

...to defend the post to the 9's, elevating the slides to being the most important thing ever in the discussion of the history of PLs. Then perhaps engage in a bit of ad hominem. (All those years of intercollegiate debate means that I'm quite capable of arguing any point from any perspective, whether I believe it or not).

But my evil twin lost the argument, as I figured this wasn't a particularly productive line of thought. :-)

Stroustrup and C++ are a lightning rod when it comes to discussion of PLs, so a certain amount of fallout was probably inevitable. Personally I enjoy reading Stroustrup, even if I'm not enamoured of C++.

This appears to be quote from Alan Kay's keynote speech at OOPSLA 1997 (available via Google Video here). The comment in question appears roughly 10 min 30 sec into the speech (at least on the Google video version). The exact quote is

...I made up the term object-oriented — and I can tell you I did not have C++ in mind...

...from their forays into Xerox Parc, along with the GUI, mouse and networking, the history of PLs might have played out much differently. :-)

Edit Note: I know Anders is associated with Delphi, but was he also the major force with Turbo Pascal?

Regarding Anders and Turbo Pascal, yes, Anders was the guy. When I was at ICOM Simulations, developers of the TMON debugger for the Mac, we got a contract to implement a source-level debugger in a to-be-released version of Turbo Pascal for Macintosh. My good friend and colleague Darin Adler executed on that contract. IIRC, that version of Turbo Pascal for Macintosh never shipped, but Darin got to work directly with Anders and had great stories to tell.

Re: Smalltalk, there was a pretty intense Smalltalk culture in the Advanced Technology Group at Apple even while I was there—in fact, you could basically say that ATG Cupertino was the Smalltalk camp and ATG Cambridge was the Lisp camp (no surprise, since "ATG Cambridge" was essentially the assets of Coral Software, developers of Macintosh Common Lisp).

Something I didn't know -- a great success story of a tiny well-written kernel of code blossoming into an epic career...

Borland licensed the PolyPascal compiler core, written by Anders Hejlsberg (Poly Data was the name of his company in Denmark), and added the user interface and editor. Anders joined the company as an employee and was the architect for all versions of the Turbo Pascal compiler and the first three versions of Borland Delphi.

Chris Rathman: If only Apple had borrowed Smalltalk from their forays into Xerox Parc

Apple did, after a fashion. But I think a main limitation at the time was limited resources in consumer grade machines, which had shockingly small amounts of RAM by today's standards. (Think: at most one megabyte.) Both Lisp and Smalltalk tended toward heavier use of memory, because of their meta-complete natures, in comparison to low resource languages like C. (Folks might not remember that the main objection to Lisp and Emacs at one time was the sheer amount of memory these things needed; they had reputations for being resource hogs.)

Apple had Rick Meyers implement Lisa Smalltalk, which later evolved into MacSmalltalk. [You can read about Rick's research in Smalltalk in "Smalltalk-80: Bits of History, Words of Advice", in a part three: An MC68000-Based Smalltalk-80 System by Richard Meyers & David Casseres.] I was later able to get all the Smalltalk source inside MacSmalltalk (for free on request) when I was an Apple employee; the sources made good reading as well as great sample source for the Smalltalk compiler I wrote as a hobby at Taligent. Coincidentally, Rick Meyers was the head of the C++ CompTech compiler group at Taligent, though he wasn't interested in discussing the old Smalltalk days when I approached as a Smalltalk groupie. At Taligent, it was all C++ all the time -- just like a C++ radio station.

When Smalltalk had any success, it was in languages like Objective-C in the low memory resource tradition, that borrowed from Smalltalk without abandoning the C goal of zero development time space and time overhead at deployed application runtime.

(At OOPSLA one year, folks from the PinkOS project at Apple attended to announce they were writing an all new operating system in (gasp) an object-oriented language. When asked by the audience what language was being used, they replied, why C++ (of course). Which was met with laughter and general derision, according to report; it seemed to make Taligent folks glum.)

Objective-C was basically C with Smalltalk embedded inside, and this was adopted by NeXT Computer (Jobs' post Apple creation) as the systems programming language. At Taligent there was little but trash talk for Objective-C, which I found disturbing, because it wasn't as bare metal as C++ or something. In retrospect, it's now ironic that Apple eventually purchased NeXT (apparently priced to match what Apple and IBM had wasted on developing Pink/Taligent), and caused Objective-C to become the dominant systems language at Apple.

Paul Snively: Re: Smalltalk, there was a pretty intense Smalltalk culture in the Advanced Technology Group at Apple even while I was there--in fact, you could basically say that ATG Cupertino was the Smalltalk camp and ATG Cambridge was the Lisp camp (no surprise, since "ATG Cambridge" was essentially the assets of Coral Software, developers of Macintosh Common Lisp).

Apple tended to be divided politically on technology at times. I rarely met the Smalltalk guys, and some of them had become C++ guys, like Rick Meyers.

The Common Lisp/Dylan folks from Cambridge were a lot of fun. When David Moon and a couple others visited to discuss Dylan plans and integration with Taligent wares, I managed to get invited to lunch discussions, and a dinner or two along the way. (I was a grunt of no consequence whatsover, but as adynamic language groupie conversant in lisp, smalltalk, and C++ jargon, I was welcome as a translator into plain english for the non-technical or C++-only folks around.)

The machines we C++ developers had at the time came with enormous amounts of RAM intalled -- sixteen megabytes. :-) I know, this sounds like nothing now. I wangled an evaluation copy of Dylan to play around with, but it required twenty megs of RAM. When I tried it with only 16 megs, it didn't ... quite ... work. So apparently 20 megs was a realistic minimum.

This might help explain the resource usage situation with Lisp and Smalltalk, and how this made them unacceptable to many low level coders who couldn't splurge on time and space. We were planning to deploy on 8 meg end user machines, which were double the size of currently shippingsystems. The Dylan folks had to work with complex design constraints to ensure all unnecessary development time costs were stripped away for end user execuables.

And today, it just doesn't matter. Even a real resource hog of a development platform has trouble making a serious dent in the amount of resources a typical end user takes for granted.

• Delphi's objects are reference types with metaclasses, while TP5.5's objects are value types, subject to slicing etc. (Basically records with methods.)
• Virtual metaclass methods - no analogue in TP 5.5.
• Method pointers (aka delegates in .NET) - not in TP 5.5.
• Published visibility, with RTTI - not in TP 5.5.
• A sane syntax for dynamic allocation, calling a constructor directly rather than the odd New syntax, which infers the type to construct from the supplied pointer type, and has the constructor call as what looks like an expression argument.
• Exceptions
• Properties

var
  x: PSomeClass;
{ ... }
  New(x, Init(5));
{ ... }
  Dispose(x, Done);

var
  x: TSomeClass;
{ ... }
  x := TSomeClass.Create(5);
  try
    { ... }
  finally
    x.Free;
  end;

I wouldn't say TP 5.5's "objects" are a failure -- I seem to remember the old-style TP objects still being available in Delphi, even. In fact, there are times you'd want to use the old-style objects for performance reasons (analagous to stack allocation in C#'s structs vs classes, which is a disinction that still exists in a modern Anders language :) )

They've been deprecated for a long time. They aren't available in the .NET version of Delphi, for example.

...I don't know if any more radical changes are in the cards. Even Bjarne only has a limited amount of control over the direction of the language. Probably best he can do is drum in the idea of having the implementations meet the standards that have already been agreed to.

My reading of where the C++ would like to go has less to do with the language itself and more to do with trying to get a more comprehensive set of standard libraries. Most see this as the reason that Java has made inroads into some traditional C/C++ territory. Of course, one can argue that making libraries is much harder without a standard GC framework, but that's a more torturous sell.

a more comprehensive set of standard libraries.

I think Bjarne said as much in one of his articles we mentioned in the past.