

The Evolution of a Haskell Programmer - hamidr
http://www.willamette.edu/~fruehr/haskell/evolution.html

======
davidp
I am simultaneously intrigued by the possibilities of functional programming,
and horrified by the ways it can take people off into the weeds.

Were I to use Haskell in a real-world project with teammates, I'd have to keep
an iron grip on the complexity of the code the team writes. Maintainability
(mainly readability/comprehensibility as far as I'm concerned) is far more
important for the kind of work I do than theoretical purity and hypothetical
applicability to classes of problems the team isn't facing.

I could easily keep things on the rails on my own, but I suppose it's simply
unsettling thinking about using Haskell for something sizable; probably due to
my own lack of experience with it. I'd love to hear about sizable real-world
Haskell projects, since I think FP is the future of software engineering.

~~~
cgag
Isn't maintainability going to be significantly added by so much being
statically checked? Even if people are writing functions that are internally
ugly, wouldn't haskell largely enforce that those functions can't really hurt
the outside world?

It seems to me like "off the rails" in a pure language is going to be much
nicer than off the rails in a language where mutable state is the norm.

~~~
nikatwork
I used to think this about Java's static typing. Then I worked on a ten person
team writing a SAAS project, which had some... less than stellar coders. They
would write 800 line functions, complete with 15 levels of nested "if else"
statements and two-letter variable names.

Yes their code sorta worked, but Deity help you when it came time to add a
feature or fix a bug.

Contrawise, my next project was with a team of moderately competent Perl
programmers. Functions were concise and variable names reasonably clear.
Maintenance was a breeze by comparison.

~~~
cgag
People who are going to use bad variable names and 800 line functions are
probably not even worth thinking about, but if you had a bunch of mediocre
programmers working in each language (perl, java, haskell), do you think their
code would be more maintainable as you moved up the level of static typing? I
would think so, but I don't have any actual experience with this or a really
strong opinion on the subject.

~~~
nikatwork
My point is that architecture and programmer ability is a much stronger
influence on maintainability than type system IME. Although your experiment
would be an interesting one.

Java's static typing did make it easier to traverse the code using an IDE, and
avoided the occasional subtle type casting bug. The easy integrated debugging
was nice too (eg setting remote breakpoints).

These benefits were vastly offset by the productivity hit from wading through
boilerplate code, language verbosity and dealing with type conversion issues.

------
b3tta
Since the "original" mentioned at the top is not available anymore:
[http://web.archive.org/web/20071020011113/http://www.cse.ogi...](http://web.archive.org/web/20071020011113/http://www.cse.ogi.edu/~diatchki/jokes/programmer.html)

------
wslh
It misses the math Haskell programmer using the closed form expression:
[http://en.wikipedia.org/wiki/Fibonacci_number#Closed-
form_ex...](http://en.wikipedia.org/wiki/Fibonacci_number#Closed-
form_expression)

What is the best way to implement it in Haskell since Phi and Psi are real
numbers?

 _Edit: as the user tome told me.... It was about the factorial function not
about fibonacci. I blindly see fibonacci._

~~~
lelf
For example like this (it provides _exact_ result _Edit—no matter how big n
is_ ). CReal is some magic.

    
    
      import Data.Number.CReal
    
      fib :: Integer -> Integer
      fib n = round $ (φ^^n - (-φ)^^(-n)) / sqrt 5
          where
            φ = (1 + sqrt 5) / 2 :: CReal
    
    
      -- While we at it
      fib' n = fibs !! n
          where fibs = 0 : 1 : zipWith (+) fibs (tail fibs)

~~~
carterschonwald
Yeah, the constructive reals lib is really cool, and that's definitely an
example where it really shines.

------
jdn
It's quite amusing how accurate this is, knowing Haskell users across a number
of these levels. It's quite a handy learning tool as well with the added
explanations at the bottom.

------
wreckimnaked
I really want to understand about morphisms and category theory after reading
this. Can anyone point out any good introduction to the category theory behind
those catamorphisms?

~~~
sfvisser
More of a programming than a CT introduction, but very useful nonetheless:
Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire (1991),
by Erik Meijer, Maarten Fokkinga, Ross Paterson

------
agumonkey
Was there some new patterns since the last decade (the page updates stopped in
2001) ?

~~~
ocharles
Unifying Recursion Schemes will be part of the ICFP 2013 papers
([http://www.cs.ox.ac.uk/people/jeremy.gibbons/publications/ur...](http://www.cs.ox.ac.uk/people/jeremy.gibbons/publications/urs.pdf))
which is tangentially related to the penultimate entry using recursion, as we
have another way of reasoning about them now.

~~~
agumonkey
Many thanks

------
ExpiredLink
Haskell? Just let it fade away!

~~~
Peaker
Ironically, Haskell is gaining traction while your comment is fading away :-)

