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

Reflecting on Haskell in 2015

stephendiehl.com

Post reply on HN
Print view View original

101–106 of 106 posts

Re: Reflecting on Haskell in 2015

#101

Post by jjaredsimpson »

kqr wrote: post #88
vans wrote: post #83

Earlier quoted context omitted.

Like Erik Meijer said in his course : there is nothing special or magic about monads. They don't deserve all the fuzz arround them. If you don't get why monads are so awesome, maybe that's a proof that you understood them. Because there is nothing special !! A monad is just a type with 2 functions defined. Like an interface with two methods in OO langages. The 2 functions have to respect some laws but you can imagine…

> You could invent a total different implementation for the list monad, for the maybe monad, etc (if you respect the laws). Could you show such a different implementation for either list or maybe?

    newtype HeadList a = HeadList { getHeadList :: [a] }

    instance Monad HeadList where 
         return a = HeadList [a]
         m >>= f = HeadList $ fmap (head . getHeadList . f) (getHeadList m)
This is a list instance that only keeps the head of function result, so it's basically just a map.

But you could imagine putting any function that returns one result. min max avg normalize, etc

Re: Reflecting on Haskell in 2015

#102

Post by paulddraper »

vans wrote: post #83
PopsiclePete wrote: post #20

Earlier quoted context omitted.

I've tried Haskell 4 times. No joke. I have no problem with currying, higher-order functions, foldl, etc., but Monads. Get. Me. Every. Time. My brain just refuses to fully "grok" them. I still don't see why they're so awesome. I know I use them day-to-day - LINQ, the "List" abstraction (supposedly also a monad??) but I just don't see why it's important to understand them on this whole new fundamentally different leve…

Like Erik Meijer said in his course : there is nothing special or magic about monads. They don't deserve all the fuzz arround them. If you don't get why monads are so awesome, maybe that's a proof that you understood them. Because there is nothing special !! A monad is just a type with 2 functions defined. Like an interface with two methods in OO langages. The 2 functions have to respect some laws but you can imagine…

It's just the name. Whatever a monad is, it must be worth the name.

(Yes, I know the history of the term.)

Re: Reflecting on Haskell in 2015

#103

Post by ky3 »

jjaredsimpson wrote: post #101
kqr wrote: post #88

Earlier quoted context omitted.

> You could invent a total different implementation for the list monad, for the maybe monad, etc (if you respect the laws). Could you show such a different implementation for either list or maybe?

newtype HeadList a = HeadList { getHeadList :: [a] } instance Monad HeadList where return a = HeadList [a] m >>= f = HeadList $ fmap (head . getHeadList . f) (getHeadList m) This is a list instance that only keeps the head of function result, so it's basically just a map. But you could imagine putting any function that returns one result. min max avg normalize, etc

    -- const [] for a HeadList
    quux :: a -> HeadList a
    quux = HeadList . (const [])

    *Main> HeadList "hello... no wait" >>= quux
    HeadList {getHeadList = "*** Exception: Prelude.head: empty list
Such breakage is verboten. This monad instance does not fly.

Re: Reflecting on Haskell in 2015

#104

Post by mikemcgowan »

distance :: { x :: Number, y :: Number } -> Number

distance point = sqrt(point.x^2 + point.y^2)

The function application of sqrt shouldn't have parens.

And the type of distance should be

distance :: forall r. { x :: Number, y :: Number | r} -> Number

Otherwise, it's not row-polymorphic and you wouldn't be able to apply distance to a record of type Point3D.

Re: Reflecting on Haskell in 2015

#105

Post by elihu »

soperj wrote: post #30

I've learned haskell at the university level, and really enjoyed it(and found it very easy to pick up), but find it puzzling where I should use it. It's very easy to say this problem requires a scripting language, and this problem is better suited for an object oriented language, but I don't quite understand what problems would be easier with a functional language. At least in terms of problems that I want solved.

Generally speaking, most programs could be written in either Haskell or an imperative language without much trouble (assuming you're comfortable with the language), though some problems are better suited to Haskell than others.

The way I see it, if you want to extend your language to be able to express solutions to your problem in terms that are close to your problem domain, then Haskell is probably a good choice.

If you would rather transform your problem into constructs that are easily understood in terms of the low-level operations performed by a computer, then you might be better off with a low-level imperative language.

To put it another way, if your requirements include things like deterministic real-time scheduling, strict performance or memory requirements, anything involving assembly language or cachelines, then you should probably use something like C or C++ or Rust.

On the other hand, if you don't care about any of that and you just want your program to compute the right answer in a reasonable amount of time and you want to have high confidence that it's right, then Haskell is a pretty good choice.

Re: Reflecting on Haskell in 2015

#106

Post by dllthomas »

progman wrote: post #98
LukeHoersten wrote: post #3

Earlier quoted context omitted.

Haskell's learning curve is certainly steeper than other popular general programming languages. But my view on that is best explained with an analogy: calculus is certainly harder to learn than arithmetic approximations but once learned, the complexity of calculus is factored out of all the problems suited for solving with it. Haskell is excellently suited for solving extremely complex problems and why it's so desira…

> Haskell is excellently suited for solving extremely complex problems I doubt that seriously. Could you write a complete Mars landing project in Haskell for instance? That would impress me. That's the area where Ada excels, or (less impressive) C and FramaC. But Haskell? No way. AFAIK there is not one serious large project written in Haskell There is not even one sophisticated Haskell IDE for daily use written in Ha…

"Could you write a complete Mars landing project in Haskell for instance? That would impress me. That's the area where Ada excels, or (less impressive) C and FramaC. But Haskell? No way."

Depending on what you mean by "in Haskell", probably. You can write hard-realtime software in an embedded DSL in Haskell that gives you explicit control over timings, scheduling, etc, while still giving you Haskell's higher order features for composing your programs.

https://hackage.haskell.org/package/atom

As I understand, the company that wrote it uses it in production in automotive systems.

Post reply on HN