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

41–50 of 240 posts

Re: I learned Haskell in just 15 years

#41

Post by tome »

fire_lake wrote: post #35
IshKebab wrote: post #28

Earlier quoted context omitted.

I feel like functional programming is pretty trivial. It's pure programming that is very difficult. They're often conflated because Haskell is pure and functional and probably the most talked about heavily functional language. I certainly didn't know that impure functional languages like OCaml existed for ages.

Is Haskell pure? It has exceptions You can divide by zero It has unsafe IO primitives

You're right: "pure" is not a well-defined concept. The well-defined concept that describes Haskell's benefits in this regard is "referential transparency". That means that this code

    let x = 
    in ... x ... x ...
(i.e. defining a variable x and then using it some number of times) is equivalent to

    ...  ...  ...
Seen in the opposite direction (transforming the bottom code to the top code) this means that extracting repeated code is always a valid thing to do. It's not valid in most other languages, and certainly no mainstream ones.

Re: I learned Haskell in just 15 years

#42

Post by __rito__ »

munchler wrote: post #2

Cute. All kidding aside, though, functional programming is worth the effort to learn, and it doesn't actually take 15 years. The payoff is at the end of the article: "It’s quite natural to program in Haskell by building a declarative model of your domain data, writing pure functions over that data, and interacting with the real world at the program’s boundaries. That’s my favorite way to work, Haskell or not." Haskel…

For the benefit(s) that you list, which are the best learning resources for F#?

Re: I learned Haskell in just 15 years

#43

Post by kreyenborgi »

foobazgt wrote: post #30
kreyenborgi wrote: post #27

Earlier quoted context omitted.

Don't think of it as being all pure code, think of it as tracking in the type system which parts of your code may launch the missiles and which parts can't. Given the following program, main :: IO () main = do coordinates IO () launch = -- TODO calcTrajectory :: Coordinates -> Trajectory calcTrajectory = -- TODO I can look at the types and be reasonably certain that calcTrajectory does no reads/writes to disk or the…

FYI, I think you meant functional core, imperative shell.

haha yes, thanks!

Re: I learned Haskell in just 15 years

#44

Post by Dylan16807 »

elbear wrote: post #40
Dylan16807 wrote: post #33

Earlier quoted context omitted.

Is there a benefit if you're already familiar with writing functions like that? Is it wrong for me to expect that most programmers are already familiar with functions that only use their inputs, but treat that style as significantly more optional? I wrote pure functions for a minute there but that's not the same, a function that only uses its inputs can modify an object while a pure function would have to return a ne…

It seems you only focused on one of the conditions I mentioned. You have to follow both rules: the one about inputs and the one about outputs. This is like a contract. If you enforce it throughout your program, you gain some guarantees about your program as a whole.

I was looking at both rules, and specifically I was using the long version where you said "it doesn't assign them to some other global variable that you have to track down". If you pass in a mutable object then that's not "some other global variable".

If I interpret "It only outputs its results" in a very strict way, that still allows having output and in/out parameters. The latter of which can break purity.

Though you can break purity with just inputs:

  define f(o): return o.x
  let a = {x=1}
  f(a)
  a.x = 2
  f(a)
If you meant to describe pure functions then that's fine, that's why I addressed pure functions too, but I don't think your original description was a description of pure functions.

Re: I learned Haskell in just 15 years

#45

Post by jiggawatts »

antonvs wrote: post #10
sidkshatriya wrote: post #4

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

> easy problems tough. That needs a qualifier: it can make easy problems tough if you're not familiar with how to solve them in a functional context. A big part of that is because smart people have already solved the tough problems and made them available as language features or libraries.

Absolutely! Any beginner can readily combine the catamorphisms and anamorphisms in `recursion-schemes`, or use the ready-made hylomorphisms for common tasks such as setting a value in a data structure. What could be simpler? /s

https://wiki.haskell.org/Zygohistomorphic_prepromorphisms

Re: I learned Haskell in just 15 years

#46

Post by elbear »

Dylan16807 wrote: post #44
elbear wrote: post #40

Earlier quoted context omitted.

It seems you only focused on one of the conditions I mentioned. You have to follow both rules: the one about inputs and the one about outputs. This is like a contract. If you enforce it throughout your program, you gain some guarantees about your program as a whole.

I was looking at both rules, and specifically I was using the long version where you said "it doesn't assign them to some other global variable that you have to track down". If you pass in a mutable object then that's not "some other global variable". If I interpret "It only outputs its results" in a very strict way, that still allows having output and in/out parameters. The latter of which can break purity. Though y…

So, another definition of a pure function is that, for a particular input it will always return the same output.

Your example respects the rule:

    f({x=1}) == 1
    f({x=2}) == 2
But it's true that the two rules I gave are not enough to make a function pure. Because I didn't say anything about I/O. So, a function that follows the rules about inputs and outputs, could still do I/O and change its outputs based on that.

Starting from the question that gave birth to this whole thread: "What's the benefit of learning a PURE functional programming language..."

The other benefit is that such a language forces you to be explicit about I/O. It does it in such a way that even functions that do I/O are pure. The good part is that, if you use it long enough, it can teach you the discipline to be explicit about I/O and you can use this discipline in other languages.

For example, this is how I see this principles being used in Python:

https://elbear.com/functional-programming-principles-you-can...

Re: I learned Haskell in just 15 years

#47

Post by cubefox »

antonvs wrote: post #10
sidkshatriya wrote: post #4

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

> easy problems tough. That needs a qualifier: it can make easy problems tough if you're not familiar with how to solve them in a functional context. A big part of that is because smart people have already solved the tough problems and made them available as language features or libraries.

> That needs a qualifier: it can make easy problems tough if you're not familiar with how to solve them in a functional context.

All problems are easy if you are familiar with how to solve them. Unfortunately it's part of the problem to find out how to solve them, and that can be unusually hard in case of functional programming. Like solving something with recursion instead of loops + states. There is a reason cookbooks use loops not recursion.

Re: I learned Haskell in just 15 years

#48

Post by afiori »

fire_lake wrote: post #35
IshKebab wrote: post #28

Earlier quoted context omitted.

I feel like functional programming is pretty trivial. It's pure programming that is very difficult. They're often conflated because Haskell is pure and functional and probably the most talked about heavily functional language. I certainly didn't know that impure functional languages like OCaml existed for ages.

Is Haskell pure? It has exceptions You can divide by zero It has unsafe IO primitives

I feel like exceptions where added as a mix of "look we can do that too" and "maybe if so many functions return optional values then it is going to be too much of a pain to use"

In hindsight I think few would now regret not having added them in the first place.

Re: I learned Haskell in just 15 years

#49

Post by afiori »

fire_lake wrote: post #35
IshKebab wrote: post #28

Earlier quoted context omitted.

I feel like functional programming is pretty trivial. It's pure programming that is very difficult. They're often conflated because Haskell is pure and functional and probably the most talked about heavily functional language. I certainly didn't know that impure functional languages like OCaml existed for ages.

Is Haskell pure? It has exceptions You can divide by zero It has unsafe IO primitives

>It has unsafe IO primitives

To be tongue in cheek then it also has the side effect of heating the CPU.

Re: I learned Haskell in just 15 years

#50

Post by cubefox »

wruza wrote: post #38
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,…

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.

Post reply on HN