Safety And Expressiveness Discussion

From IssuesForLanguageDesigners:

Quoted from below: "I think, however, that it is a relatively uncontroversial assertion that the amount of code in any nontrivial project that needs to be written in an unsafe language is a very small proportion of the total, if it is not zero. I can't prove this, but it has always been true for me in 15 years of doing system programming" Quote from below: "I'm not sure what you're asking for at all. It sounds like what you're asking for is a demonstration that any possible program that could be written in an unsafe language, say C, could also be written in some safe language. You're not going to get any such demonstration: it isn't true, nor does it need to be true" Quote from below: "The original poster put OCaml in the list of "expressive" languages, and it is also safe. So you can indeed have both."
Trying to refactor this interesting debate, hope to get some clarification. -- Costin

Let's stipulate that this discussion is in the context of system languages where efficiency is considered paramount. It doesn't make sense to discuss the trade off between safety and expressiveness in high level languages because languages like Scheme, Smalltalk, Java, etc have both. Now how efficient should a language be to be considered in this context is another matter for debate. For example OberonLanguage and its successor Active Oberon have successfully been used to write OS (including the drivers and all that), whereas they are clearly safe languages (compared to C), and they are at least as expressive as C. Also it puzzles me in what sense is Ada less expressive than C. Also, to correct a matter of fact, ObjectiveCaml is unsafe in the sense that syntactically legal programs can give segment violation (see OcamlTypeSafetyProblem). Of course a modified ObjectiveCaml could avoid by inserting appropriate run-time type information and checks, but it wasn't the choice of Ocaml designers and we don't known if such a modified run-time can perform as well as the current one to be considered (at least theoretically) as a candidate for system programming. So let's try to identify precisely language issues where the triangle Safety/Expressiveness/Efficiency involves a trade-off. Maybe give each of them a separate wiki page.

Safety Versus Expressiveness

Is the language primarily going to protect programmers from themselves by making certain categories of mistakes impossible (Java, Ada, Pascal, BondageAndDisciplineLanguages), or is it primarily going to be as expressive as possible to maximize the power of the programmer (Lisp, Ocaml, C/C++)?

There is a possibility that this trade-off is not necessarily inherent, and that a way to have safety without losing any expressiveness (even in terms of systems programming) may be found. The experimental CycloneLanguage is such an attempt.

Part of the reason that this is the traditional tradeoff is that expressiveness is often valued by self-styled pragmatists, while safety is most often stressed by self-styled purists/ideologues; the latter have frequently said quite explicitly that loss of expressiveness is acceptable, or even desirable, if it leads to greater safety, while the former camp have frequently explicitly expressed the opposite.

This means that attempts to have maximum safety combined with maximum expressiveness have been very much in the minority compared with efforts to simply trade one for the other.

It's also true that it is relatively rare for maximum-safety advocates to address e.g. SystemProgramming needs.


Safety versus Expressiveness is a false dichotomy - you can have both. Compare ObjectiveCaml with CeePlusPlus: OCaml obtains expressiveness without compromising safety, while C++ obtains it by throwing away safety. The latter is just bad design. -- DavidSarahHopwood

It is not a false dichotomy, you are just blinded by the shining light that is the glittering pure perfection of OCaml, the single exception to this, and all other tradeoffs. Faster than assembler, more OO than Smalltalk, more expressive than English, safer than a mother's kiss - what's not to like?

But other than OCaml, yes, it's a tradeoff. You utterly misunderstand C++, for instance. I know it's everyone's favorite whipping boy these days, and there are things I hate about it myself, but the point of C and its direct descendents is systems programming, and the lack of safety in the C family is not bad design in that regard, and anyone who says otherwise is an ideologue, as is proven by the simple fact that there is no adequate replacement language for systems programming. Systems programming does not necessarily require loss of safety. I write embedded programs all the time, and 99% of the code does not make any necessary use of unsafe language features. The 1% of the code that does is written in assembler, not C or C++ (in fact, it couldn't be written in C/C++). As it happens, most of these programs are written in C. But that is not because of any technical attributes of the C language; it's because of the lack of support for higher level language implementations that target the embedded systems I use. I've been seriously considering switching to CycloneLanguage, which is also both expressive and safe (and which can cross-compile to and interoperate with C, solving the compiler and library support problems). -- DavidSarahHopwood If you look, not at OCaml (which, despite my sarcasm, is unusual in some regards), and not at C++, but at Java, what you see is a language whose major selling point is safety, which it achieves by making many dangerous operations illegal. Pointer manipulation, for instance. Does expressiveness suffer because Java lacks pointers? Hell, yes; people get used to it, and many enjoy and approve of this, but there are many famous classic algorithms that can't be directly written in Java; one must do little workaround idioms. The question isn't whether that is good or bad, the point is just that it is a tradeoff.

Any differences between pointer arithmetic and array indexing are completely trivial; I don't consider that to be a loss of expressiveness (anyway, CycloneLanguage does support pointer arithmetic). Type safety is another such issue; it is achieved by preventing the programmer from doing certain kinds of things. Functional languages rely on HM type inference, chosen because it is not TuringEquivalent, meaning it is decideable, meaning it prevents programmers from certain areas of expressiveness.

This is not a controversial issue. It's an old, well-known, tired issue.

The fact that it's an old issue doesn't mean that the most common opinion about it is right. If I can have both expressiveness and safety by using OCaml or Cyclone, why should I use C++? For the area to which C++ is supposedly targeted - systems programming - I don't find the design decisions it embodies to be well-motivated at all. Anyway, this page is about issues for language designers - i.e. of new languages. Someone designing a new language should certainly look at OCaml and Cyclone as examples of the degree of safety and expressiveness that are simultaneously achievable, not C++.
See also spin-off page OcamlTypeSafetyProblem.

View edit of September 30, 2009 or FindPage with title or text search