
On programming language design - kqr2
http://math.andrej.com/2009/04/11/on-programming-language-design/
======
hobb0001
The author is obviously a fan of B&D languages.
([http://catb.org/jargon/html/B/bondage-and-discipline-
languag...](http://catb.org/jargon/html/B/bondage-and-discipline-
language.html)) There's nothing wrong with preferring a little B&D, but it's a
shame that there are still masochists in this day and age that claim other
languages are "broken" because they don't spank you often enough.

~~~
Zak
I don't think that's quite it. The author seems to like languages that let
programs be as close to provably correct as possible. He also admits that, for
some problems, this is a mistake.

I used to hate static typing with a passion, and I'm still a pretty big Lisp
fan, but I've recently taken up Haskell. Many of the examples in this post use
Haskell as an example of the right thing, and I'm really starting to see the
advantages. Certain common errors are caught by the compiler, and impure
operations show up in a function's type signature, reducing the chances of any
spooky action at a distance.

Ultimately, I think there's a tradeoff between flexibility and correctness.
How much of each to choose depends on the parameters of the project. Some
languages try to allow a choice, especially with regard to typing discipline.
Haskell offers Data.Dynamic. Common Lisp has optional type declarations and
compiler warnings for obvious type errors. There's a post about formalizing
such things as "gradual typing"
(<http://news.ycombinator.com/item?id=556794>).

------
jrockway
"I am embarrassed that I made a mistake with that article about lambda, so now
I am going to write 15 pages about how it is someone else's fault."

~~~
Herring
s/fault/problem

------
jorgeortiz85
Even though it was never mentioned, I couldn't shake the feeling that he was
talking about Scala. Scala allows nulls for compatibility with Java, but
prefers the statically checked Option type (equivalent to Haskell's Maybe). It
puts variables (var) and final variables (val) on equal syntactic footing, but
convention dictates you use a val by default and only switch to var if it's
really necessary. Case classes and pattern matching let you define statically
checked data types. Type inference helps so that all the static typing doesn't
get in your way, but errors are still caught at compile time.

------
andreyf
_Here we hit against a law of nature: there is no algorithm that would analyze
an arbitrary piece of code and determine whether it will only produce valid
search trees._

Why not? I know about the Halting problem, but I don't see how this is
equivalent... am I missing something?

~~~
nostrademons
In order to produce a valid search tree, the code must halt. Therefore, an
algorithm that can tell whether an arbitrary piece of code will produce valid
search trees can tell whether that piece of code will halt.

This isn't really a good example though, because it's quite possible to
examing an arbitrary piece of code and, _assuming it halts_ , determine
whether it will produce valid search trees. The Haskell and ML typecheckers
are existence proofs for this, as is the static typechecker that Wadler did as
a bolt-on addition to Erlang.

~~~
ntoshev
More practically, the "arbitrary piece of code" can be expressed in a less-
than-turing-complete language or language subset, and it would actually be
possible to prove useful things about it.

------
ilkhd2
And, and the end of the day, the very language runtime of the very ideal
language, will have to be written in C, for efficiency reason...

~~~
davidmathers
_language runtime of the very ideal language, will have to be written in C_

Or, maybe not: <http://piumarta.com/software/cola/>

