
Reasons to use Haskell as a Mathematician (2006) - cottonseed
http://blog.sigfpe.com/2006/01/eleven-reasons-to-use-haskell-as.html
======
cousin_it
I've slowly come to the opinion that laziness is not the best idea, even from
a pure mathematical point of view. There are large mathematical benefits to
using a strict language like SML. One important benefit to me is that
strictness allows you to have an equality operation with a very strong
mathematical guarantee, namely that the types for which equality can be
automatically defined are _precisely_ the types for which equality is
decidable (always terminates). A lazy language throws that out the window. In
a strict language you can define both a type of guaranteed-finite lists with
decidable equality and a type of potentially-infinite streams, while in a lazy
language you only have the latter.

I wrote about it in more detail here: [http://slepnev.blogspot.ch/2014/06/is-
laziness-wrong-for-equ...](http://slepnev.blogspot.ch/2014/06/is-laziness-
wrong-for-equality.html)

~~~
wyager
But mathematics is non-strict. One can define functions that terminate when
evaluated lazily but don't terminate when evaluated strictly. These kinds of
functions are prevalent in mathematics.

~~~
cousin_it
Does your belief that "mathematics is non-strict" go as far as saying that the
type of natural numbers:

    
    
        data Natural = Zero | Successor Natural
    

must include this member as well:

    
    
        omega :: Natural
        omega = Successor omega
    
        bool1 = (omega == Zero)            -- returns False
        bool2 = (omega == Successor Zero)  -- returns False
        bool3 = (omega == omega)           -- whoops, infinite loop
    

The moral is that some parts of mathematics may be lazy, but mathematical
induction has gotta be strict. Since many functional programs rely on
induction for proofs of termination, correctness and resource usage, that
means they should be strict as well.

~~~
wyager
>Since many functional programs rely on induction for proofs of termination,
correctness and resource usage, that means they should be strict as well.

Am I incorrect in thinking that any strict program proven to be correct and
terminating is also correct as a lazy program?

~~~
cousin_it
Yeah, that's true for programs, i.e. things that accept no arguments. Lazy
evaluation provably makes more programs terminate than any other evaluation
strategy. But it's kind of misleading for functions that accept arguments,
like numbers or lists. Most functions in a lazy language can fail to
terminate, because the arguments could fail to terminate or could be non-
standard entities like omega. So, for example, the statement "computing the
length of a list always terminates" is true in a strict language but not in a
lazy one.

In general, strict languages allow you to say more about termination and
time/space complexity of functions than lazy languages. For example, the
statement "computing the length of a list takes O(1) space" is true in a
strict language, but in a lazy language it's difficult to say what the
statement even means, and in most practical cases it's false. Computing length
with either foldr and foldl uses at least O(n) space, and the usual advice is
to use foldl', which has a strictness annotation. I think this should be
alarming to anyone who recommends lazy evaluation as the right default.

In slightly more complicated cases, like sorting a list, there's no sensible
way to assign a time or space complexity at all, because it depends on how the
function is called and how much of the result is used by the caller. People
sometimes claim that's an advantage of lazy languages, e.g. implementing
quickselect in terms of quicksort and claiming that quickselect will only
evaluate as much of quicksort as needed. I think that's a hack. We need to be
able to reason about the time and space complexity of a program in terms of
its parts, without relying on implementation details of the parts.

------
gizmo686
As someone who has used Haskell for math, I would comment that the standard
prelude (Haskell's standard library) can be quite obnoxious to work with
depending on what you are doing. When I use Haskell for math, I normally
switch to the numeric-prelude [0].

[0] [https://hackage.haskell.org/package/numeric-
prelude](https://hackage.haskell.org/package/numeric-prelude)

~~~
gamegoblin
At least #2 on their list of issues is currently fixed in GHC 7.8

------
tdees40
I'm currently porting a Numpy project into haskell as a self-improvement
project, and it's been 69% great. But then I find some library that I have to
implement from scratch when I just had it in python. That's a pretty big
problem, and I'm willing to put up with it, but most people aren't.

~~~
iand675
A nice way to look at it: if you share what code you have had to reimplement,
you're making it more than 69% great for the potential Haskellers that follow!

~~~
tdees40
Would love to! But my employer probably wouldn't be so thrilled about it.

------
warfangle
I've always wondered why computational mathematicians/physicists end up using
MATLAB/FORTRAN instead of haskell or similar.

~~~
leephillips
The author of the article gives a hint: "Haskell isn't very good at dealing
with arrays." High performance numerical code typically involves mutating
large arrays distributed over a grid of machines or processors. I talk about
the question you ask a little more here:

[http://arstechnica.com/science/2014/05/scientific-
computings...](http://arstechnica.com/science/2014/05/scientific-computings-
future-can-any-coding-language-top-a-1950s-behemoth/)

~~~
nightski
That just isn't true though. It might be true for the standard prelude, but
there are very high performance options available. Not only that, there are
great wrappers to the standard C/Fortran scientific libraries used by
everyone.

I have written real time 3D reconstruction and SLAM algorithms in Haskell, so
I have had to face this head on.

------
segmondy
there are a bunch of languages mathematicians should know, haskell is one of
them, so is prolog, lisp, APL, FORTRAN, and C. They all have their advantages,
and you just have to know which one will give you an edge in your problem
domain.

------
j2kun
I want to hear from people who do math all day every day, and not just
programming language theory. I want to hear about algebraic geometers,
topolgists, ring theorists using Haskell and saying "Yeah this is really
helping me in my work."

~~~
Sniffnoy
As a mathematician I'll certainly endorse a number of the points in the linked
post. Because what they mean is that it can be very quick to translate
mathematics into code. Maybe it won't run fast or be understandable by anyone
else, but I can express complicated ideas (relatively) compactly and quickly
and get something working without huge amounts of tedium.

~~~
j2kun
Can you give me some examples? What do you use Haskell to do? I am also a
mathematician so I can handle the jargon.

~~~
Sniffnoy
Mostly not large things. (Or at least, mostly not things that are large in
Haskell.) An example recently -- I wanted to consider, let's say you have two
finite rooted trees, S and T, with T having more vertices; and you you have a
bijection f from the set of subtrees of S (subtrees have to have the same root
as the original) to the set of subtrees of T, with certain restrictions on it;
and then to f you associate a system of linear equations; and if the solution
set to this system isn't contained a hyperplane aligned with the axes, then
(if there exists an f for which this is true) I'll say "S interferes with T".
And then I want to check for various T whether there is any smaller S that
interferes with them.

Basically without something like Haskell, or at least something like Haskell-
or-ML (I didn't need typeclasses and I don't know how much I needed laziness),
it seems like that would have been a complete mess.

Of course, the above example is perhaps not the best as it meant I had to
[either look up a library, or, what I actually did] implement row-reduction in
Haskell, obviously not a great language for it! But ultimately it wasn't too
terrible. And the rest as I've said would have been terrible in another
language.

------
gone35
Shamelessly off-topic, but I can tell the author is a legit pure
mathematician:

 _(1) Haskell is Functional

(2) Haskell Insulates You

(3) Haskell Performs Well

[...]

(3) Haskell is Declarative_

Not being ironic, by the way. From experience, often I can tell pure vs
applied mathematicians by how hilariously bad/absent-minded they can be at
basic arithmetic/algebraic manipulations.

Same for theoretical- vs systems-oriented CS people, I've found --almost as if
being a horrible programmer somehow gives you academic hipster cred.

( _EDIT - To clarify: I mean CS academics in grad school, not CS professionals
in industry. Also it 's just a silly anecdote only marginally correlated with
reality: no offense intended to anyone._)

~~~
StandardFuture
It is technically impossible to be a good 'CS People' and simultaneously be a
'horrible programmer'. It seems that what you are referring to are people who
know basic CS concepts and even know the basic features of a language or two
but do not have a 'Hacker' mindset. This does not make them a 'horrible
programmer' \-- just as a hacker who comes up with 'tricks', without actually
understanding that the things he 'created' were already discovered in some 70s
CS paper, is not a 'horrible Computer Scientist'. It's not a sufficient method
to describe a person's strengths and weaknesses.

~~~
gone35
Sorry I wasn't clear: by 'CS people' I meant to refer to CS academics in
graduate school (professors, post-docs, grad students), not CS professionals
in industry --admittedly a sign of insularity, I recognize.

And what I meant is that, anecdotally, academics working on CS theory ( _eg_
theory of computation, computational learning theory) are more likely than not
to unmistakeably be what I think everyone on HN would agree to call point-
blank "horrible programmers": no use of version control, no tests, little
concern for organization/modularity/maintainability, _etc_. And in part it
makes sense since they don't have to hack nearly as much as systems-type CS
academics --in many ways their work is closer to pure mathematics than
engineering/applied math. That's all.

In all just a silly anecdote, although with a kernel of truth. See for
instance Scott Aaronson's joke comments about his programming abilities [1]:

 _On the spectrum of computer science, I 'm about as theoretical as you can
get. One way to put it is that I got through CS grad school at Berkeley
without really learning any programming language other than QBASIC_ (!).

[1]
[http://www.scottaaronson.com/blog/?p=266](http://www.scottaaronson.com/blog/?p=266)

~~~
cottonseed
This wouldn't be at all surprising if people realized that the job of academic
computer scientists is not to program (just like the job of an academic
mathematician is not to perform basic arithmetic.)

