re. design patterns

I realized that a few years ago, that if the GoF had worked on their concept some more, they might've been able to fashion a language out of their patterns, and then they wouldn't have to deal with constructing these patterns, but could just use the language to do what they wanted. As I recall, in the introduction of the book they said they were after a "pattern language," but maybe that was just a metaphor.

Re. Alan Kay and C++

Yeah, he was not expressing a preference for it. Here's the article and the actual quote. I tried summarizing it here, but when I found the original article again, I realized I was mischaracterizing what he said somewhat. He didn't express any realization, nor did he say "use macros." Rather he said the whole language is a macro processor, and that most C++ programmers miss this point.

This is an interview with Stuart Feldman from 2004:

http://queue.acm.org/detail.cfm?id=1039523

AK In the 1960s Ted Steele spent several years promoting an idea called UNCOL (universal computer-oriented language), and, to me, by a weird and interesting process mainly because its easy to implement, C turned out to be UNCOL. I dont think any human being should write in it, but its a great target for anybody who wants to do multiplatform things especially if you pick the right subset.

The problem with the Cs, as you probably know if youve fooled around in detail with them, is that they're not quite kosher as far as their arithmetic is concerned. They are supposed to be, but they're not quite up to the IEEE standards. You have to pick a subset of C and you have to have some side information to get to a mathematically perfect transform of your VM.

SF To what do you attribute the long-term love of Smalltalk? There is a certain set of languages that I would assert people seem to love, not just use. I know many people who love C. I know very few who love C++, even though they may make their living on it.

AK You have to be a different kind of person to love C++. It is a really interesting example of how a well-meant idea went wrong, because [C++ creator] Bjarne Stroustrup was not trying to do what he has been criticized for. His idea was that first, it might be useful if you did to C what Simula did to Algol, which is basically act as a preprocessor for a different kind of architectural template for programming. It was basically for super-good programmers who are supposed to subclass everything, including the storage allocator, before they did anything serious. The result, of course, was that most programmers did not subclass much. So the people I know who like C++ and have done good things in C++ have been serious iron-men who have basically taken it for what it is, which is a kind of macroprocessor. I grew up with macro systems in the early 60s, and you have to do a lot of work to make them work for you, otherwise, they kill you.

SF Well, C++, after all, was programmed as a macro processor, in essence.

AK Yes, exactly. But so was Simula.

In the work that he's done in the last 17 years, I haven't seen one instance of him, or the people he's worked with, doing anything in C++. They've used C some, but only as a high-level, portable assembly language, and even then, he's expressed a desire to get away from it, to create something better for low-level stuff.

Incidentally, in a 2010 interview, he had this to say:

http://www.computerworld.com.au/article/352182/z_programming_languages_smalltalk-80/

Q: What contribution do you feel you made to successive programming languages like Objective-C and C++?

The progression from the first Smalltalk to the later Smalltalks was towards both efficiency and improved programming tools, not better expression. And I would term both Objective-C and especially C++ as less object oriented than any of the Smalltalks, and considerably less expressive, less safe, and less amenable to making small compact systems.

C++ was explicitly not to be like Smalltalk, but to be like Simula. Objective C tried to be more like Smalltalk in several important ways.

However, I am no big fan of Smalltalk either, even though it compares very favourably with most programming systems today (I dont like any of them, and I dont think any of them are suitable for the real programming problems of today, whether for systems or for end-users).

Re. what you're finding in C

You might be interested in checking out Allen Holub's book, "C + C++: Programming with objects in C and C++." It's an old book, originally published in 1991, and was never updated. It looks like it's out of print, but you can still get it used. It's the book I used to learn C++. As I recall, he wrote it for people who were C newbies. So he goes from teaching C all the way through to teaching C++. I skipped the early part of it. The part that was really interesting to me was he goes into a "transitional phase", explaining how you could implement something object-like in C, using structs. He explained for example how you could implement inheritance by defining one struct, and then including that struct as the first instance inside a second one. This way you can hold onto a "derived" struct, recast it as the "base" struct, and it'll work. I haven't looked at the book in years. It was extremely helpful to me in learning how C++ works, which was necessary for me to get the language. There comes a point where he says, "You could do this in C to kinda get this feature in C++," and he demonstrates the principle, but then says, "This is a lot of work. Here's how C++ does this for you." So he explains the rationale for C++. At the time he wrote it, I think templates might've just been introduced into the language. He didn't cover templates at all, IIRC.

In the last part of the book he explains how you can use C++'s features to do some system-level abstraction. I remember one example he gave was explaining how you could create a "paging array". You created a container that looked for all appearances like an array (using operator overloading), but you had no limit on what you could index (well, up to MAXINT), because under the covers the array was a buffer which paged its contents to disk. It could save the portion of what you had put into it, that you weren't using at some point in time, and load some other portion you were trying to access. I thought it was a good book for what it was trying to teach.