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

I learned Haskell in just 15 years

duckrabbit.tech

Post reply on HN
Print view View original

101–110 of 240 posts

Re: I learned Haskell in just 15 years

#101

Post by dboreham »

cubefox wrote: post #50
wruza wrote: post #38

Earlier quoted context omitted.

Hot take of the day: you learn that with imperative programming just as well. I familiarized myself with fp to the point of writing scheme and haskell around 15 years ago. Read the classics, understood advanced typing, lambda calculus and so on. The best “fp” I’m using nowadays is closures, currying in the form of func.bind(this[, first]) and map/filter. Which all are absolutely learnable by the means of closures, wh…

> These FP talks are disguised elitism imo (not necessarily bad faith). Beta reduction and monadic transformers sound so cool, but that’s it job-wise. They may be disguised mathematics. People are into math because it is neat / elegant / cool. So they study it regardless of whether it has a practical use or not.

Mathematics is just a kind of programming. And vice versa.

Re: I learned Haskell in just 15 years

#103

Post by tome »

simiones wrote: post #83
tome wrote: post #67

Earlier quoted context omitted.

> technically that isn't true if you use, for example, unsafePerfomIO in the defintion of x Ah, well, regardless of whether it holds in Haskell, referential transparency is a well-defined concept. Purity is not a well-defined concept (at least as far as I know. Please share a formal definition if you have one!). That's primarily what I'm trying to say. But I also disagree with your point about unsafePerformIO. In pra…

It seems that someone did come up with a formal definition to try to capture the concept [0], though I haven't looked into the details to see whether it really matches the colloquial use of the terms "pure" and "impure" functional programming. In short, the formal definition they came up with is that a language is pure if the result of a valid program is the same under any parameter passing strategy. I should note th…

Sabry's definition of "pure" fails to satisfy me for two reasons:

1. It assumes that the language is "a conservative extension of the simply typed λ-calculus". That's rather high-powered yet also really restrictive! Haskell doesn't satisfy that requirement. It also assumes the language has functions. Expression languages (i.e. ones without functions) are perfectly reasonable languages and it makes sense to ask whether they are pure.

2. It assumes that a language putatively has multiple evaluation orders (which I suppose is a consequence of the assumption "It is a conservative extension of the simply typed λ-calculus"). Haskell doesn't have multiple evaluation orders. It has one! (notwithstanding you can influence it with seq/!)

If you unpick the essence of what Sabry's really saying you find you can translate it into the Haskell world through imposing two conditions:

C1. soundness of the β-axiom (a.k.a. referential transparency) (this plays the role of Sabry's condition that call by need and call by value have the same result).

C2. That

    let x =  in ...
gives the same result as

    let !x =  in ...
whenever the latter terminates. (This plays the role of Sabry's condition that call by name and call by value have the same result.) I omitted this condition from my original. I probably shouldn't have because technically it's required, but it risks getting into the weeds of strictness versus laziness.

So Sabry's definition of "pure" is a long-winded and restricted way saying something that can be much more conveniently expressed by C1 and C2. If you disagree with me, please demonstrate a property of purity that can't be deduced from C1 and C2!

> I should note that I agree that, in practice, Haskell is almost always pure and/or referentially transparent. I was just pointing out that technically the GP was correct that it's not perfectly 100% so.

OK, fine, but I also said the GP was correct! I am keen to point out, however, that exceptions (including division by zero) do not violate referential transparency (and if someone thinks they violate "purity" that may be a sign that "purity" is ill-defined).

Re: I learned Haskell in just 15 years

#104

Post by usgroup »

Valodim wrote: post #100
usgroup wrote: post #88

In my opinion, if you are after the mystical experience of understanding functional programming, you're better off learning Prolog. I think it has more to offer in terms of insight, because wrapping your head around the language only takes a couple days, but wrapping your head around its consequences is a gift which keeps on giving for quite some time. Immutable functional programming is basically what 80% of your Pr…

Prolog is a logic programming language though, I wouldn't expect it to have a lot of overlap with functional programming?

Prolog variables are immutable by default. Data structures are the same as the immutable functional programming counterparts (no arrays, and tree based everything). Recursion is the only way to loop. Map, filter, fold(l/r), reduce, accumulate, etc, are staple predicates.

As I said, 80% of your code, or more, will look just like a functional programme.

Re: I learned Haskell in just 15 years

#105

Post by tome »

simiones wrote: post #97
chuckadams wrote: post #89

Earlier quoted context omitted.

> My favorite example of this is implementing quicksort. It's significantly easier in C than it is in Haskell. Oh please, what's so hard about qsort :: Ord a => [a] -> [a] qsort [] = [] qsort (p:xs) = qsort lesser ++ [p] ++ qsort greater where lesser = filter ( = p) xs :) folks, take that with a big ol /s, you would never want to actually use that algorithm. But the real deal isn't all that awful: https://mmhaskell.c…

Well, I'd say using an entirely different collection type than the rest of language (STArray instead of [a]) is already a big complication. It also ends up being more than double the size of the Java code. And, as the author admits, it's actually even slower than the original not-quicksort implementation above, because it actually has to make a copy of the original list, and then return a copy of the mutated array. S…

> I'd say using an entirely different collection type than the rest of language (STArray instead of [a]) is already a big complication

Haskell uses many different collection types, just like any other language. Why not?

> it's actually even slower than the original not-quicksort implementation above, because it actually has to make a copy of the original list, and then return a copy of the mutated array.

Sure, but it could also not do that, if callers are happy to provide a mutable array, just like any other language ...

> one of the best sorting algorithms ever devised is not actually usable to sort a [a] in Haskell

Indeed! One of the best algorithms for sorting a mutable array can't be used on an immutable data type, just like any other language ...

None of this invalidates your original claim that "It's significantly easier in C than it is in Haskell" of course.

Re: I learned Haskell in just 15 years

#106

Post by hnfong »

chuckadams wrote: post #89
simiones wrote: post #86

Earlier quoted context omitted.

Not really, certain problems are just inherently harder to express in a purely functional way than they are in an imperative way (and the reverse is just as true). For example, computing a histogram is much simpler in imperative terms (keep an array of histogram values, go through the original list, add 1 to the array element corresponding to the current element in this list) than in a purely functional style, especi…

> My favorite example of this is implementing quicksort. It's significantly easier in C than it is in Haskell. Oh please, what's so hard about qsort :: Ord a => [a] -> [a] qsort [] = [] qsort (p:xs) = qsort lesser ++ [p] ++ qsort greater where lesser = filter ( = p) xs :) folks, take that with a big ol /s, you would never want to actually use that algorithm. But the real deal isn't all that awful: https://mmhaskell.c…

Arguably the issue with "quicksort in Haskell" is not that it's "hard" to implement, but rather it defeats the whole purpose of using a "purely functional" language.

The pragmatic way to look at Haskell is not that it's purely functional, but rather, you could write imperative code Monads if you wanted, and that gives a "functional by default" environment, whereas most imperative languages default to mutable objects etc that are not friendly to functional-style programming.

But then the more modern languages are catching on with immutable by default variables etc. so in the end the differences between newer languages may not be that great after all...

Re: I learned Haskell in just 15 years

#107

Post by chuckadams »

simiones wrote: post #97
chuckadams wrote: post #89

Earlier quoted context omitted.

> My favorite example of this is implementing quicksort. It's significantly easier in C than it is in Haskell. Oh please, what's so hard about qsort :: Ord a => [a] -> [a] qsort [] = [] qsort (p:xs) = qsort lesser ++ [p] ++ qsort greater where lesser = filter ( = p) xs :) folks, take that with a big ol /s, you would never want to actually use that algorithm. But the real deal isn't all that awful: https://mmhaskell.c…

Well, I'd say using an entirely different collection type than the rest of language (STArray instead of [a]) is already a big complication. It also ends up being more than double the size of the Java code. And, as the author admits, it's actually even slower than the original not-quicksort implementation above, because it actually has to make a copy of the original list, and then return a copy of the mutated array. S…

quicksort2 has a very reasonable constraint of Array, it's the helpers that use the STArray implementation. I suspect it wouldn't be hard to port to MArray, though I don't know that it would perform any better (maybe avoiding some copies since MArray is actually usable outside of runST). I also suspect the overhead of the copies pays off with larger lists given the lack of space leaks compared to the naive algorithm. Some benchmarks of different-sized lists would have been nice.

I'm not a cheerleader for Haskell, it's not the most appropriate language for every job (certainly not for quicksort). But some folks suddenly become hyper-optimizing assembly programmers whenever anyone has the thought of porting a sql crud app to another language... Horses for courses and all that.

Re: I learned Haskell in just 15 years

#108

Post by chrischen »

sidkshatriya wrote: post #4
initplus wrote: post #3

Earlier quoted context omitted.

Yes - the value of functional programming isn't that working in OCAML, or F#, or Haskell is 10x as productive as other languages. But that it can teach you worthwhile lessens about designing software that apply equally to imperative languages. Modelling the business domain, reasoning and managing side effects, avoiding common imperative bugs, these are all valuable skills to develop. F# is a great language to learn,…

> Yes - the value of functional programming isn't that working in OCAML, or F#, or Haskell is 10x as productive as other languages. This is not true in my personal experience. As has been famously said (paraphrased): Functional programming makes tough problems easy and easy problems tough. In other words the value of functional programming depends on your domain.

It’s only tough to change your way of thinking. Most people making the switch find it tough because they are trying to find imperative techniques to do something in a functional way and struggling because they can’t find an if else statement or a for loop. But if you were never taught to think in terms of conditional branching or looping indexes you’ll save a lot of time.

Re: I learned Haskell in just 15 years

#109

Post by pyuser583 »

sidkshatriya wrote: post #4
initplus wrote: post #3

Earlier quoted context omitted.

Yes - the value of functional programming isn't that working in OCAML, or F#, or Haskell is 10x as productive as other languages. But that it can teach you worthwhile lessens about designing software that apply equally to imperative languages. Modelling the business domain, reasoning and managing side effects, avoiding common imperative bugs, these are all valuable skills to develop. F# is a great language to learn,…

> Yes - the value of functional programming isn't that working in OCAML, or F#, or Haskell is 10x as productive as other languages. This is not true in my personal experience. As has been famously said (paraphrased): Functional programming makes tough problems easy and easy problems tough. In other words the value of functional programming depends on your domain.

How do you “Hello World” in a functional language? Doesn’t it have side effects?

Re: I learned Haskell in just 15 years

#110

Post by lukan »

itishappy wrote: post #98
lukan wrote: post #93

Earlier quoted context omitted.

Pandoc seems useful, but maybe "mass market" is a bit of an overstatement? And since many programmers like myself had to learn Haskell, I think Haskell should have a better head start and be in a better position, if it would be so useful for "real world" use cases. But please don't take this as an attack on haskell. I have nothing against the language, or its users and I did not suffered because of it in university,…

Pandoc is the standard for markdown conversion. Check out the comments in this recent thread (or pretty much any thread where markdown is mentioned): https://news.ycombinator.com/item?id=40695628 https://hn.algolia.com/?q=markdown

I don't think markdown conversion is a mass market application, but maybe personally I will indeed use it soon, so that would be something I guess ..
Post reply on HN