Live data from Hacker News

What was your "ah ha" moment with Haskell?

reddit.com

41–50 of 61 posts

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

#41

Earlier quoted context omitted.

Would that downvotes interested me... To your questions: OcaML: seems like a hack-ish [S]ML. There's a nice comparison between SML and OcaML here : http://adam.chlipala.net/mlcomp/ . I like SML's syntax, but OcaML made it too easy to be imperative and seemed too hackish. Most of the OcaML I've seen looks like weird C, but written in OcaML because it's F4ST3R. F# : I run Linux... next! Scala* : I can't stand it. I use…

[Scala] Type inferencing, but not powerful type inference? In Scala the Hindley–Milner type inferencing is not possible because Scala is OOP, compared to Haskell which isn't. Ocaml does have Hindley-Milner, but not for the OOP features and whenever I played with Ocaml it felt like 2 different type-systems shoved into the same language (much like Obj-C). Scala on the other hand is more consistent, elegant and simpler.…

> And because of implicits, the type-system is also more powerful than what's available in Ocaml and even Haskell.

I don't think that's true. You do the same thing (e.g. collections that choose better representations) via type families/associated data types in Haskell. E.g. in [1] or [2]

That said, what is true is that Odersky has modified the Scala type system in quite interesting ways, specifically to support his collections library. [3]

[1]: http://hackage.haskell.org/package/adaptive-containers

[2]: http://hackage.haskell.org/package/accelerate

[3]: http://lampwww.epfl.ch/~odersky/papers/fsttcs09.html

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

#42
post #18

Earlier quoted context omitted.

Would that downvotes interested me... To your questions: OcaML: seems like a hack-ish [S]ML. There's a nice comparison between SML and OcaML here : http://adam.chlipala.net/mlcomp/ . I like SML's syntax, but OcaML made it too easy to be imperative and seemed too hackish. Most of the OcaML I've seen looks like weird C, but written in OcaML because it's F4ST3R. F# : I run Linux... next! Scala* : I can't stand it. I use…

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?

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

#43

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

But if you implemented Maybe in Java, there still wouldn't be any compile-time guarantee that Nothing would be handled, right? At best you'd have something in code that more strongly encourages a certain convention.

Just now I briefly looked at implementations of Maybe in Java and at least one of them fakes this with checked exceptions, while another seems to lean heavily on Guava's Function interface, which is just awkward to use. I'd certainly be interested in seeing alternative implementations, if you know of any that are decent.

Also, a maybe more serious issue is that since it's not idiomatic Java you'd have to do a lot of wrapping around libraries, and hard-selling to colleagues. Admittedly no longer dealing with flaws in Java's type system, but a big part of a language is the community and ecosystem, and in Haskell's case people using it have already bought on to the advantages of stronger types.

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

#45

Off topic, but my "ah ha" moment with both Clojure and Lisp was this blog post by John Lawrence Aspden: http://www.learningclojure.com/2010/09/clojure-faster-than-m... He managed to get a statement to go as fast the JVM could possibly go, and he did this by getting the code to write code (the code added type castings to every variable, which apparently gave the JVM the info it needed to optimize like crazy). And ther…

>* In other words, this kind of stunt can only be done in a language that allows this kind of code-that-writes-code.*

On the other hand, this kind of stunt will still be a stunt, not a common use case of the language.

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

#46

My "ah ha" moment with Haskell was after a few years of using it quite regularly, I realized that it wasn't actually making me more productive in the kind of code I actually write from day-to-day. It's a lovely language and I wouldn't discourage anyone from using it, but for my purposes I realized it was more exciting than useful at some point, and after that I haven't been back to it as much.

> I realized that it wasn't actually making me more productive in the kind of code I actually write from day-to-day I've got a quip for that in my quotefile: > "Haskell mainly helps with my C++ template coding when I'm doing money oriented programming" -- fnord123

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 without the strict attention to the type system and without having to rigidly separate IO?" Or a bit more sarcastically/cynically, can we get the benefits without having to fundamentally change how we do business? My gut says no, but I'm open to being proved wrong. (Oh, and yeah that's not the only question, there's others like "What about OO? Can we keep it?", but I think that's really the core question; do we really have to rigidly control our side effects or can we keep our sloppy side-effect usage? Everything else is either incidental next to that, or flows from it.)

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

#47
post #18

Earlier quoted context omitted.

Would that downvotes interested me... To your questions: OcaML: seems like a hack-ish [S]ML. There's a nice comparison between SML and OcaML here : http://adam.chlipala.net/mlcomp/ . I like SML's syntax, but OcaML made it too easy to be imperative and seemed too hackish. Most of the OcaML I've seen looks like weird C, but written in OcaML because it's F4ST3R. F# : I run Linux... next! Scala* : I can't stand it. I use…

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?

Why do you say "whitespace is a brain-dead choice" ?

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

#48
post #27

Earlier quoted context omitted.

> There are interesting projects underway for parallel programming (both on CPUs and GPUs) that rely heavily on the type system Are you referring to Accelerate[1]? And isn't Repa[2] stable and usable? [1]: https://github.com/AccelerateHS/accelerate/ [2]: http://repa.ouroborus.net/

Unfortunately, repa and vector are sometimes a few times slower than counterparts in C or C++ for the lack of SIMD intrinsics. Thankfully, things are moving forward fast on that front: http://ghc-simd.blogspot.com/

repa also has some unfortunate lacunae, either in the API or in the documentation.

For instance, one thing I tried to do but couldn't - apply `scanl` to an array with a piece of intermediate state that is threaded through the computation, save the piece of state at the end, and then apply `scanr` to the same array, using the piece of state from the application of `scanl`.

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

#49
post #46

Earlier quoted context omitted.

> I realized that it wasn't actually making me more productive in the kind of code I actually write from day-to-day I've got a quip for that in my quotefile: > "Haskell mainly helps with my C++ template coding when I'm doing money oriented programming" -- fnord123

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.

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

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

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 approach that might salvage conventional programming approaches is a process-based model like Erlang or Go, where each process is internally mutable (mostly unlike Erlang, though it does have the process dictionary), but strictly segmented such that one process can not mutate another's state. This hybrid approach might be viable, and while it's not exactly business-as-usual, it's not as far a trip as full-on IO isolation. (Still, that affords just slamming everything in one process, at which point you don't win much. Will be interesting to watch Go's ecosystem develop and see if goroutines manage to become something deeply and pervasively used in all libraries or a thing occasionally used when the situation is desparate.)

Post reply on HN