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

Haskell in the Large [pdf]

code.haskell.org

Post reply on HN
Print view View original

41–50 of 139 posts

Re: Haskell in the Large [pdf]

#41

Post by mercurial »

saosebastiao wrote: post #25

I've toyed with Haskell, ultimately moving on to the Ocaml/F# camp. There are only two things that I miss from Haskell without an appropriate equivalent or easy workaround: Type Classes, and Higher Kinded Types. This big roadblock that everyone claims with Haskell, Monads, didn't give me any problems at all...even if it didn't make any sense to resort to them to do something as trivial as IO. What really turned me of…

> This big roadblock that everyone claims with Haskell, Monads, didn't give me any problems at all...even if it didn't make any sense to resort to them to do something as trivial as IO.

That's a bit uncharitable. You're likely going to end up working with Lwt (monadic concurrency/IO library) as soon as you need to do something interesting with IO in OCaml.

> Everything seemed to revolve around cool tricks with no practical concern behind them, and then in the comments you inevitably find comments from other Haskellers claiming to do it just a little bit more cleverly using >.

While I agree that showering code in mathematical abstractions doesn't make for readable code, a zipper is not "cleverness for cleverness' sake". It lets you manipulate easily manipulate an immutable tree (and it doesn't decrease readability).

> Ocaml does fine with concurrency, but parallelism is a disaster.

Hopefully the multicore runtime will turn into something concrete eventually :)

It's also lacking real type classes, at least until modular implicits are ready.

Re: Haskell in the Large [pdf]

#42

Post by fsloth »

spopejoy wrote: post #11

“Make illegal states unrepresentable” Types pay off the most on large systems. Architectural requirements captured formally. This more than ANYTHING else is why I want to move enterprisey app code to Haskell. Having worked on numerous ginormous enterprisey systems -- which are usually doing pretty straightforward things, just at scale, and needing to be maintained by non-brilliant developers -- I can say pretty secur…

A sidenote: There is nothing in Java/C++ etc that would stop one from making only legal states representable. It's just easier and more obvious in ML family...

Re: Haskell in the Large [pdf]

#43

Post by mercurial »

eru wrote: post #37
melling wrote: post #8

Has anyone used both Haskell and OCaml (or F#?)? How do they compare in practice? I've been wanting to put some time into a functional language and I've been debating between Haskell and OCaml. Because of F#, OCaml seems like it might be the more practical language (i.e. direct job opportunities). However, excluding F#, Haskell does seem to much more popular than OCaml.

I used both Haskell and OCaml professionally. OCaml's strictness makes some things easier to reason about. Haskell is a nicer language and has more momentum.

OCaml has, IMHO, strong syntactic advantages over Haskell which have a major impact on readability:

- the way you access records (which also means it's not going to clutter your namespace)

- named arguments

- default values

- not an OCaml-the-language property, but there is much less of a race in the OCaml ecosystem to write the shortest variable name possible and accumulate the most ASCII operators

Also, the great module system, with easy abstract types or "public" types with private constructors. By contrast, having to export accessors (if using a lens library) is embarrassing.

Re: Haskell in the Large [pdf]

#44

Post by gergoerdi »

davdar wrote: post #40
eru wrote: post #35

Earlier quoted context omitted.

> Monad stacks do wonders for circumscribing your computational context in an app. Wait until you discover the power of Applicative Functors. They are more restricted in their operations than Monads, so they compose better and allow for analysis.

I'm curious, what do you mean they compose better and allow for analysis [better than monads]?

You can determine a lot more about a computation described only in terms of an applicative functor as you can from a monadic one, without running any of its effects (i.e. "statically").

It's easy to see why when you consider the opaqueness of the function in the right-hand side of a bind. Check out http://gergo.erdi.hu/blog/2012-12-01-static_analysis_with_ap... for an example.

Re: Haskell in the Large [pdf]

#45

Post by dasmoth »

michaelochurch wrote: post #24

I'm really happy to hear about Standard Chartered's success with this, and I want to know more. This is really promising stuff. My current company is looking into our "next generation" platform for when our datasets exceed what we can do in R. R may not be the best language, but it's great for exploratory data science, has the best or the only library out there for some ML purposes, and we've done a lot of things to…

Not something I've used myself yet, but is there any particular reason Julia isn't on that list?

Re: Haskell in the Large [pdf]

#46

Post by lomnakkus »

fsloth wrote: post #42
spopejoy wrote: post #11

“Make illegal states unrepresentable” Types pay off the most on large systems. Architectural requirements captured formally. This more than ANYTHING else is why I want to move enterprisey app code to Haskell. Having worked on numerous ginormous enterprisey systems -- which are usually doing pretty straightforward things, just at scale, and needing to be maintained by non-brilliant developers -- I can say pretty secur…

A sidenote: There is nothing in Java/C++ etc that would stop one from making only legal states representable. It's just easier and more obvious in ML family...

That's only true in the most trivial Turing Tarpit sense, though. Ease of use and defaults matter in practice.

E.g. you can do compile-time exhaustiveness-checked pattern matching using the visitor pattern in Java/C++, but try doing that in practice and the amount of boilerplate just becomes unbearable -- and actually obscures (rather than illuminate) the essence of the data structure.

There's also the lack of higher-kinded types. (Or just plain syntactic pain of using HKTs e.g. in Scala.)

Re: Haskell in the Large [pdf]

#47

Post by tome »

jongraehl wrote: post #27

I wonder why they don't just use GHC with some customization to make the default eval strategy less lazy. I understand why someone might prefer more predictable (strict) evals by default.

They were targeting an already existing runtime for on older in-house functional language, and the runtime only supported strict evaluation.

Re: Haskell in the Large [pdf]

#49

Post by pjmlp »

spopejoy wrote: post #11

“Make illegal states unrepresentable” Types pay off the most on large systems. Architectural requirements captured formally. This more than ANYTHING else is why I want to move enterprisey app code to Haskell. Having worked on numerous ginormous enterprisey systems -- which are usually doing pretty straightforward things, just at scale, and needing to be maintained by non-brilliant developers -- I can say pretty secur…

Another thing is contract programming, but it is really hard to sell to managers where shipping cheap outweights quality.

I don't envision FP or contract based programming in enterprise offshore code.

Re: Haskell in the Large [pdf]

#50

Post by stream_fusion »

melling wrote: post #8

Has anyone used both Haskell and OCaml (or F#?)? How do they compare in practice? I've been wanting to put some time into a functional language and I've been debating between Haskell and OCaml. Because of F#, OCaml seems like it might be the more practical language (i.e. direct job opportunities). However, excluding F#, Haskell does seem to much more popular than OCaml.

My experience is that, Haskell syntax is a dream compared to Ocaml, with 'where' clauses, beautifully simple lambda syntax, do notation support, . and $ composition, typeclass operator overloading.

Ocaml is more practical in a hard to explain way. Much more predictable in terms of it's memory and cpu use with non-lazy default evaluation, and I found much better performing on general code.

Post reply on HN