The Dongola Times

(Anachronistic) Dispatches from the Kingdom of Makuria.
19th of September, 2012

Re: Haskell Saves Even the Best

And I think it should be said that programming correct code is hard, regardless of what language you use. With Haskell, sometimes the difficulty of getting something correct is made immediately obvious, because it is part of the creed of the language.

With a language that has null pointers, for example, you think you have no bugs even when in fact you do. They are easier to use, those other languages, because they don’t face reality.  They redefine “bug” from being the classical “wrong code” to being “wrong code that has caused a problem at least once”. So you see things that could blow up, because no boss has complained yet, there is apparently no bug. (That is true of whole programs, because of the languages.)

But to make sure that you never have a null pointer problem would imply that you change your programming style to make it a Haskell style. Is it a bit costly to have code that will never have null pointer problems? Whether yes or no, that doesn’t depend on the language. If the language enforces it, fine: you get as much (or as little) trouble as you would if the language didn’t enforce it. The problem is what has to be done, not the language in which it has to be done. But if it has to be done, let the language help.

Every programming convention is a missing compiler feature.

Le Sep 19, 2012 à 11:49 AM, The 27th Comrade a écrit :

Things like this bug are why everybody should be using Haskell.
In particular, the people programming the HTTP package of Golang are very good programmers; but they have that bug—caused by having liberated state—and they cannot even fix it, because … well, because they are not using Haskell. (I say “Haskell” here as a style and approach, more than as a language; but either way, the meaning is safe.)

When you have state, you have an infinite number of code paths that could surprise you. This is not about being a good programmer and safeguarding against the paths you don’t want. Au contraire, it is about being a good programmer and realising that “liberated state → bug”. (And being a philosopher enough to know that there can be no qualitative definition of “liberated”. Software is art, not science. Forget the lies.)
Until 1931, the Western mathematicians were looking for a logical structure that could define mathematics in all its infinite “code paths”. Gödel showed them that their efforts were futile; and yet they continued even after his theorems came out. (Hilbert’s program continued; Lord Bertrand Russell’s program ended for different reasons.) To this day, many seek to prove things—or think they can prove things—which are clearly impossible due to the fact of Gödel’s Incompleteness Theorems.

The same is true of the programming styles that we use today. A lot of programming today proceeds as though you can have a program that has free state (as in freed, liberated state) and also have that program be bug-free and intelligible. This is a fallacy. Even the best programmers cannot achieve that; just as the brilliance of Hilbert and Lord Russell put together could never save mathematics from the implications of the incompleteness theorems.
I am paranoid when I use languages that have free state. At least we should have purity with state introduced carefully, rather than having state where we introduce purity selectively. Give me Haskell or give me another task.


Posted by e-mail.






Posted by e-mail.