Lambda the Ultimate

To me, a design philosophy would be about making hard choices: what do you ruthlessly abandon no matter who pushes for it because it would weaken the overall design.

Saying that everybody came together in peace and harmony to produce a great standard is basically saying that they stuck whatever crap anyone wanted in there, and that Bjarne wasn't the designer so much as the cheerleader for the process.

Personally, I see design as a much more focused and disciplined activity, and am concerned that the most well-known PL designers (in the wider community, anyway)(e.g. Stroustrup, Wall) don't admit to doing it.

Surely you mean kittens?

To me, a design philosophy would be about making hard choices: what do you ruthlessly abandon no matter who pushes for it because it would weaken the overall design.

I don't think an explicit example of what you would abandon would constitute design philosophy, it would be too specific. Rather design philosophy would be that you would do this.

I can actually think of a great example where Stroustrup did just that: the C++ variable declaration syntax. He knew it was deficient, he himself wanted to change it but didn't because part of the overall design was to retain C compatibility as much as possible.

I think that saying the language support for library design comes before other things is quite important. It is also fairly easy to check whether a language lives up to this goal.

I don't. This is just saying that a language should have abstraction features which are as expressive as possible.

Well, on second thought, there are some people (incredibly) who don't share this philosophy, for example Larry Wall and Guido van Rossum.

Since some of them may have efficiency issues (closures, continuations for abstracting control) going for "expressive as possible" can be quite a big deal.

Properly designed restrictions on what can be expressed increase the strength of the invariants you have about the program, and can make reasoning about the program much easier. Eg, the compositionality of purely functional code makes building complex programs much easier. The trick, of course, is to find a set of restrictions that don't prevent people from writing useful programs while at the same time providing hackers with strong invariants.

For me the issue is that I think we still don't have maximally expressive abstraction features. I think we are still thinking about what these may be (e.g., high order modules etc.)

But it all comes down to the same thing. My maximally expressive abstraction features would express strong invariants of the sort you are talking about.

Please note that in the above I use the term 'abstraction' in its widest possible sense.

I believe that most such features can be implemented in a disciplined way that does not affect efficiency unless the problem is inherently inefficient (complexity-wise). For example, linear (one-shot) and escaping continuations can be implemented efficiently; this is what the programmer should use unless the problem demands otherwise.

Neel: I don't want maximally expressive abstraction features, either. For example, in my ideal programming language, you would get fold and unfold recursion operators when you define a new datatype, but you wouldn't be allowed to define arbitrary recursive functions on those types. Instead, the recursive function operator would instead generate values of a monadic type representing potentially non-terminating computations, or something along those lines.

Me too! Brian Howard used an idea of Freyd's to design a type system which does precisely what you want. I guess your definition of "expressiveness" is different from mine since, In my opinion, such a language is more expressive (in this respect) than a language like Haskell, which conflates inductive, coinductive and pointed types.

Properly designed restrictions on what can be expressed increase the strength of the invariants you have about the program, and can make reasoning about the program much easier.

Than we're in agreement, because my notion of an expressive language is one which allows you to express more static invariants (`restrictions').

There was a philosophical choice to create a new PL as an extension to an existing popular PL, and to avoid any PL features that conflict with this choice regardless of how desirable they might be. Stroustrup is repeatedly asked how differently would he have made C++ if he hadn't chosen to make it as compatible as possible with C. His answer is that the question is not relevant. If not C, he would have chosen some other PL to build on. His intention was never to create a wholly new PL, rather to extend an existing one with new capabilities.

This philosophical design choice is very interesting when you compare to other PLs:

1. Build something completely new.
2. Build something new, but give it syntax and semantics that are similar to existing PLs.
3. Build something new, but make it compatible with an existing PL-specific VM/framework/type system.
4. Build something new, but barrow specific functions from existing PLs/tools
5. Build something that is the same as existing PLs but change the syntax so that it appears to be new.

Sure... let's throw kittens in there too. ;-)

The essential feature of abstraction is forgetting things: having a typed language means that you "forget" that that all values are really just bit-patterns in memory. This means that certain operations become impossible -- for example, you can't treat an integer as a pointer -- and the assumptions you can make about the program's state get correspondingly stronger. This is profoundly useful; so useful that I'd refuse to write programs in a language where I couldn't forget this fact. (Aside: here, I'm considering safe, dynamically typed languages as uni-typed languages with the trivial static type system.)

But it does reduce expressiveness, because certain useful programs become impossible to write. For example, in Scheme or ML you can no longer write a doubly-linked list that uses the XOR-pointer trick to encode the forward and back pointer in a single word. You can prove this is safe, but you can't code it up in ML.

The utility of a type system -- or any other abstraction -- is as much in what it excludes as what it permits, because each abstraction is an assertion about what facts you can profitably forget. A powerful abstraction is one that lets me forget a great deal while still permitting me to write the programs that I am interested in.

"Don't you see that the whole aim of Newspeak is to narrow the range of thought? In the end we shall make thoughtcrime literally impossible, because there will be no words in which to express it. Every concept that can ever be needed, will be expressed by exactly one word, with its meaning rigidly defined and all its subsidiary meanings rubbed out and forgotten."

Of course expressiveness must be circumscribed. Immoderate discipline is the price of security. Sure expressing mathematics would be nice. But who uses or even understands all that stuff. We don't even need Real numbers - we can fake it just fine. And who needs nondeterminacy. And parallelism is just a deadly can of worms. Oh, and memory. Yipes! Fortunately instead of trying to reason about it, we are removing the words to express it. State in general has to go of course. If the compiler can't prove the safety of your thoughts, it shouldn't allow you to express them.

... Why does so much of language design raise my premature optimization and design preemption hackles. Perhaps, maybe, we should wait until after our systems can toddle before we break their kneecaps?

I recommend that you [re]read The Design and Evolution of C++. It clearly contradicts your slanderous speculation, because it discusses several extensions that were not accepted.

Good abstraction mechanisms (think information hiding) enforce abstraction boundaries, and helps the programmer enforce invariants.

I'm starting to think that some of my honorable colleagues are unaware of a fundamental principle when it comes to discussing particular documents in a forum such as this.

Each paper must stand or fall on its own.

Telling me to go read something you think supports your point of view better might have interest on its own, but it does not do anything to improve or detract from the document under discussion.

Furthermore, the issue is not that nothing was ever rejected. I was discussing design philosophy: I want to hear a statement of principle about why in general things should be rejected (or accepted), at least in the context of a particular language.

As to slander, the two most recent documents that I have read that report Mr. Stroustrup's point of view as a designer have articulated views (or lack their of) that I would not consider worthy for a designer of PLs (or of anything else) to emulate. Hence I will not applaud or recommend them.

So pardon me if I don't run out and read "Apologia Pro Sua PL", oops, I mean "Design and Evolution of C++" anytime soon when I already have a stack of more worthy documents (some concerning design) to consider.

Indeed. I can think of at least three ways to interpret it in the way it is used around LtU:

1) the number of concepts or constructs that can be handled directly by the primitives of the language

2) the number of concepts or constructs that can be derived by some combination of those primitives

3) the "semantic density" of the primitives; this is akin to the concept of "power" that some language afficionados talk about.

A fourth possibility, if I may be permitted a human factor ;-), the perceived elegance or elequence of the primitives (or perhaps their syntactic manifestations).

Unless we narrow down what what we mean by the term in a given instance, we may not be able to discuss it meaningfully.

Marc, you are not the first person I have encountered that has a problem with admitting making faulty assumptions. In the future I will refrain from trying to correct your erroneous assumptions so you can remain happily ignorant.

For the rest of the LtU crowd, sorry for the noise generated by the quarrel.

Sure. But a paper may be really bad, without the author being an idiot. Check the context (web interview, foreward for a book etc.)

I am no C++ fan, but I think reading about the design of C++ can be worthwhile.

Vesa you make the rather bold assumption that I know nothing about C++ or its history.

If you think that Stroustrup has a wonderful design philosophy, please articulate it here for us to discuss. If you can make a good enough case, I will be glad to concede.

Suggesting, however, that my opinion is faulty because I haven't read the right book is more than a little patronizing, and does nothing for our understanding of programming languages or their design.

I agree completely. I also don't think Stroustrup is an idiot or anything close.

I just don't agree with his approach to being a designer as he has stated it in the last couple pieces (and others I have read before, going way back).

I am concerned that the practice of critical discourse may have become so weak that the only way my disagreement can be accounted for is to assume that I am utterly ignorant of C++, its history and how important Stroustrup is.

I may disagree strongly and vocally with his views but I have no reason to attack Stroustrup the person. Stroustrup the idol, though, is fair game... ;-)

Given that Stroustrup found the need to write a whole book about it, I don't think anybody here can do his philosophy justice by rendering it as a short post on LtU.

Agreed. I have no interest to spend time squeezing the essence of a ~400 page book into a single post. What is clear to me, however, is that Stroustrup has given thought to various design alternatives and that he has also recognized his own limitations - he never set out to design a perfect language. He also knows very well that C++ is not perfect.

To me the essense of design is generating and trying alternatives, analyzing the results of experimentation and then making hard design decisions. C++ was designed over a very long period of time and many design decisions that did not turn out to be "optimal" could not easily be corrected when the problems were obvious. Does this indicate lack of sufficient analysis? Perhaps to some extent, but as a designer I know how hard it is to get things right while at the same time you need to make some progress.

...

The one thing everyone should know about ignorance is that you never know yourself when you are ignorant - that is what ignorance is all about. The cure for ignorance is careful analysis - checking the validity of all assumptions. Analysis is the basis of scientific thinking. The cure for ignorance is not creative synthesis (drawing creative conclusions based on invalid assumptions), but the most ignorant always seem to assume that their synthesis is flawless. The reason why the ignorant think that their synthesis is flawless is that they haven't done (and often don't know how to do) the analysis required to discover their faulty assumptions.

...

To me, being critical is the same as being analytical. To be critical is not the same as boosting your ego by generating slanderous bullshit based on faulty assumptions.

...

What I would like to see, is that Marc proves that his assumptions were correct, that Stroustrup was the "cheerleader" for the design process and that whatever "crap" was suggested was also accepted into the design of C++. I'm sure Marc will try to find ways to argue that I should be doing the proofs. Besides, I also already provided the hint on where to find the proof and also a one line summary of the essense of the proof, which is a proof by counterexample - in case you missed it. For the logicians out there, proof by counterexample is valid in this case because of the (essentially) universal quantifier that Marc used.

Neel, there is `forgetting' and then there is `forgetting'. If I forget the do-while construct in C I don't decrease its expressiveness. Some coordinatizations are redundant: if I remove a vector from a basis for a vector space, I may still be able to denote every point in the space. If I remove 0 from the set of naturals, the resulting set is still isomorphic to the naturals, and can serve as well. (Think about 2's complement encoding.)

This means that certain operations become impossible -- for example, you can't treat an integer as a pointer -- and the assumptions you can make about the program's state get correspondingly stronger.

Only inessential operations.

But it does reduce expressiveness, because certain useful programs become impossible to write.

No, they don't. Turing completeness of a language contradicts this claim. What happens, rather, is that certain programs become writeable in different ways.

Look at it this way: the compiler is a mapping between programs written in a programming language and programs written in machine language. It is unlikely to be one-to-one or even surjective or injective; but it is guaranteed to have as image a Turing-complete sublanguage of machine language, a core. Since machine language as a whole is no more than Turing-complete, every program written in machine language is observationally equivalent to one written in the core. Programs in the core may be less efficient, it's true; but that is not a fault of the language itself, but rather the compiler, the mapping.

So typing is not the problem here. Indeed, everything you claimed you could equally well have been claimed for dynamically checked languages, right?

The utility of a type system -- or any other abstraction -- is as much in what it excludes as what it permits, because each abstraction is an assertion about what facts you can profitably forget. A powerful abstraction is one that lets me forget a great deal while still permitting me to write the programs that I am interested in.

The abstractions which are available in functional languages are (almost?) all of the sort which do not forget essential information. This is clear from the fact that adding products and exponentials to a (certain sort of) language are conservative (free) extensions. (I'm not so sure about sums and recursion.)

Conventional typed OOP languages, OTOH, are generally rife with abstraction mechanisms which do forget essential information: subsumption is an example.

I certainly don't rule out reading Stroustrup's book at some time in the future, but it would be helpful to get a general sense of what his position is, at least for discussion purposes on LtU if no other.

If he does have a coherent design philosophy (as distinct from a rationale for why he did things), it seems to me that should be a pithy way to sum it up in broad strokes. Perhaps as small set of guiding principles or goals would do.

If it really takes a case by case analysis over a whole book to get a sense of it, I would have to argue that it isn't really a design philosophy but a series of independent design decisions that can't be extracted from context or generalized.

Here are a few choice quotes:

C++ was designed to provide Simula's facilities for program organization together with C's efficiency and flexibility for systems programming. It was intended to deliver that to real projects within half a year of the idea. It succeeded.

At the time, mid-1979, neither the modesty nor the preposterousness of that goal was realized. The goal was modest in that it did not involve innovation, and preposterous in both its time scale and its Draconian demands on efficiency and flexibility. While a modest amount of innovation did emerge over the years, efficiency and flexibility have been maintained without compromise. While the goals for C++ have been refined, elaborated, and made more explicit over the years, C++ as used today directly reflects its original aims.

and

One conclusion I drew from the wildly divergent comments on the HOPL-2 paper – and from many other sources – is that there is no agreement on what a programming language really is and what its main purpose is supposed to be. Is a programming language a tool for instructing machines? A means of communicating between programmers? A vehicle for expressing high-level designs? A notation for algorithms? A way of expressing relationships between concepts? A tool for experimentation? A means of controlling computerized devices? My view is that a general-purpose programming language must be all of those to serve its diverse set of users. The only thing a language cannot be – and survive – is a mere collection of "neat" features.

The difference in opinions reflects differing views of what computer science is and how languages ought to be designed. Ought computer science be a branch of mathematics? Of engineering? Of architecture? Of art? Of biology? Of sociology? Of philosophy? Alternatively, does it borrow techniques and approaches from all of these disciplines? I think so.

This implies that language design parts ways from the "purer" and more abstract disciplines such as mathematics and philosophy. To serve its users, a general-purpose programming language must be eclectic and take many practical and sociological factors into account. In particular, every language is designed to solve a particular set of problems at a particular time according to the understanding of a particular group of people. From this initial design, it grows to meet new demands and reflects new understandings of problems and of tools and techniques for solving them. This view is pragmatic, yet not unprincipled. It is my firm belief that all successful languages are grown and not merely designed from first principles. Principles underlie the first design and guide the further evolution of the language. However, even principles evolve.

The book obviously contains a lot more.

I think you have the right of it there, Marc. This is a difference between local and global decision-making, and between doing things that seem intuitively right or correct, even when based on certain contextual data, and doing things for clearly elucidable purposes. Even the most brilliant person, who always makes the `right' decision, perhaps cannot be said to have a design philosophy if they can't extract it from context.

Whether this applies to Stroustrup (one way or the other), I don't know, though.

My view is that a general-purpose programming language must be all of those to serve its diverse set of users.

1. A general-purpose PL must be all things to all people.

Alternatively, does it borrow techniques and approaches from all of these disciplines? I think so.

2. PL design is multi-disciplinary.

It is my firm belief that all successful languages are grown and not merely designed from first principles

3. PLs are best constructed through evolutionary design.

I heartily agree with 2 and 3. My tendency to consider "human factors" comes from my feeling that 2 is so.

I think disciplined evolutionary design is the best way to build all complex systems, since it is impossible to anticipate every detail of how something will be used.

So I guess I two-thirds agree with Stroustrup's design philosophy. ;-)

It is really the first point that I strongly disagree with.

To be successful is often determined by what you sacrifice more than what you do. Trying to please all people and all goals at the same time leads to overly complex designs and ineffective solutions.

I think this is one of the fundamental problems with software development and why there are so many failed projects: a tendency to guild the lily and dream what "would be great if...".

I think the key problems that exist in C++ are a result of this desire to cover all angles.

In particular, the "too low level/too OO" behaviour he ascribes to C++ programmers in the Artima interview is a direct result of this "all things to all people" philosophy.

In this sense, he is directly responsible for the behaviour he is criticizing as a fundamental consequence of his design choices.

I don't point this out to pick on him, but rather to stimulate thought and discussion about the effects of design philosopy on PL design.