Lambda the Ultimate

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

Does anyone really think so?

or

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

(I favor a multi-language approach.)

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.

Mantra or no mantra this is the right way to program. 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).

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...)

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.

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.)

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.

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.

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

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)

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.

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).

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

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.