Haskell in the Large [pdf] • Hacker News Board

Re: Haskell in the Large [pdf]

#131

Post by dkarapetyan » Fri, Jan 30, 2015, 7:34 AM UTC

eru wrote: post #35

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…

> 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.

Mathematically speaking applicatives are less restrictive since more things can be applicatives than monads. A monad is a "very special" kind of functor and that is why a composition of monads often fails to satisfy the monad laws. The least restricted thing in this hierarchy is the functor since composition and other kinds of operations always give you back another functor.

Re: Haskell in the Large [pdf]

#132

Post by evincarofautumn » Fri, Jan 30, 2015, 10:21 AM UTC

codygman wrote: post #122

evincarofautumn wrote: post #121

Earlier quoted context omitted.

I have used all three languages professionally—Haskell & some OCaml at Facebook, and some F# at Xamarin—and would recommend learning Haskell. There’s a strong community around Haskell, with a decent library ecosystem and high-quality implementations, and learning it will make it easy to pick up F# or OCaml—the reverse is not necessarily true. F# is a decent choice if you want to write functional code in .NET land, bu…

> OCaml is a good language, but I would recommend against it. Like F#, it has some syntactic and semantic conveniences that Haskell lacks. I haven't had a chance to use OCaml or F# yet, what syntactic and semantic conveniences are you talking about?

For example, OCaml has an object system (the “O”), polymorphic variants (somewhere between ADTs and symbols), parameterised/first-class modules, and named/optional function parameters. A lot of these things have suitable replacements in Haskell, they’re just not in the language directly. And of course, Haskell has plenty of features that OCaml and F# lack, such as pervasive purity, typeclasses, and an array of useful advanced type system features. It’s tradeoffs all the way down. :)

Re: Haskell in the Large [pdf]

#133

Post by tel » Fri, Jan 30, 2015, 1:56 PM UTC

lomnakkus wrote: post #118

tel wrote: post #114

Earlier quoted context omitted.

Agda's emacs-mode is probably the most developed form of this available today, although Coq's tactics are doing roughly the same thing. Types can't be wrong in the same way that values can be. Rather, to be more specific, in any circumstance where program derivation could even remotely succeed you will have had to have been specific enough with your types that they cannot easily produce the wrong code. It simply woul…

I really like this analogy to interactive games, thanks! I kind of see, logically, that the types can't be wrong in quite as many ways as the code/values/terms, but that's still a (possibly) infinite amount of wrong to contend with! Yes, we can, and frequently do, narrow it down, but still... :) I've been aware of Mr. McBride's literature for some time, but I haven't ventured in beyond a cursory look at that ridiculo…

The thing about being wrong with types is that the end result is an immediate compiler failure. It can be difficult to figure out the right types, but once you do they're certain to behave properly. Thus, the penalty for wrongness is nearly nothing at all.

You face the infinite amount of wrong by working really hard to understand the right.

If you're wrong in values it'll probably still work for a while until it suddenly doesn't for rather mysterious reasons. This can be way down the line, undetected for a long time if not forever. Thus, the pain of being wrong is potentially infinite as well.

So, programming in types is no easier. It's probably even harder today since so few people do it. But the consequences are amazingly different.

And yeah, with Conor's work its "come for the puns, stay for the mind blowing computer science"

Re: Haskell in the Large [pdf]

#134

Post by tel » Fri, Jan 30, 2015, 1:59 PM UTC

thinkpad20 wrote: post #120

tel wrote: post #115

Earlier quoted context omitted.

Oh! I've used Ur a bit and spoken to Adam about it briefly. He gave a talk on Ur at Haskell Boston. I wasn't actually aware that it had typeclasses (though it surely has modules). Honestly, Ur is completely ingenious but there remains an enormous challenge getting it away from being entirely Adam's project. It's completely web-only right now (although Ur is supposedly a more generalized language) as the only compiler…

By the way, Adam is apparently going to be a lecturer at OPLSS this summer. That kind of event seems right up your alley; have you ever gone? Any plans to go this summer? I'm hoping to attend.

I watch all the lectures! I really really really want to go but can never afford it timewise. :(

Re: Haskell in the Large [pdf]

#135

Post by tel » Fri, Jan 30, 2015, 2:01 PM UTC

michaelochurch wrote: post #22

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 tend to think of OCaml as a functional C. It's strict and not purely functional. You can write for-loops and while-loops if you want (but you shouldn't) and use refs to have mutable state (but you shouldn't). It has a better module system than Haskell, but doesn't have type classes. It has functors, which are equivalent-- OCaml's functor is an operation over modules and only very loosely connected (through type the…

I'd really love to be able to think of ATS as "functional C"!

(Not that I actually do. Maybe someday).

Re: Haskell in the Large [pdf]

#136

Post by lomnakkus » Sat, Jan 31, 2015, 8:17 PM UTC

tel wrote: post #133

lomnakkus wrote: post #118

Earlier quoted context omitted.

I really like this analogy to interactive games, thanks! I kind of see, logically, that the types can't be wrong in quite as many ways as the code/values/terms, but that's still a (possibly) infinite amount of wrong to contend with! Yes, we can, and frequently do, narrow it down, but still... :) I've been aware of Mr. McBride's literature for some time, but I haven't ventured in beyond a cursory look at that ridiculo…

The thing about being wrong with types is that the end result is an immediate compiler failure. It can be difficult to figure out the right types, but once you do they're certain to behave properly. Thus, the penalty for wrongness is nearly nothing at all. You face the infinite amount of wrong by working really hard to understand the right. If you're wrong in values it'll probably still work for a while until it sudd…

> the penalty for wrongness is nearly nothing at all.

Well, I think Edwin Brady showed a couple of C++-template-errmsg-like-things during a couple of his talks, but having actually programmed semi-advanced C++-template things I think I can agree on the general thrust that type-level problems are in some sense "better problems to have".

Btw, thanks for the exchange. (This is getting too off-topic, so I'll leave it at that.)

Re: Haskell in the Large [pdf]

#137

Post by codygman » Sun, Feb 01, 2015, 2:23 AM UTC

mercurial wrote: post #72

stream_fusion wrote: post #50

Earlier quoted context omitted.

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.

Funny, I have the opposite experience. Where clauses force you to look down and then up again (bonus if you managed to use both let and where in the same function!). The lambda syntax is a matter of debate, writing "fun" instead of "\" doesn't bother me and is, IMHO, clearer. OCaml has an equivalent of $ with @@, but I haven't seen it used very much, since chaining functions with |> is so convenient. OCaml does not h…

> However, one thing you're unlikely to find in OCaml and which is unfortunately not uncommon in Haskell is functions with a long list of positional parameters (since you have named arguments) or different versions of the same function with a "_" suffix, depending on various defaults (since you have named arguments). It makes a tremendous difference of readability when dealing with complex code.

Can you give an example, I'm interested in seeing what you mean but having trouble figuring out what an example would look like.

Re: Haskell in the Large [pdf]

#138

Post by codygman » Sun, Feb 01, 2015, 3:25 AM UTC

AnimalMuppet wrote: post #104

tel wrote: post #75

Earlier quoted context omitted.

Just imagine that every static constraint you want to encode has to be written in the language of the types, a subset of your chosen language. C's language of types is incredibly primitive. Haskell's is quite nice. Agda/Idris/Coq's type language is technically equivalent to its value language so you can encode incredible things. It turns out that due to people's general desire for compilation to always terminate that…

"It turns out that due to people's general desire for compilation to always terminate that the type language behaves quite different from the value language. It also turns out that the type language operates differently because we're more interested in logical constraints than actual evaluation." If I understand you correctly, if the type system behaves the same as the value system, then it is possible for the compil…

Unrelated but you don't have contact information and this is the most related thread I could find. Here is context:

" I've been trying to get my mind around this kind of stuff for maybe a year. And I have to say that monads don't look like the solution to any of the problems that I actually face or have ever faced, in a thirty-year career." - https://news.ycombinator.com/item?id=8815973

Re: Haskell in the Large [pdf]

#139

Post by eru » Mon, Feb 09, 2015, 12:50 AM UTC

mercurial wrote: post #43

eru wrote: post #37

Earlier quoted context omitted.

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 m…

Actually, (some form of) default values are easy to add to Haskell. We did so at Standard Chartered.