Lambda the Ultimate

I don't know that academia has a distaste for pointers -- think of all the "academic" languages that use unified representation! -- but there does seem to be a preference for implicit pointers. Which is fine with me.

More seriously, if the documents are "elaborate", it might suggest that the language design might be flawed, or it may suggest a design criterion which could not be avoided, or it might suggest a degree of freedom that carries with it some measure of responsibility.

Consider something as simple as layout, which is something that you'd find in any style document, elaborate or otherwise. Any text-based language is either extremely rigid in its layout rules, or it's going to need some kind of style document to ensure that a team of programmers stays consistent.

On the other hand, there's the style document clause which basically says "don't use this large part of the language". Something like "don't use unsafePerformIO in Haskell" one might feel to be perfectly understandable. It's there for emergency use only.

Suppose, on the other hand, that the Haskell standard still mandated that implementations support continuation-based IO for backwards compatability. Wouldn't a style guide which said "don't use this; use monadic IO instead" be perfectly reasonable? Does it suggest a flaw in the language design? Arguably, yes, it does. Monadic IO is certainly a far better design than continuation-based IO. But it would be there for a reason, such as that Haskell programs from 1992 should still work with minimal porting.

Incidentally, on the topic of include files including include files, you can get pretty much all of the speed benefit by guarding each #include. This way, if you don't need to #include a header file, it never gets read. This sort of thing:

foo.h:
#if !defined(FOO_H)
#define FOO_H
/* stuff */
#endif

bar.h:
#if !defined(BAR_H)
#define BAR_H

#if !defined(FOO_H)
#include "foo.h"
#endif

/* stuff */
#endif

Are there programming languages that wouldn't benefit from checklists and style documents?

I was going to whole-heartedly support this statement, given my Donald A. Norman design philosopy: a well-designed object is one that helps the user find its intended use.

However, I can't imagine a language of any power that could prevent crap code (for example, obfuscated naming), or even make it harder to write than good code.

So, it seems to me that a clarification of the claim would need to be something like: A well-designed language should have: 1) a well-defined, easy-to-follow style that is the norm in that language community, and which can be learned and emulated without having to resort to style guides or checklists 2) no features that encourage or require bad style

To be fair, I can't think of ANY language that has property 1, though most communities have a couple of competing styles that almost comply.

Equally, I can't think of any general-purpose languages that don't have some violations of 2. For example:

Lisp - encourages use of macros to solve problems that only exist due to cumbersome syntax.

Java - requires (until 1.5) violation of type-safety in order to use ubiquitous Collection library.

Python - allows and encourages unmarked violations of the Open-Closed Principle

I'm sure I could go on and find an example for any language we could mention.

Assuming this principle, are there ANY general-purpose languages that are well-designed?

Presumably you mean "encourages use of macros to solve problems that only exist due to the desire to add cumbersome syntax."

Slightly more seriously, if this is your most damning criticism of Lisp, then it's quite obviously time to start programming in Lisp again. But as I told another friend, I've all but left dynamic typing behind—the only language I'm currently interested in that uses it is Oz, and it makes up for it with all of the rest of its positive features—so for now I'm sticking with O'Caml, which really, truly does seem like the "alternative language" that can serve, today, in the stead of C or C++.

Sure. But notice that I said elaborate style documents. By this I meant to say more than is strictly necessary. Obviously, this is a bit circular, but I am sure everyone understands what I am trying to say, namely that if the language itself needs to be protected from, there's something wrong with it.

Aren't you glad I gave you an opening to say that? ;-)

Actually, I would very much like to. I downloaded a tutorial a while back, and also picked up a remaindered book (by Robert G. Clark), but unfortunately I haven't made much headway.

Can you recommend a paper entitled something like: "An introduction to the features that make Ada stylistically consistent for a PLT geek with too little time to learn the whole language"? ;-)

carl

http://www.adapower.com/learn/adadistilled.html

I certainly wasn't trying to offer a comprehensive critique of Lisp or any other language. ;-)

One thing this thread has got me thinking about is the degree to which lack of consistency in PL styles is brought about as a phenomenon of the language community.

It seems that any language that gets reasonably popular inevitably comes under fire from a "freedom to program the way I want" constituency that will demand features that were deliberately left out of the original design. (The "Java needs macros" crowd comes to mind as an example... )

Can any language have both a wide and varied user community, and a single consistent style? (Maybe Ada.... ;-))

The Ada Steelman document, which defined the fundamental requirements from the (original) language is also worth a look. Some of the relevant sections are 1c (Maintainability), 2c (Syntactic Extensions), 2d, 4a (Form of Expressions), 4f (Operator Precedence Levels), 6a (Basic Control Facility), 7a (Function and Procedure Definitions) and 13c (Completeness of Implementations).

Notice that many of these requirements restrict the language is various ways (now macros, or first class continuations in Ada, for example). For good or bad, this was a conscious design decision, favoring readability and consistency over raw expressiveness.

Well, I do know what you mean, but I suppose I would still feel better if we could come up with a slightly more defined meaning for "strictly necessary".

One programmer's stylistic sin is often another's stylistic virtue, so we really need some shared boundaries to examine this problem meaningfully.

I'd love to use O'Caml, but I need overloading and implicit type casting! C++ needs some things O'Caml has (local functions), and could use some others (easier polymorphic functions, duck typing), but we C++ users have hacks to get by (Boost Lambda Library).

I'm more interested in extracting out the subjective to see if there is anything potentially objective and well-defined underneath.

For example, "meaningful naming". Most people like it, but it is highly subjective, and you can't often enforce it in a compiler.

So any language that wants to promote it would have to add that to a style guide.

On the other hand, a closed syntax is a design choice that could be enforced by a compiler or interpreter. If you choose not to have a closed syntax, then you can't help but add to the style guide if you still want a somewhat consistent style.

So if anyone accepts the "smallest possible style guide" criterion, they would also have to accept that closed syntax is a better design.

That's the sort of thing I have in mind.

"clear use of function pointers is the heart of object­ oriented programming" ?!

I hope he's happy now "the tyranny of Pascal is that beginners don't use function pointers" has been overcome in Oberon-2.

Notice that naming is not only subjective but also project dependent. IEFBR14 sounds like a meaningless name, until you realize that IEF* is the prefix of all the programs and codes belonging to a specific OS component, and that BR 14 is the ASM/370 code to return control to the caller. Thus the name tells you that this is the null program! It, in fact, contains 50% of the executable code.

Presumably by "overloading" you mean "generic functions." Keep an eye on <http://pauillac.inria.fr/~furuse/generics>. Now that 3.07 is out, we should expect more progress.

As for implicit type casting, I strongly disagree. That's more a source of trouble in C++ than a source of solutions. A type for everything, and everything of a type, I say. Now of course, it should all be inferred, and thanks to variant types, you can almost certainly achieve what you need anyway.

Finally, I am a huge fan of Boost, Lambda/Phoenix (part of the Spirit parser generator framework), and FC++. They make C++... almost barely tolerable.

Perhaps you need them, but does your software need them?

When I was a BASIC programmer, I thought line numbers, goto, structured loops and assignment were indispensible. Then I became a C programmer, abandoned line numbers, and convinced myself typecasting and function pointers were indispensible. Then I became a C++ programmer, abandoned typecasting and and became convinced overloading and classes were indispensible. Then I became a Haskell programmer, and abandoned function pointers, classes, goto, assignment and structured loops. Then I became a Generic Haskell programmer and abandoned overloading (type classes).

Strangely enough, I've still been able to write the same kinds of software in all these languages, and my programs are now shorter, more readable and more reliable (though, sadly, not always faster :).

Notice that naming is not only subjective but also project dependent.

Is there any formal work on the question of how best to construct the names one uses for nouns, verbs, adverbs, adjectives, etc? I'm thinking along the lines of both maximum communication, as well as contributing to formalism?

(BTW, it's probably best not to think of these types of things while one is masticating). :-)

G'Caml is missing some important features, like object support, and the possibility of not respecifying the whole function everytime one wished to extend its domain.

"The one thing it [Lisp] has going against it is that it is not a crystallization of style. The people who use it must have a great deal of personal style themselves."

"Pascal was the guy who said, "Please forgive the length of this letter. I didn't have the time to make it shorter." That is a very classy statement. There is no element of that class in the language PASCAL."

And now something to antagonize Ehud :)

"Ada was the first programmer. She said the analytical engine weaves algebraic patterns just as the jacquard loom weaves flowers and leaves. This is a very classy statement. You find none of that class in ADA."

(pp. 173-174).

But I think this is the most insightful (and in my opinion, the correct) view he expresses on the language-style relationship:

"There are two kinds of programming languages: ones that are basically accretions of features like PL/1 and ADA, that are never finished being defined, and ones that are basically crystallizations of styles, like SMALLTALK. Pick a good style for doing something, and make that into a language. People will tend to do things in the style that the language encourages. A programming language of that kind is very close to a kit. But the problem with a kit is that in order to make certain things easy, you prevent other things from being done at all."

(p. 172)

No. Lisp macros provide one more aspect of software design, which is absent in most other languages. It has nothing to do with Lisp syntax, be it cumbersome or not: witness Dylan or Goo, who have AST-manipulating mechanisms serving similar purpose.

What new dimension does this bring to software design that couldn't be done "less expensively" with less powerful abstraction mechanism?

The only unique problem that macros solve, as far as I can see, is syntax transformation.

My post was not intended to suggest that there is a linear `fitness' relationship between programming languages, only that I encountered some programming languages in a particular order. What you say reminds me of the attitude of aspect-oriented programming people, who seem to have become convinced that OO was the only possible evolution of procedural programming, and that there is likewise a single possible `successor' to OOP languages (and that they have found it).

Inasmuch as GH is a superlanguage of Haskell, we can say it is an improvement. But I don't think there is a well-defined `next step'. That said, of course I think that the sort of datakind abstractions and type-level computations I envision for Arrow are a natural direction to extend GH-style generic programming.