Lambda the Ultimate

Actually I never understood why C++ became so popular while Objective-C languished. ObjC seems the better way to integrate objects with C. That Apple, nee NeXT, have used and are using Objective-C so well for the last 15 years or so bears this out.

Also consider the effort required to integrate a scripting language with C++ vs. doing the same with ObjC. Cutting to the chase: it's trivial in ObjC, it's a bear in C++.

On the theoretical side, developers engaged in the worst sort of premature optimization: since Objective-C is (deliberately, by design) uniformly extremely-late-bound, it "couldn't be as fast" at C++, in which early binding is the default and "virtualization" a conscious choice that opens up a raft of issues ("virtual constructor" idioms, anyone)? I lost track of the number of times I heard this canard passed along as if it had actual semantic value.

On the pragmatic side, for the longest time, NeXTStep was the only environment with an Objective-C compiler, let alone Objective-C frameworks. So if you think that the Macintosh was a marginal platform to develop for, imagine trying to make the case for NeXT development!

Now, of course, with Cocoa, Objective-C is arguably in better shape than it's ever been in the marketplace.

Patrick: Also consider the effort required to integrate a scripting language with C++ vs. doing the same with ObjC. Cutting to the chase: it's trivial in ObjC, it's a bear in C++.

Yeah. All of the C++ solutions worth their salt essentially implement a MOP for C++ and then trampoline between the MOP and the scripting language. At this point, I almost find C++ without a MOP of some kind not worth using... but C++ with a halfway-decent MOP can almost be pleasant. Whisper 2 is a good example of a Mac/Windows framework in C++ that implements a nice COM-inspired MOP and then uses that for practically all but the very lowest levels of its architecture. And so far, the nicest-looking fairly-general MOP for C++ that I've found is here.

Hmm... at the "C" level of C++, it is very easy. At the C++ (class, operator/function overloading, templates, etc) it is more difficult. Then again, I tend to glue scripting languages onto C++ at the flat points (classes that don't expose deeply nested structures or mechanisms --- i.e. not templated nor riddled with pointers to other classes nor deep extension via inheritence). For such flattened classes, tools like SWIG make life easier.

Actually I never understood why C++ became so popular while Objective-C languished. ObjC seems the better way to integrate objects with C.

The saving grace of C++ is STL (generic programming). I think if it wasn't for STL, C++ would have faded away. Sure other languages do it better (or simply don't need such mechanisms), but it help break C++ from its object-oriented chains (OO being something it never did very well -- too low level).

ObjC, like Java, depends heavily upon is library to be truly useful. C++ is full of rich abstractions and enough rope to hang yourself with.

That being said, rewriting Yahoo Store in C++ seemed to be a value subtracted prospect: Let's take something that works and rewrite it using a lower level language, because as we all know, the web is all about bit manipulation ;-)

SWIG is not a dynamic runtime mechanism, though.

1. Hmm... at the "C" level of C++, it is very easy

Kind of leaves out a good bit of C++. 8^)

Then again, I tend to glue scripting languages onto C++ at the flat points

I suspect this is influenced by #1, above.

because as we all know, the web is all about bit manipulation ;-)

LOL. I'd like to see a transcript of the actual discussions.

Yes, and this is part of the curiosity. There's a chicken and egg thing here somewhere.

Why the demand and/or supply for C++ early on?

The demand, I guess was due to marketing by AT&T. Unsuspecting people, like Mentor Graphics, jumped in with million dollar commitments without a reasonable evaluation.

Someone could have sold ObjC from the supply side on non-NeXT platforms, recruiting some key influencers.

Funny.

Patrick (Logan, I presume?)

Correct.

Why the demand and/or supply for C++ early on?

C++ was marketed on the Big Lie principle: the conceit was that you could take your existing C programmers, sprinkle Magic Pixie Object Dust on them, and they'd be new-fangled object-oriented C++ programmers. Just say "class" instead of "struct." The argument really was that C++ was extremely backward-compatible with C, whereas Objective-C required you to adopt a different development approach from the outset. Now, I'm not convinced that this is completely true (AFAICT, you can write C just as well in Objective-C as in C++), but I do believe it's true that if you do take advantage of objects in Objective-C, you are, perforce, faced with a different paradigm than in C++. Feature or bug? This is where the disconnect lies, IMHO.

Even easier, because at least back in 1988-1992 when I used C++, even the C part was "not quite C". I don't even care to remember exactly what the differences were. I think parameter prototypes were off by one.

Whereas with ObjC, if you aren't declaring objects or sending messages, then, dagummit, you're just using the actual ANSI C compiler.

if you do take advantage of objects in Objective-C, you are, perforce, faced with a different paradigm than in C++. Feature or bug? This is where the disconnect lies, IMHO

Yes, I find the visual distinction beneficial. But I was a Smalltalk programmer before I used ObjC, and the syntax is the same.

Actually, Stepstone did sell an ObjC system on other platforms, specifically Windows. It included a class library called ICPak. I've never run across anyone who used it.

For an interesting take on embedding C into a scripting language (a reversal), see http://mini.net/tcl/critcl

A couple of years ago I wrote an important part of a desktop app (used by network operators to setup/monitor satellite modems) in Tcl/Tk. I was able to get a working system into the hands of the operators quicker than anything I could have done in MFC/C++ (shudder).

When I resigned from the company, I took 3 days to teach the remaining developers how to maintain my Tcl/Tk code. A few months after I left they decided to throw away all of my code and rewrite it in MFC/C++. As best I could tell, the reason was because they thought they could attract more programmers with MFC/C++ and not Tcl. This may be true, but they rewrote working/deployed code. They rewrote working/deployed code.

Now, Tcl ain't no Lisp, but its pretty easy to learn and my code was pretty clear.

I think a lot of this has to do with following language fashion trends. Tcl isn't sexy. Lisp isn't sexy. Erlang isn't sexy. Now, Java --- oooh baby. I've worked with developers who wouldn't want touch a task if they didn't get to use a language that would keep them employed...

This is something I observed too.

An organisation had an in house language that was tailored for kind of applications the clients expected and wanted. Development was quite efficient, due to built in logic, libraries etc.

But programmers hated to work on these projects (at least that's what they claimed) since they all knew that when the go job huniting, being an expert programmer in house language isn't going to win them any points.

The amusing thing is that many dollars later, programmers are complaining about Oracle, PL/SQL etc. -- the in house language was so much easier to use, and the applications so much more reliable...

Stories like these highlight an important problem. Programmers are the only one qualified to make decisions on porogramming languages, tools and so on, but for the same reasons they are the ones that tend to have conflicts of interests regarding such matters.

Some musicians will choose a particular instrument (or type of instrument) and after mastering it will seek to play music that involves only that type of instrument (or even attempt to adapt the music to the instrument).

Some composers will write music and choose the best (or most interesting) instruments by which to realize the composition.

Now, some musicians are composers (and most all composers are musicians).

Some musicians will take a composition that specifies an instrument that may seem unusual and take great joy in trying the piece with such an instrument. They are sometimes called multi-instrumentalists.

The software industry has its composers; it has its musicians. I think it needs more multi-instrumentalists.

I think a key part of selling a language is recruiting influential application developers whose APIs will draw more developers. This is the Microsoft way, after all. It also worked for Emacs, Autocad, et al. with Lisp. It's working for Apple with Cocoa itself being in ObjC, as Paul points out. It worked for JavaScript in browsers.

This was a tactic the Smalltalk and Lisp vendors failed to act on, to my knowledge, because they just thought they had better languages and IDEs.

But those other languages and IDEs have more customers, and they've caught up a lot of mileage over the years.

I agree. But we also need a better programming model for a multi-language concert than just WS Orchestration!

8^)

decisions on programming languages
Hopefully there's a technical lead capable of analyzing what the trade-offs are for different programming languages, and providing technical recommendations to business managers. At that point isn't it just another business decision that requires information on marketing and sales impact, on costs, on possible hiring issues... and should therefore be made by suitably informed business managers?

But see: How to Interview a Programmer

Programmers are the only one qualified to make decisions on programming languages, tools and so on

I have to disagree. Programmers master one important dimension of the decision matrix: technical suitability. There are several important aspects, including availability of resource, cost, cost of resource, etc. These decisions need to be made in a partnership between developers and management.

Don't get me wrong, I'm quite in favor of functional languages and LISP is the only one I'm really competent in (although I'm having fun experimenting in OCAML).

With respect to the Yahoo Store experience, my guess is that management wasn't the real enemy of LISP. Management was probably told that C++ was better by technical types who are C++ enthusiasts (see, I didn't say "bigots" ... ooops).

There is a reasonable chance this is what happened. I've found very little rigor among programmers over 20+ years, in either programming or in general decision making.

Going back to about 1988, Mentor Graphics backed into a decision that nearly sunk the company and certainly altered its course significantly for the worse. A few technical types, of the sort mentioned above, "decided" (and I use the term lightly) that C++ was the *only* technology that could be used to develop their next generation digital CAD tools.

Bear in mind in 1988 C++ meant "cfront", a pre-processor for C, generated poor code, no debugging capabilities, name mangling, cost oodles of $$$, and no relevant (to MGC) software had been developed using it. And so MGC literally bet the company on it.

The bad decisions neither began nor ended with the decision to use C++. But this specific decision was the pinnacle of bad decisions, and the prototype of decisions made without rigor at that time.

The Mentor Graphics experience with C++ became a punching bag for Ralph Johnson's framework talks, who was over the next five years or so to become the authority on building frameworks, even with C++.

I should add that the MGC story was covered by Grady Booch in his book, Object Solutions. I don't know who gave him the stories, but they certainly reflected the positions of someone with something to hide. Things were much worse and not much related to the stories in the book.

Gerry Langeler, the president of MGC, (with a chemistry and marketing background, BTW, not electronics or software), was the manager who listened to the wrong people without evidence and went on to make a few bad decisions of his own. He wrote up his experiences in the March 1992 Harvard Business Review article "The Vision Trap". Needless to say he got the stories way wrong too, and he was the ultimate decision maker at the time.

Royally pissed off the chairman/CEO, when he got up to speed on all that was sinking the company very quickly, it seemed, a couple of years later. Mentor Graphics does not develop much software anymore. They mostly buy startups, incorporate them into the product portfolio, and help customers use them.

My stock tanked. Langer continued to be wealthy. He is now a hi-tech venture capitalist. Tom Bruggerre, the chairman/CEO, ran for the US Senate from Oregon in 1996 and was trounced.

Which is all more than you wanted to read, but I had never written this down before. And so LtU is the archive of my take on this adventure with bad language decisions.

Emacs (Lisp), TeX (macros), AutoCAD (Lisp), Web Browsers (HTML), AOLServer (Tcl), Apache(PHP/Perl/etc), many modern games, etc.

Interestingly, OO doesn't emphasize using higher level language constructs.... A difference between classic OO approach and a language based approach as encouraged by languages like Lisp and Forth (and to a lesser extent Tcl): With OO, you model your problem as a collection of interacting thingies. While in Lisp/Forth you define a (domain specific) language in which to best express the solution to your problem. You create the language by extending/modifying your language toolkit. Then you solve the problem.

Good point. The interesting thing about Smalltalk is that due to simple syntax, especially for closures and keyword parameters, the result can sometimes draw very close to being a "domain specific language".

Other OO languages with more complex syntax and little if any support for closures, are more cumbersome for "seeing the domain" in the objects.

It abuses C++ through templates and operator overloading to allow you to specify an approximate to EBNF in compilable C++. In this respect, if your job is to build parsers, Spirit extends C++ to allow you to concentrate on EBNF syntax...

EBNF :

group ::= '(' expression ')' factor ::= integer | group term ::= factor (('*' factor) | ('/' factor))* expression ::= term (('+' term) | ('-' term))*

Spirit :

group = '(' >> expression >> ')'; factor = integer | group; term = factor >> *(('*' >> factor) | ('/' >> factor)); expression = term >> *(('+' >> term) | ('-' >> term));

But, is it a good idea?

In general, no it's not. This is kind of like what mathematicians call "abuse of notation"

Others mentioned that extending ST is easier. The same, of course, is true about Scheme.

The uniformity of Scheme's and ST's syntax, makes building DSEL so much easier.

This is a good example why designing language syntax can be as important as thinking about the semantics.

Must admit I've yet to read Coplien's books. I'm currently reading Andrei Alexandrescu's "Modern C++ Design", and that (plus a couple of article in C++ Users Journal) is what inspired my reply.

Obviously this technique is not the only method in C++ that allows you to define domain specific objects. Indeed some might find it esoteric and obtuse. I find it appealing because it provides a straightforward mechanism to tailor generic classes to your precise needs. As Alexandrescu puts it, to have to compiler act as a code generator.

If find this very cool because it seems like a natural way (from the C++ language perspective (unlike Spirit IMO) to build a sort of DSL inside your C++ application. And it is type-checked by the compiler.

The downside, as I mentioned above, is that the C++ templates syntax makes such meta programming (dubbed MetaC++ by a C++ User Journal editor) rather difficult. This may simply be the result of the fact that such usage of the mechanism was perhaps not foreseen by its creators. OTOH if that is the case, the fact that it does work is doubly intriguing.

I am not familiar with Alexandrescu's work, so I can only guess what he is talking about (but you can provide links and examples, can't you?)

Many Haskell DSEL examples use algebraic datatypes to model the language, I assume using C++ classes is similar.

But, is it a good idea?

I'm going to disagree with Ehud here and say, yes, it is a good idea. It strikes me as hypocritical to say that embedding DSLs in your underlying language is a good idea, and then to criticize Spirit for doing precisely that. Besides, there's so much more to Spirit than just the EBNF-in-C++ aspect (I'm thinking of dynamic parsers, its LL(inf) capabilities, and its integration with the Phoenix functional-programming-in-C++ features in particular).

To the extent that programming consists of abstracting away from irrlelevant detail while simultaneously providing increasing levels of expressive power, Spirit succeeds admirably for those of us engaged in language implementation tasks in C++.

I wasn't talking specifically about Spirit, I was talking about the general issue.

I think DSELs can be very useful, but one of the things I want them to help with is maintenance ("Little Languages, Little Maintenance"). Using language "tricks" tends to result in code that is harder to maintain.

I would agree that the problem is usually one for the library writer, who is supposed to feel comfortable with this sort of programming style, and the application programmer is free from thinking about the template, operator loading and other hacks.

But this only goes so far. When something doesn't compile, or when you start working the debugger, the lines blur. [BTW, this is something for language designers to work on.]

Like I said, I general such tricks are problematic. But there are cases where sound software engineering would lead you to use them.

Todd Coram: With OO, you model your problem as a collection of interacting thingies. While in Lisp/Forth you define a (domain specific) language in which to best express the solution to your problem.

Taken together with Greenspun's Tenth Rule of Programming, this means any sufficiently complex software includes an implementation of a Lisp interpreter that runs a Lisp program written so that it may execute programs in another language altogether.