Hacker News Reader

Comment by brudgers | Hacker News Reader

Maybe, what I am thinking is that a language which makes it easy to program in a functional style, should make it equally easy to program in an imperative one. By extension, this may mean that a good language for functional programming ought to make it easier to program imperatively than languages designed to facilitate imperative programming.

Of course, this begs the question of what is easier and harder and better and worse. There's a case to be made that Haskell's monads make imperative programming easier. It's essentially a mathematical argument - rather abstracto-theoretical versus the sort of concrete arguments that get advanced to avoid discussions of why it might be better to reason with lambda-calculus versus using von-Neumann as a model.

To put it another way, being able to abstract away von-Neumann into mathematics is useful. But the von-Neumann model is useful because it is a model that we can easily get our heads around.

View on HN

If you asked a Haskell expert what their favorite imperative language is, they'll probably say "Haskell."

That is because it "makes it easier to program imperatively" more than any other language I've met.

Only after the learning curve, though. It isn't immediately approachable as an imperative language.

Yes, but suppose you could write the same program in two languages, a classic imperative one, and a purist and difficult FP language.

For the sake of argument, let's assume the classic imperative language is easier to approach for rookies. If it's also the easiest language to write bugs and make mistakes with, wouldn't the "harder" FP language still be a net win? As long as its learning curve isn't unapproachably steep -- i.e. so steep that your time to market becomes awful -- what is the advantage of the imperative language's ease to hit the ground running and writing lots of bugs?

If language 'a' lets a person write a program with 'b' bugs in time 't', and language 'aa' lets the same person write the same program with 'b' bugs in time 't-n' then there is a clear net win for all 'n' > zero.

If 'aa' also has the advantage of providing semantics for producing significantly less buggy code in time 't-n-m' at some future time then that is also an advantage but a distinctly different one and one which can be deferred [and probably will be given a significant learning curve].

The first step toward the modern automobile was the 'horseless carriage' not the Countach.

It's greatly overstating the learning curve. It's possible to pick up Haskell by simply writing a few small applications tackling different parts of the language in each one. This can be done in a few months. Not to mention there are now numerous resources available for free such as learn you a haskell, real world haskell, and countless blog posts.

I hear the Wikibook also has a good introduction.

> The first step toward the modern automobile was the 'horseless carriage' not the Countach.

Lamborghini makes shit cars. The only reason people rave about them is because they have giant engines. A car without a reverse gear is one of the stupidest ideas in automobile history.

I used "Countach" for its word value. It's alliterative and has little rhyming potential and is loaded suggestively with images of suits with shoulder pads. An absurdity is not accidental.

"But the von-Neumann model is useful because it is a model that we can easily get our heads around."

I am skeptical of this statement.

Programmers make a lot of errors when reasoning about mutable state, so I don't think it's fair to say "we can easily get our heads around the von-Neumann model". My intuition is programs written without mutable state will, on average, have fewer errors, which suggests to me the more "mathematical" nature of functional programming is actually easier to wrap one's head around.

Not sure what empirical data is out there to test this hypothesis.

I probably wasn't clear enough. My point is that the von-Neumann model allows us to walk up to a computer and point and say, "Here is the memory and here is the processing unit and here on this test probe of register 47 we see the instruction to move the contents of memory address 42 from memory into register 19." Even my mom can understand a sketch of the von-Neumann model to some degree.

Because functions are not a model of a computer, but a means of computation, there's no obvious picture. Indeed, if I look at the test probe, I don't see a function but an instruction to move the contents of memory address 42 from memory into register 19. I can draw a diagram of a Turing machine in a few minutes, not so with the lambda calculus. The equivalence is only mathematical, and that cuts both ways. There's no way to write a functional version of The Art of Computer Programming because mathematical equations don't have running times.

I think you hot the mail on the head there. That the delta between mathematics and programming is time. Lee Smolin makes a similar case for physics.

Reply on news.ycombinator.com