Lambda the Ultimate

inactiveTopic Language Myths
started 4/22/2002; 6:46:21 AM - last post 4/26/2002; 4:49:19 AM
Ehud Lamm - Language Myths  blueArrow
4/22/2002; 6:46:21 AM (reads: 4190, responses: 23)
Language Myths
Language Myths by Laurie Bauer (Editor), Peter Trudgill (Editor). 208 pages Penguin USA (Paper). September 1999.

I've been meaning to mention this book for quite awhile now. The book is a collection of essays on various language myths . Myths as in 'well established ideas that are not quite correct'. The essays are quite opinionated. To quote the introduction: If they think that the idea is wrong, they have said so. If they think it is based on a false premise, they have said so. If they think that people may not realize where the idea comes from, they have explained this.

To give an idea of the scope of this fairly short book, here are some of the titles from the table of contents: Some Languages are Just Not Good Enough; English spelling is Kattastroffik; Women Talk Too Much; Some Languages Have No Grammer.

Many of the essays deal with social issues related to language (Socio-linguistics). Alas, this results in many repetitions of the same ideas. Some of the essays, so it seems, are more statements of personal conviction than professional discussions of contested issues.

Still, the book is worth checking out if you are interested language. (I particularly enjoyed the essay on Aboriginie languages.)

I wonder how a book similar to this one but focused on programming languages would look like. I agree with the premise given in the introduction that users do not need to have a conscious knowledge of how a system works in order to exploit it. Explanations of the system require the type of knowledge that only the specialist can provide. That's why I think a book like this one only containing essays by programming language specialists, may be quite interesting.

What topics would such a book cover?

1. OOP is best design methodology 2. Static typing reduces programming speed 3. Java/C++/C is the best programming language ever designed. 4. C is faster than Scheme 5. All programming languages are basically the same.

I am waiting to hear suggestions for other chapter titles...

Posted to Misc-Books by Ehud Lamm on 4/22/02; 6:51:44 AM

Ehud Lamm - Re: Language Myths  blueArrow
4/22/2002; 7:46:30 AM (reads: 3339, responses: 0)
6. An OOPL must have a class construct

Jay Han - Re: Language Myths  blueArrow
4/22/2002; 7:52:06 AM (reads: 3342, responses: 1)
7. Real Men don't need GC.

Ehud Lamm - Re: Language Myths  blueArrow
4/22/2002; 8:35:49 AM (reads: 3435, responses: 0)
That was the next one I was going to mention (with less colorful language, I must admit). So how about:

8. To be a proffesional programmer it is enough to know one language well.

Dan Shappir - Re: Language Myths  blueArrow
4/22/2002; 9:29:35 AM (reads: 3896, responses: 1)
9. C is faster than C++
10. Hand coded assembly is always the fastest
11. exceptions are bad

Ehud Lamm - Re: Language Myths  blueArrow
4/22/2002; 9:34:12 AM (reads: 3680, responses: 0)
11. exceptions are bad

Does anyone really think so?

Jay Han - Re: Language Myths  blueArrow
4/22/2002; 12:30:49 PM (reads: 3309, responses: 0)
some new languages (born after the web) still prefer error codes to exceptions.

scruzia - Re: Language Myths  blueArrow
4/22/2002; 4:17:26 PM (reads: 3282, responses: 0)
12. Programmers who use LISP can be more productive than those who use other languages.

Jarno Virtanen - Re: Language Myths  blueArrow
4/22/2002; 10:10:09 PM (reads: 3249, responses: 0)
13a. Imperative programming is more intuitive (than functional programming).


13b. Functional programming is more intuitive (than imperative programming).

Adam Vandenberg - Re: Language Myths  blueArrow
4/22/2002; 10:58:18 PM (reads: 3233, responses: 0)
14 C/C++ is the best language to base a first year / intro to programming course on, since "C/C++ is what they use in industry."

(I favor a multi-language approach.)

Paul Snively - Re: Language Myths  blueArrow
4/23/2002; 7:23:56 AM (reads: 3198, responses: 1)
I would revise 12 to read "Programmers who use LISP are more productive than those who use other languages." As worded, 12 is trivially true, rather than a myth.

Re: exceptions, a goodly number of folks whom I respect tremendously have issues with dynamic non-local exits, which exceptions are an instance of. There's a tendency to turn exceptions into a catch-all. Worse, there's a tendency to turn exceptions into someone else's catch-all, a tendency that led to one of the Pink team's design mantras being "Exceptions are part of the interface."

Exceptions introduce subtleties in the semantics of your code. Sometimes you really can't have the stack unwinding out from under you. It took a while before the need for unwind-protect (Common Lisp) or finally (Java) was recognized as legitimate. And if what you're protecting is owned by something other than the local scope, you'd better be sure that both the exceptional and non-exceptional case leave these resources in a consistent state, consistently—not necessarily a trivial matter if your exception handlers are fine-grained and are themselves in differing scopes.

Exception handling combined with operator overloading is just fraught with peril. Consider that Herb Sutter has now written "Exceptional C++" and "More Exceptional C++," and much of the first book is devoted to issues of exception safety that arise if you aren't careful in the design of your assignment operator (to be fair, the C++ community got the copy-and-swap idiom out of it, which is worth the price of admission).

Re: 14 and favoring a multi-language approach, since syntax differences seem to throw so many people, I favor a multi-paradigm but single-language approach, the language then being Oz.

Ehud Lamm - Re: Language Myths  blueArrow
4/23/2002; 7:48:08 AM (reads: 3256, responses: 0)
"Exceptions are part of the interface."

Mantra or no mantra this is the right way to program. No interface is complete without a specification of error (i.e., exceptional) events.

Alex Moffat - Re: Language Myths  blueArrow
4/23/2002; 8:08:51 AM (reads: 3182, responses: 0)
Does all "All those parentheses are confusing." count?

Franck Arnaud - Re: Language Myths  blueArrow
4/23/2002; 9:26:56 AM (reads: 3168, responses: 2)
> No interface is complete without a specification of error > (i.e., exceptional) events.

That nobody would deny, the question is more whether specification of errors is so special that it needs a dedicated language construct, and then if yes whether that language construct should be a (loosely) constrained goto.

Besides many current exceptions mechanism precisely aim at non-specified treatment of errors ("specification is too much work") and when the choice is offered like in Java specified errors end up converted into non-specified errors because it's heavy to propagate the spec, and everybody thinks the caller is in charge of dealing with errors (so ultimately the end user is in charge, and indeed when you use the web you get exceptions traces all the time).

Another point is that it encourages mislocation of error treatment and poor modularisation, that is the "exception pattern" pushes people to split error handling between the very ends of the call chain, even in cases where it would fit very well at a single location (eg use recovery of an exception deep in a date computation library in the middle of some processing and recover it on top, rather than checking the date is OK at the point of user entry before starting the processing).

Ehud Lamm - Re: Language Myths  blueArrow
4/23/2002; 9:35:40 AM (reads: 3246, responses: 1)
it encourages mislocation of error treatment and poor modularisation

I don't buy this. This is one of those claims that are hard to prove, and don't really lead to the desired conclusion, even when proved. Exceptions can be used to localize error handling; they also support porpagation. If programmers don't know which technique to use when, they should be educated (If you live in Israel, come take my course...)

Jay Han - Re: Language Myths  blueArrow
4/23/2002; 11:14:20 AM (reads: 3316, responses: 0)
FWIW from an old usenet post:

The essence of exception handling is the ability to define _dynamically_ what the bit of code after an 'else' should do, subject to the pre-condition of that 'else' and the post-condition of the 'if' in which it appears. If one wants to use the same bit of code to handle various ``exceptions'', the same bit of code must satisfy the pre/post conditions of various 'else' parts.

Franck Arnaud - Re: Language Myths  blueArrow
4/24/2002; 4:47:46 AM (reads: 3081, responses: 1)
Exceptions can be used [well]. If programmers don't know which technique to use when, they should be educated...

Spot on. That's the core of my argument against exceptions: they are not a robust construct in that it's very easy for people who are not precisely educated in their handling to get it wrong. I even think that intuitively you get it wrong, like a door you have to push with a handle that suggests pull. I think an essential property of an industrial (as opposed to research) programming language is to have some education built in, that is make it difficult to get things wrong and hint towards the right or simply consistent way to do things -- that won't replace education but every little bit helps.

Better have no exceptions and some rare awkward propagations to do by hand, than having millions of lines of exception spaghetti to maintain -- and that's a form of spaghetti which is particularly hard to refactor (stinks and sticks), another very bad point.

(Same point as the nice S. Tucker Taft paper recently covered here, see also the classic Design of everyday things, there's no reason that it shouldn't apply to programming languages.)

Ehud Lamm - Re: Language Myths  blueArrow
4/24/2002; 5:47:38 AM (reads: 3169, responses: 0)
very easy for people who are not precisely educated in their handling to get it wrong

This is a slippery slope: Many don't know how to write good subroutines (think cohesion/coupling; parameters; naming). So next we'll have to throw these out as well...

Let me just add that I think exceptions are among the better error handling mechanisms. First, they can not simply be ignored (like error code returned by functions. Ask a firendly C programmer how many hours can be wasted hunting down these errors). Second, they are much easier to use correctly than mechanisms that support retrying or resuming problematic expressions.

Dan Shappir - Re: Language Myths  blueArrow
4/25/2002; 1:34:27 AM (reads: 3028, responses: 1)

I'm glad to see my comment on exceptions generated such a debate. For the record, I'm pro exceptions yet somehow find that I don't use them as much as I ought to. In many cases this is because I'm adding code to existing applications that were originally built without exception handling. Also, I find that many programmers are unfamiliar/suspicious about exceptions. Since I prefer not to swim against the current in such cases (unless there is a substantial upside), I do without. Finally, Microsoft's COM technology and ATL framework don't like exceptions. Since I've used both in many of my latest projects, this was also a factor. OTOH, since Java and .NET both rely heavily on exceptions I guess their usage will increase.

Here is another topic for the "book":
15. Inheritance is the best way to get code reuse.

Oh, and Ehud, I live in Israel ;-)

Ehud Lamm - Re: Language Myths  blueArrow
4/25/2002; 3:05:25 AM (reads: 3134, responses: 0)
Great. We should meet sometime!

I always find it amazing when I hear about people being suspicious about exceptions and/or templates. These are usually C++ programmers. Ada programmer use these tools for years, and they are seen as something obvious and quite old fashioned. (Only people who don't like exceptions are the mission crtical crowd, but they are really niche players)

Franck Arnaud - Re: Language Myths  blueArrow
4/25/2002; 11:02:42 AM (reads: 3034, responses: 1)
These are usually C++ programmers.

There's also some controversy in the Java world: see Eckel's or this summary. A twisted mind could also interpret the recent thread in comp.lang.functional on misadventures with bottom in Haskell as an extra disadvantage of exceptions.

Ada programmers use [templates].

I thought Ada generics were quite different from C++ templates (closer to Eiffel's genericity). It seems to me quite reasonable to like Ada generics and dislike C++ templates. They are quite different solutions to the same initial problem -- but maybe I'm seriously mistaken about Ada generics.

Ehud Lamm - Re: Language Myths  blueArrow
4/25/2002; 1:26:00 PM (reads: 3097, responses: 0)
Well, there are differences. But I still think the basic idea is the same. Most people I talked to who don't like/trust templates are not experts. They simply don't grasp the basics. (As the saying goes: they think OO is more intuitive).

Indeed, I prefer the Ada model (which utilizes the Ada type system etc.), but I think some exciting C++ features can be quite useful (template specialization and automatic instantiation).

Ehud Lamm - Re: Language Myths  blueArrow
4/25/2002; 2:20:28 PM (reads: 2998, responses: 0)
Now that we have a bunch of myths, how about thinking about who is most suited to debunk each of them? Example:

C is the best programming language - Dennis Ritchie (Well maybe. See what he says about language success).

Frank Atanassow - Re: Language Myths  blueArrow
4/26/2002; 4:49:19 AM (reads: 3013, responses: 0)
I must admit I don't like exceptions much. In statically typed languages, it seems they are used mainly to make up for other defects in a type system. Other times, people throw exceptions when they are too lazy, or unaware of how, to write a total function with the correct type or use a monad or something to handle the partiality. In dynamically typed languages, it seems exceptions are used in an even more willy-nilly fashion because people think even less about static guarantees. (This is called the "To hell with it!" response in psychology. For example, you've given up drinking, but then decide to have a drink. Well, you say, I've had one---to hell with it, I'll have another! And so on.)

The way I regard exceptions is, essentially, as an application of upwards continuations (downward too, if they are resumable) plus dynamic binding. Regarding exceptions from this perspective is, IMO, a Good Thing, because it gets you out of the "I dunno how to solve this problem so I'll just stick an exception in there" and "all error conditions are equal" mindsets. Actually, if you look at exceptions this way, you will see they have nothing much to do with "errors" (whatever those are! can you give a formal definition?) at all.

Ehud said that exceptions are part of the interface. This should certainly be true in a statically typed language. There are languages based on classical logic which can record in the type when a function will exit via a continuation. Compared to these languages, the Java-style "throws" specifications are very weak and awkward.

Likewise, it can also be argued that dynamic binding should be part of the interface, by which I mean of course "the type", especially in a purely functional language like Haskell. And indeed there is work on this, in the form of "implicit parameters", by Lewis, Shields, Meijer and Launchbury. Their work seems to have an interesting and plausible semantics, which I was pleasantly surprised to learn of.

As far as implementations go: SML/NJ is the only implemented language I can think of which seems to have proper types for continuations as a language primitive. OTOH, first-class continuations can be coded up from scratch in Haskell if you are prepared to do your programming in a monad. The Glasgow Haskell Compiler (and Hugs?) supports an extension which supports dynamic binding too, though there are some unexpected interactions with laziness (which most users probably will never trip across, though). So you should be able to code up resumable exceptions in GHC. GHC also has primitive support for "non-deterministic" exceptions, though I've never used them.