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

What was your "ah ha" moment with Haskell?

reddit.com

Post reply on HN
Print view View original

51–60 of 61 posts

Re: What was your "ah ha" moment with Haskell?

#51

Post by heretohelp »

hencq wrote: post #42
mahmud wrote: post #18

Earlier quoted context omitted.

I don't think you understand either ML or Lisp. SML would never make whitespace significant because: 1) that's a brain-dead choice, and 2) ML, much like Lisp, is used as a language, as a notation, and as a "kernel" language. Clojure without dynamic-typing is bath-water without baby. What is the point of interactivity, homoiconicity and macros if the language is statically typed?

Is there any specific reason why macros can't work in a statically typed language? How does Typed Racket handle this. Or does it not have macros?

Typed Racket is more like type annotations with a checking routine than anything, if you're writing a macro you want generality.

You achieve this by omitting the type annotation and reverting to normal Racket.

You can do macros in a statically typed language, but it would (and does) get ugly fast.

Re: What was your "ah ha" moment with Haskell?

#52

Post by gtani »

tonetheman wrote: post #26

Ha already been said, but my ah ha came when after reading quite a bit about it. I realized I was incapable of understanding it and moved on. :)

dont' give up! Remmeber your friends.

    Hoogle is your friend

    the REPL is your friend
(typeclassopedia, too, but that's for later). The point is to get into the REPl and start defining the contours of the type system, monomorphism restriction, inference, etc, in your mind

Re: What was your "ah ha" moment with Haskell?

#53

Post by pka »

sseveran wrote: post #49
jerf wrote: post #46

Earlier quoted context omitted.

I've noticed that slowly, but surely, Haskell really is winning. C++ is now basically running as fast as it can to become Haskell. It's such an old language with so much baggage that "as fast as it can" isn't very fast at all, and it has no chance of ever reaching it, but the trendline is clear. The question the programming community faces over the next, oh, ten years or so, is "Can we get the benefits of Haskell wit…

The answer is no. Marking side effects is the one thing, probably more than any other that makes haskell awesome for building applications. For instance STM is awesome in Haskell because it is easy for the compiler to see any and all side effects. The real thing that would be cool would be a strict haskell with optional laziness.

For all my love of Clojure, having used its STM implementation I can wholeheartedly agree with this.

Having side effects in a transaction occur more than once because you didn't pay attention is a real pain to debug, mostly because the transaction won't be retried until the program is exposed to heavy load leading to serious memory contention.

At that point, debugging concurrent designs turns into a nightmare, not being any better than having to deal with deadlocks etc, the very thing STM is supposed to magically make go away. In some cases I even had to resort to locks because it was easier to handle IO that way.

Now, Haskell's type system would just not allow having any sort of IO side effects inside a STM transaction. Yes, having to explicitly handle IO may sound as a lot of work, but in my experience it makes everything easier.

Re: What was your "ah ha" moment with Haskell?

#54

Post by masklinn »

jerf wrote: post #50
sseveran wrote: post #49

Earlier quoted context omitted.

The answer is no. Marking side effects is the one thing, probably more than any other that makes haskell awesome for building applications. For instance STM is awesome in Haskell because it is easy for the compiler to see any and all side effects. The real thing that would be cool would be a strict haskell with optional laziness.

As I said, my gut agrees with you, but I think that given the relative newness of this idea, that the programming community at large should be given some time to make the case that the benefits can be obtained without so much of the cost. There's only a bare handful of languages that have even taken a serious swing at it, like Clojure and lately D. I want more evidence before I call it. Probably the most promising ap…

> mostly unlike Erlang, though it does have the process dictionary

Yes and no, while Erlang structures are not mutable (aside from the process dictionary, and the process's message queue), each new iteration of the process loop mutates the process itself, as the process goes from one state to an other.

Re: What was your "ah ha" moment with Haskell?

#55

Post by masklinn »

jonsterling wrote: post #22
spacemanaki wrote: post #9

Earlier quoted context omitted.

> Now when I go back to Java I often get frustrated and the amount of code I have to write simply to work around the fact that functions are not first class objects. Frankly, I've mostly gotten over Java's lack of first-class functions and just make do with the boilerplate involved with regular for-loops or with anonymous implementations of interfaces that are just stand-ins for functions, etc. What I really struggle…

Remember, Maybe and Either are not language features in Haskell, but rather library features! Java is totally capable of hosting them. (Though, there isn't any special syntax for tuples in Java).

> Java is totally capable of hosting them.

No, because your Maybe or Either reference may still be null, so you get "Maybe fuck you" and "Either fuck you, or fuck you". That's the first part.

The second part is, due to the lack of match completeness check (or more generally match) and the shitty type system, APIs forcing developers to safely unwrap or rewrap values are... shitty.

Re: What was your "ah ha" moment with Haskell?

#56

Post by jerf »

masklinn wrote: post #54
jerf wrote: post #50

Earlier quoted context omitted.

As I said, my gut agrees with you, but I think that given the relative newness of this idea, that the programming community at large should be given some time to make the case that the benefits can be obtained without so much of the cost. There's only a bare handful of languages that have even taken a serious swing at it, like Clojure and lately D. I want more evidence before I call it. Probably the most promising ap…

> mostly unlike Erlang, though it does have the process dictionary Yes and no, while Erlang structures are not mutable (aside from the process dictionary, and the process's message queue), each new iteration of the process loop mutates the process itself, as the process goes from one state to an other.

Erlang values are not mutable. You can't have a 4, lose the execution pointer to another process, and when it comes back you suddenly have a 5 in that variable. (Barring arbitrary C, of course.) That's the aspect of "immutable" that matters from a multithreading point of view. For most of what Erlang does, it would be fine to have mutable variables but immutable values, as if everything were as immutable as a Python string but you could freely reuse variable labels just as you can set a = "A", then a = "B" in Python. I think that's basically what Go does, though I haven't quite studied it enough to be sure.

Re: What was your "ah ha" moment with Haskell?

#57

Post by masklinn »

jerf wrote: post #56
masklinn wrote: post #54

Earlier quoted context omitted.

> mostly unlike Erlang, though it does have the process dictionary Yes and no, while Erlang structures are not mutable (aside from the process dictionary, and the process's message queue), each new iteration of the process loop mutates the process itself, as the process goes from one state to an other.

Erlang values are not mutable. You can't have a 4, lose the execution pointer to another process, and when it comes back you suddenly have a 5 in that variable. (Barring arbitrary C, of course.) That's the aspect of "immutable" that matters from a multithreading point of view. For most of what Erlang does, it would be fine to have mutable variables but immutable values, as if everything were as immutable as a Python…

> Erlang values are not mutable. You can't have a 4, lose the execution pointer to another process, and when it comes back you suddenly have a 5 in that variable. (Barring arbitrary C, of course.) That's the aspect of "immutable" that matters from a multithreading point of view.

Which is of no relevance to Erlang in the first place, since it does not expose threads to the developer.

> I think that's basically what Go does, though I haven't quite studied it enough to be sure.

Go has mutable structures and mutable bindings.

Re: What was your "ah ha" moment with Haskell?

#58

Post by jerf »

masklinn wrote: post #57
jerf wrote: post #56

Earlier quoted context omitted.

Erlang values are not mutable. You can't have a 4, lose the execution pointer to another process, and when it comes back you suddenly have a 5 in that variable. (Barring arbitrary C, of course.) That's the aspect of "immutable" that matters from a multithreading point of view. For most of what Erlang does, it would be fine to have mutable variables but immutable values, as if everything were as immutable as a Python…

> Erlang values are not mutable. You can't have a 4, lose the execution pointer to another process, and when it comes back you suddenly have a 5 in that variable. (Barring arbitrary C, of course.) That's the aspect of "immutable" that matters from a multithreading point of view . Which is of no relevance to Erlang in the first place, since it does not expose threads to the developer. > I think that's basically what G…

"Which is of no relevance to Erlang in the first place, since it does not expose threads to the developer."

It may not expose them to the developer in the sense that they are available for the developer to directly manipulate, but it is certainly exposed that multiple cores may be running Erlang simultaneously. To the extent that it isn't relevant to Erlang, it is because Erlang has made it not relevant to Erlang by a conscious choice of the developers, not some sort of accident.

"Go has mutable structures and mutable bindings."

Yes, I said that, but can a structure owned by one goroutine be directly modified by another such that a single goroutine can observe that a reference has changed values which the goroutine in question has not changed? Do structures even belong to goroutines? One of the things that turned me off when I looked at it a while ago was that the docs were giving me a hard time answering this question, but I consider it a rather fundamental one. (But this was a while ago, much closer to its beginning.)

Re: What was your "ah ha" moment with Haskell?

#59

Post by masklinn »

jerf wrote: post #58
masklinn wrote: post #57

Earlier quoted context omitted.

> Erlang values are not mutable. You can't have a 4, lose the execution pointer to another process, and when it comes back you suddenly have a 5 in that variable. (Barring arbitrary C, of course.) That's the aspect of "immutable" that matters from a multithreading point of view . Which is of no relevance to Erlang in the first place, since it does not expose threads to the developer. > I think that's basically what G…

"Which is of no relevance to Erlang in the first place, since it does not expose threads to the developer." It may not expose them to the developer in the sense that they are available for the developer to directly manipulate, but it is certainly exposed that multiple cores may be running Erlang simultaneously. To the extent that it isn't relevant to Erlang, it is because Erlang has made it not relevant to Erlang by…

> it is certainly exposed that multiple cores may be running Erlang simultaneously.

Sure, but there is absolutely no way that values can change "under your feet" within a process since processes don't share memory. Even if objects were mutable within a given process that would make no difference.

> Yes, I said that, but can a structure owned by one goroutine be directly modified by another such that a single goroutine can observe that a reference has changed values which the goroutine in question has not changed?

Not sure what you mean by "a single goroutine can observe that a reference has changed value". If a structure is not local to a goroutine A (because it was carried through a pipe or was created in a lexical scope other routines can see), then other goroutines will be able to alter it yes, as to whether A will be able to see that, well unless A memoized the old value (by deep-cloning the structure) A will see new values and not old ones.

> Do structures even belong to goroutines?

Go has no built-in concept of ownership, so that question is a bit tricky. Structures are only exclusive to a given goroutine if they are not visible by or shared with other routines. So if the structure in question has been created in a scope making it visible by multiple goroutines, or it has been carried across a channel to an other goroutine, then other goroutines will be able to modify it from "under your feet".

Re: What was your "ah ha" moment with Haskell?

#60

Post by jonsterling »

masklinn wrote: post #55
jonsterling wrote: post #22

Earlier quoted context omitted.

Remember, Maybe and Either are not language features in Haskell, but rather library features! Java is totally capable of hosting them. (Though, there isn't any special syntax for tuples in Java).

> Java is totally capable of hosting them. No, because your Maybe or Either reference may still be null, so you get "Maybe fuck you" and "Either fuck you, or fuck you". That's the first part. The second part is, due to the lack of match completeness check (or more generally match) and the shitty type system, APIs forcing developers to safely unwrap or rewrap values are... shitty.

Whilst you're mostly right about the second bit, your first complaint really isn't valid, since in Haskell, every value is basically "My Type + Fuck You" (because codata isn't distinguished from data).

fuckYou :: a

fuckYou = fuckYou

justTrolling = Just fuckYou

That said, however, I'm very sympathetic to the rejection of non-total languages. But we must note that even though Haskell is inconsistent as a logic, it is still able to derive tolerable advantage from the use of option types, etc.

Post reply on HN