2

I have often seen claims that a programming language feature eliminates a whole class of errors.

For example, I have seen claims that:

  • A strong type system eliminates the class of errors caused by using features that a type does not support.

  • Automatic memory management eliminates the class of errors relating to allocating the correct amount of memory for an object/structure.

  • Mandatory variable initialisation eliminates null pointer or null reference errors.

  • Immutable data structures eliminate the class of errors caused by not understanding the impacts of changing mutable state.

I am not trying to find out whether the claims above are true or not, but rather compile a list of claims of this type that are specific enough for me to research and evaluate myself.

What other specific features are alleged to eliminate a whole class of errors?

Is there a general principle or theory for identifying features that do this, or identifying the absence of such features?

(Note that I do not include obviously vague or subjective claims like these, whether true or not:

  • Object oriented programming improves reusability.

  • Dynamic languages are faster to program in.

  • Meaningful whitespace makes the program cleaner. )

Paul Sweatte
  • 24,148
  • 7
  • 127
  • 265
dukereg
  • 722
  • 5
  • 16
  • 1
    Automatic memory management eliminates a class of errors related to proper (timely) destruction of objects and freeing their memory, and also "user-after-free" errors. I mean it's usually hard to misallocate memory, but sometimes it's easy to not properly free it. – kostix Feb 26 '14 at 12:37
  • Automatic memory management *doesn't* eliminates for complete a class of errors regarding allocation, they just make it easier for the programmer to deal with the timing of deallocations. Here is an example of memory leaks on Java : http://stackoverflow.com/questions/10577534/can-you-have-memory-leaks-with-a-garbage-collector – Pedrom Feb 26 '14 at 14:09
  • I'd include the strong type system claim as obviously vague and subjective. The objective reality is that in my experience I've only ever seen two bugs that can be improved by having a strong type system in over 12 years of programming. And those bugs happened in C - a typed language. I've never had problems with typeless languages like tcl or bash though semi-typed languages like perl and javascript are annoying when you're first learning them because some types don't behave the way you expected. – slebetman Feb 26 '14 at 14:49
  • 3
    C is extremely weakly typed. I wouldn't generalize much from C to any other typed language. – Brian T. Rice Feb 27 '14 at 01:01
  • A determined coder can implement an error of any kind using any Turing-complete language, no matter what functionality the language provides, what style it encourage or discourage. – SK-logic Feb 27 '14 at 05:33
  • I was using words like "claim" and "alleged" to hint that the claims don't need to be unassailable, proven correct, agreed with by the reader, etc. The point is to collect claims that are specific enough that I can research and evaluate them without getting into opinions. – dukereg Feb 27 '14 at 05:54
  • @slebetman You are right that there is vagueness in my examples, but they are specific enough to evaluate, as you just did by counting errors that meet the criteria given. Also, I wouldn't make the mistake of limiting objective reality to your own experience, because others have experiences that have led them to make the claims in the first place. – dukereg Feb 27 '14 at 06:01
  • @SK-logic Why would someone deliberately try to simulate an error that is guarded against by the language? If they did, is it still an error? – dukereg Feb 27 '14 at 08:48

3 Answers3

2

Immutability

Concurrency

Immutability reduces all shared data issues in a concurrent system. Concurrency and Caching are two of the hardest things to get correct, and most people get it wrong the first few dozens of times they try to write code of either type.

Side Effects

Immutability also makes code deterministic, inputs to functions can never change during the scope of the function, for either inside or outside the function, this means there are no side effects.

Non-Null values

Most systems that support immutability as the only type of variable also don't have the concept of Null, either references are assigned or they aren't, if they aren't the compiler complains and you have to fix it.

In Java liberal use of final references and @Nonnull annotations on parameters and return values eliminate almost all non-logic based errors or shows them as they are at compile time or very early in runtime

Community
  • 1
  • 1
1

Here are a few off the top of my head:

Class                 Feature                             Example
Type Error            Single Data Type                    awk
Type Mismatch         Union Types                         XQuery
Reference Error       No Variables                        sed
Mismatched Braces     No Braces                           python
Dangling semicolon    Significant Whitespace              python
Buffer Overflow       No Pointer Arithmetic               Ada
Division by Zero      Default to infinity                 lua
Circular Reference    All values are immutable strings    tcl
Circular Import       No Cyclical Dependencies            OCaml
Ambiguous Type        Hindley-Milner type inference       OCaml
Not enough args       Partial Application                 Haxe
Import Error          Implicit Standard Library           Coldfusion
Leaky Abstraction     No Conditional Logic                CSS
Object Expected       Everything is an object             SmallTalk
No such method        Reification                         SmallTalk
Infinite Loop         No Side Effects                     DSSSL
Deadlock              Software Transaction Memory         Clojure
Namespace Conflict    Stack Save/Restore                  PostScript
Invalid arguments     Stack Machine                       PostScript
Heisenbug             Message Passing Concurrency         Erlang
Paul Sweatte
  • 24,148
  • 7
  • 127
  • 265
1

Optional types eliminate null pointer exceptions. The type forces you to check for the possibility of an empty value.

Most general programming languages have an optional type of some form. Maybe in Haskell, Option in OCaml, Optional generic type in Java.

Daniel
  • 26,899
  • 12
  • 60
  • 88
  • In Java they don't eliminate the errors, they eliminate the exceptions that the errors cause, the logic errors are still there –  Mar 05 '14 at 00:43
  • If you use exclusively Optional types there is no way to dereference a `null`. What logic errors are you referring to? – Daniel Mar 05 '14 at 00:57
  • if you don't have `null` values possible then you don't need a nasty hack like `Optional` which is just more overhead and more indirection, you still have to check to see if it is empty or not, it just **moves** the problem, it doesn't solve it. –  Mar 05 '14 at 01:02
  • It's a fact of life that some computations can fail and using Optional forces you to check for the missing values which are the results of such failures. – Daniel Mar 05 '14 at 01:04
  • like I said, it just **moves the problem**, it doesn't fix it, it is still a **null pointer check** just with more overhead by another name. If the language doesn't support `null` or you completely eliminate the possibility of `null` during proper execution; you don't have the [Billon Dollar Mistake](http://lambda-the-ultimate.org/node/3186)! –  Mar 05 '14 at 01:16
  • We're talking about the same thing here. – Daniel Mar 05 '14 at 02:01
  • Option is not a null-pointer check. That is a common misconception often found in the minds of C++/Java programmers. Option lifts the possibility of failed computation to the type system (thus it only makes sense if one has a meaningful type system). – choeger Mar 05 '14 at 09:15
  • In Java 8; `if (x == null)` and `.isPresent()` are for all practical purposes the **exact same thing**, and `.get()` throws a `NoSuchElementException` how is that any better than a typical `NullPointerException`? So this isn't any better than what we have now, other than it is more code to write, and more checked exceptions explicitly handle, so **it is a null pointer check wrapped in code that throws a different error ... which is even worse!** Eliminating `null` as ever being an option is the only way to deal with the Billion Dollar problem! –  Mar 07 '14 at 02:59