Is imperative style programming (say with Java/C) more error prone than something more declarative

Question

I know programmers tend to get defensive with their paradigms and tools that they use. But in your experience, with the most generic, typical pieces of code that you see with Java or C++ or C, is the code more error prone than a similar piece of code in an declarative or functional programming language.

For example, with Java there can be a lot of boilerplate and setup code need to call your target routine. Usually developers may need to look at the implementation details to really understand what happens if they do or do not provide the correct dependencies. Normally the developer never does that so you end up with NullPointerException bugs and other logic errors.

Answer 1

The question is a bit unclear. Is one programming style more "error-prone" than another? What would this mean? Humans cause errors, not programs. However, some programming styles are better at mitigating certain types of human error. I think it's reasonable to say that a compiled language that doesn't give a syntax error at compile-time is more error-prone than one that does, and it is this sense that I will use.

Some languages do provide more mitigation than others. For instance, statically typed languages provide errors that mitigate type violations*. In some languages, such as Haskell, the type system is so powerful that "getting the types right is most of the battle". I would argue that these languages provide more mitigation than others. That is to say, it is easier to have unexpected type violations in dynamically typed languages, but that does not make them worse languages

So, no language will make humans less error-prone, so no language is less error-prone per se. But some languages will have more effective mitigation strategies that will catch human errors before they become user-facing bugs.

Of course, none of this will make a bad programmer good, nor does it replace more robust mitigation strategies like unit testing.

* _{This is not to say that dynamically typed languages are strictly more error-prone, only that there is a class of bug (type violation) that will not be mitigated directly by the language.}

Answer 2

Errors come from humans not languages. Neither language nor language type is relevant in determining error proclivity.

Lazy coders on the other hand are more error prone than diligent ones.

Answer 3

That's a highly subjective question. I would argue that it's ultimately clarity that counts most when it comes to reducing errors in programs, and for me personally, declarative programming is clearer. If I can understand the gist of what a method is out to accomplish without reading further, I'm already a leg up over someone who has to understand what that method does to understand the big picture, in my opinion. That's not to say that I may not actually know what it does (programmer naming methods in misleading ways), which in many ways is worse than not understanding what it does at all.

I suppose ultimately it depends on what's clearer to you rather more than anything else.

Answer 4

An unnecessarily imperative style is more error-prone than a style relying more on pure functions and immutable values because mutable values have the potential for aliasing bugs. If a particular program can be implemented both ways, the imperative approach has a higher risk of bugs all else being equal.

However, not all languages support a pure functional style well. It's relatively difficult to make good use immutability in Java, for example, because neither the language nor the standard libraries support it.

Answer 5

Humans make errors. The more a human has to do, the more errors he makes. Therefore, there are two things a language can do:

• Help detect errors early, e.g. through a strong type system. This has been covered by other answers.
• Reduce the amount of work the human has to do.

The second point isn't simply about terseness. "Work" the human has to do isn't just the typing of the code. A lot of the work is in mapping from your idea of how something works to a way of expressing that in the code.

As a consequence, the more directly your ideas map to constructs of the programming language, the less translating you have to do, and the fewer errors you introduce in that translation. For example, in a language without higher-order functions, if you have a list of things and you want a list of things that are derived from the original things, you need to translate from the abstract idea "give me a list of derivatives of things in another list" to "create a list; go over the original list; compute the derivative of the current element; add it to the target list" and then translate that into code like

result = new List();
for each element in source { // what if you don't even have foreach?
  result.add(derive_from(element));
}

In a language that has higher-order functions, you can more clearly express your idea, because you only have to translate it to "use the thing that gives me a list with elements corresponding to another list; give it the way to derive a new element", or in code:

result = map(source, derive_from);

The code is succinct, but more importantly, it more directly expresses the intention. There was less mental translation, and thus less room for error.