In Praise of Haskell • Hacker News Board

Re: In Praise of Haskell

#61

Post by tel » Tue, Nov 05, 2013, 3:23 AM UTC

taeric wrote: post #59

nightski wrote: post #50

Earlier quoted context omitted.

It is more of a contract. The library author is stating this package was developed against these dependencies and versions. It is known to work well in these cases. This does not mean it will not compile. In fact often the fix is simply for the author or developer to relax the version bounds and everything will be fine. Lastly, many of these issues arise not because of a direct dependency but an indirect one. The pro…

I still feel you are being a touch unfair to the dynamic world. Many times, bringing in a dependency just works. The analogy I have in my mind is a digital computer for a bike. The general "contract" is simply that you will somehow get a pulse to the computer for each rotation of a tire with a known size. The details of how the bike is constructed are ultimately irrelevant. Further, because this is such a general con…

There's work to provide this "module by contract" notion you're talking about exactly (http://www.mpi-sws.org/~skilpat/backpack/) but it's very new and far from implementation. OCaml does a good job of this and is usually the poster child for parametric modules done right.

That said, dynamic languages allow this kind of contractual module imputation by the virtue of allowing absolutely anything to be considered a module and hashed out at runtime. At the least this means carrying around a lot of tagging/runtime typing information so you can call up runtime errors. At the most, it means that your whole system is held together by an increasingly wide set of unchecked and uncheckable assumptions.

Cabal hell is annoying but at least it's checking.

Re: In Praise of Haskell

#62

Post by chongli » Tue, Nov 05, 2013, 1:43 PM UTC

clux wrote: post #17

tmhedberg wrote: post #10

Earlier quoted context omitted.

The latest version of Cabal (1.18) includes built-in sandboxing support, which alleviates this problem to a significant extent. Prior to that, there were/are tools [^1][^2] for doing the same thing external to Cabal itself. Dependency hell has without a doubt been problematic with Cabal, but it is fast becoming a solved issue. [^1]: http://hackage.haskell.org/package/cabal-dev [^2]: http://hackage.haskell.org/package…

I did use cabal-dev, and it only moved the problem from being a global problem to a local one. Is the problem that you cannot have several versions of the same package solved? Because this really needs to work, otherwise you effectively have a limit on how many modules you can use sensibly without expecting things to break.

You can have several versions of the same package. You can't have one package built multiple times to depend on different versions of the same package. This is the main cause of dependency hell.

Re: In Praise of Haskell

#63

Post by chongli » Tue, Nov 05, 2013, 1:49 PM UTC

MedDev wrote: post #41

cgh wrote: post #35

Earlier quoted context omitted.

No, you can just watch this talk by John Carmack as he extols the virtues of Haskell for game programming: http://functionaltalks.org/2013/08/26/john-carmack-thoughts-...

The problem I have with this is Carmack is in the top 0.01% of developers so of course writing a game in Haskell is going to be within his grasp. For the rest of us it's a huge exercise in mental gymnastics. I've written a few visualizations for data using Gloss ( http://gloss.ouroborus.net/ ) with Haskell and although it does "just work" when it does compile understanding how to manage state in a pure environment is…

For the rest of us it's a huge exercise in mental gymnastics.

I've thought about this a lot and honestly, I think this is a good thing. Languages which are much less strict about types and mutation require huge mental gymnastics too, they just don't tell you about it. They let you happily continue on your merry way until some time at a later date you realize your program is a giant ball of mud and you have no idea how to change things without breaking it. Haskell forces you to deal with the hard problem of state up front in exchange for having a clear, maintainable program down the road.

Re: In Praise of Haskell

#64

Post by platz » Fri, Nov 08, 2013, 4:56 AM UTC

cgh wrote: post #33

nahiluhmot wrote: post #18

Earlier quoted context omitted.

It wasn't so much a bad example so much as it was a trivial one. Perhaps a more powerful one (that displays the advantages of lazy evaluation and higher-order functions) would be the function to generate an infinite list of Fibonacci numbers. fibs :: [Integer] fibs = 0 : 1 : zipWith (+) fibs (tail fibs) Even still, it's difficult to get the feel of actually using the language from one function taken from a freshman y…

How about demonstrating the power of laziness by generating the power set of a set? (Taken from Learn You a Haskell). powerset :: [a] -> [[a]] powerset xs = filterM (\x -> [True, False]) xs ghci> powerset [1,2,3] [[1,2,3],[1,2],[1,3],[1],[2,3],[2],[3],[]] Edit: I read LYaH some time ago but this example stuck with me because it's both wonderful and mind-blowing.

Here's a recursive definition which is less cool but less 'magic'

    powerset        :: [a] -> [[a]]
    powerset     [] =  [[]]
    powerset (x:xs) =  yss ++ map (x:) yss
                       where yss = powerset xs

    > powerset [1,2,3]
 
    [[],[3],[2],[2,3],[1],[1,3],[1,2],[1,2,3]]