Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Not Haskell?

neugierig.org

Post reply on HN
Print view View original

121–130 of 134 posts

Re: Why Not Haskell?

#121

Post by teaspoon »

gtani wrote: post #106
gtani wrote: post #54

Earlier quoted context omitted.

http://haskell.org/haskellwiki/Keywords

(too late to edit above) The haskell wiki link is not adequate, relative to the RW Haskell hard copy index (not avail. online unfortunately), which starts with 1.3 pages of symbol function names (and is missing a few relatively common QuickCheck symbol names). I was looking for something like the Scala staircase book, first edition freely available online, which has a complete list for that language.

Whatever symbols you're seeing in RWH that aren't on that wiki page are probably functions, not keywords. For functions, you should use Hoogle.

For better or worse, there will never be a complete list of infix functions for Haskell because new infix functions can be defined by the user.

Re: Why Not Haskell?

#122

Post by teaspoon »

SkyMarshal wrote: post #102
gnuvince wrote: post #78

Earlier quoted context omitted.

I found that one of the largest difference between Haskell and OCaml is the amount of time I spent figuring out how to make code go fast. Because OCaml is eagerly evaluated and that its compiler is extremely simple, I find that the "tools" that I learned in school and in my time coding in other languages apply to making OCaml code fast (and predictibly fast). With Haskell, you need to be more keenly aware of how eval…

>because I still have problems making really simple Haskell functions that don't crash. Do those functions compile, and then crash anyway? I'd be interested to see examples. In my limited experience, if you can get your code to compile, it's pretty stable. Would be interesting to see counter examples.

Non-exhaustive patterns are one thing the compiler can't catch:

  fn 0 = return ()
  main = fn 1
Giving an empty list to head/tail is another:

  main = head []

Re: Why Not Haskell?

#123

Post by twfarland »

Adaptive wrote: post #36

For those interested in learning Haskell, I can recommend the lesser known "Haskell Road to Logic, Maths, and Programming": http://www.amazon.com/Haskell-Logic-Maths-Programming-Comput... It's great to go over old and new math concepts and do so while exploring Haskell.

I'm going through this now. I've no math/logic background but wish to learn, so is perfect for where I'm at. Interactivity is a great learning tool. The book's focus isn't on real world software engineering though, so anyone expecting that should look elsewhere.

Re: Why Not Haskell?

#124

Post by jstepien »

teaspoon wrote: post #122
SkyMarshal wrote: post #102

Earlier quoted context omitted.

>because I still have problems making really simple Haskell functions that don't crash. Do those functions compile, and then crash anyway? I'd be interested to see examples. In my limited experience, if you can get your code to compile, it's pretty stable. Would be interesting to see counter examples.

Non-exhaustive patterns are one thing the compiler can't catch: fn 0 = return () main = fn 1 Giving an empty list to head/tail is another: main = head []

Speaking of the first example, compiling it with -Wall provides some hints:

  $ ghc --make test.hs -Wall
  test.hs:1:1:
      Warning: Pattern match(es) are non-exhaustive
               In an equation for `fn':
                   Patterns not matched: #x with #x `notElem` [0#]

Re: Why Not Haskell?

#125

Post by teaspoon »

jstepien wrote: post #124
teaspoon wrote: post #122

Earlier quoted context omitted.

Non-exhaustive patterns are one thing the compiler can't catch: fn 0 = return () main = fn 1 Giving an empty list to head/tail is another: main = head []

Speaking of the first example, compiling it with -Wall provides some hints: $ ghc --make test.hs -Wall test.hs:1:1: Warning: Pattern match(es) are non-exhaustive In an equation for `fn': Patterns not matched: #x with #x `notElem` [0#]

Wow, that's cool. It even works for non-Bounded argument types, as in fn [0] = 0:

  Warning: Pattern match(es) are non-exhaustive
        In an equation for `fn':
            Patterns not matched:
                []
                #x : _ with #x `notElem` [0#]
                0# : (_ : _)

Re: Why Not Haskell?

#126

Post by gnuvince »

gnuvince wrote: post #108
SkyMarshal wrote: post #102

Earlier quoted context omitted.

>because I still have problems making really simple Haskell functions that don't crash. Do those functions compile, and then crash anyway? I'd be interested to see examples. In my limited experience, if you can get your code to compile, it's pretty stable. Would be interesting to see counter examples.

I'm at school all day, but I'll post something tonight.

OK, so we were learning about greedy algorithms at school and I implemented a very naive implementation of a change making algorithm for Canadian coins. Here's the Haskell code:

    makeChange :: Int -> [Int]
    makeChange amount = loop 0 [200, 100, 25, 10, 5, 1] []
        where loop total coins@(c:cs) solution
                  | total == amount = solution
                  | null coins = error "no solution"
                  | otherwise = if total + c > amount then
                                    loop total cs solution
                                else
                                    loop (total + c) coins (c : solution)
(I could make this a lot better by returning an [(Int, Int)] and by using integer division, but I wanted to just follow the algorithm described in the textbook.)

To make sure that my code was correct, I wrote a QuickCheck property:

    quickCheck (\(Positive n) -> sum (makeChange n) == n)
However, running this after compiling my file with GHC causes a stack overflow and I need to Ctrl+C out of the process.

On the other hand, the exact same algorithm in OCaml runs extremely quick and without a hicup.

Re: Why Not Haskell?

#127

Post by nightski »

vidarh wrote: post #91
gaius wrote: post #88

Earlier quoted context omitted.

The point is that a whole class of things that you would have to write unit tests for, you get "for free" with strong typing, and for a lot of the others, there's QuickCheck. Or as the old saying goes, why get a dog and bark yourself?

Except you don't get them "for free". You get them in the form a ton of restrictions on you that you need to be mindful of when writing it in the first place. You just pay for it in different ways. The biggest difference is that in dynamic languages, you can sometimes get away with being lazy and not writing the tests to verify the things static languages enforce to varying degrees (whether or not that's a good thing…

Who wants to explore errors? Seriously a well designed array library would not limit exploration at all while preventing one from wasting time with trivial mistakes.

Re: Why Not Haskell?

#128

Post by aangjie »

pnathan wrote: post #98
aangjie wrote: post #94

Earlier quoted context omitted.

//would it be a good ROI? I am only a haskell beginner but i think we can break down this question a little more specific by talking about exact timespan of the projects. From what i understand haskell's maintainability is a huge advantage in some projects with never ending specification changes and feature requests.(ERP??) Anyone has tried haskell for something like that? or were stopped by the chicken-egg problem o…

The key reason I am looking at this kind of technology is because I have a large block of code in a situation where it is very difficult to do functional or unit tests due to system design. Being able to write in a language that statically analyzes my code for all the errors it can before my poor customers encounter it sounds like a huge win. The maintenance goal is being able to catch my fat-fingers and design flaws…

It sounds like other-people-hackability is the real problem for you then. i guess it's hard to convince someone from other programming paradigms to spend the effort and time required to get proficient in haskell.

Re: Why Not Haskell?

#129

Post by gtirloni »

Adaptive wrote: post #36

For those interested in learning Haskell, I can recommend the lesser known "Haskell Road to Logic, Maths, and Programming": http://www.amazon.com/Haskell-Logic-Maths-Programming-Comput... It's great to go over old and new math concepts and do so while exploring Haskell.

I've read numerous Haskell docs online and they are pretty good. However I felt the need for a more in-depth book and I chose "Haskell: The Craft of Functional Programming" (3rd edition) and I'm LOVING it. It's excellent and I recomment it for anyone starting on Haskell.

ps.: I'm not a professional coder and my experience has been on using Python/Shell Script for sysadmin stuff only. However, I constantly read C code to figure out issues and how the book tries to make a parallel between FP and Imperative is quite nice for me.

Re: Why Not Haskell?

#130

Post by joeyh »

gnuvince wrote: post #126
gnuvince wrote: post #108

Earlier quoted context omitted.

I'm at school all day, but I'll post something tonight.

OK, so we were learning about greedy algorithms at school and I implemented a very naive implementation of a change making algorithm for Canadian coins. Here's the Haskell code: makeChange :: Int -> [Int] makeChange amount = loop 0 [200, 100, 25, 10, 5, 1] [] where loop total coins@(c:cs) solution | total == amount = solution | null coins = error "no solution" | otherwise = if total + c > amount then loop total cs so…

quickcheck is running makeChange with an arbitrary Int. maxBound :: Int here is 2147483647. When given a number that large, makeChange recurses a lot, subtracting one two-dollar coin at a time, so you blow the stack. This is where you need to consult a haskell guru to find a way to make your code tail-recursive -- or find a smarter algorithm (using mod c for example so it only needs to recurse 6 times total).

Amusingly, if you simply change the type to Integer -> [Integer], it all works ok. I suspect that since Integers have unbounded size, quickcheck only tests with reasonably small ones.

Post reply on HN