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

31–40 of 240 posts

Re: I learned Haskell in just 15 years

#31

Post by zogrodea »

TrackerFF wrote: post #12

What's the benefit of learning a PURE functional programming language, opposed to just using a language which has adapted the best bits and pieces from the functional programming paradigm? Given that you want write code that sees "real world" use, and is used to handle data and events from the real world. To me, sometimes the line between optimized code and intellectual curiosity blurs.

I can't speak for others, but I never really understood the benefits of functional programming when my language pretty much allowed unbounded mutation anywhere. I would say there's a chance for impure languages to impede you in learning what functional programming is about (or at least my experience with F# and OCaml did not really help as much as it otherwise could have I think).

Your mileage might vary, but I've heard advice from others to learn Haskell and "go off the deep-end" because of people citing similar reasons.

Re: I learned Haskell in just 15 years

#32

Post by Barrin92 »

kreyenborgi wrote: post #27
TrackerFF wrote: post #12

What's the benefit of learning a PURE functional programming language, opposed to just using a language which has adapted the best bits and pieces from the functional programming paradigm? Given that you want write code that sees "real world" use, and is used to handle data and events from the real world. To me, sometimes the line between optimized code and intellectual curiosity blurs.

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…

>as tracking in the type system which parts of your code may launch the missiles

given that Haskell is lazy by default there's a million ways to shoot yourself in the foot through memory leaks and performance issues (which is not unlike the problems the IO type attempts to make explicit in that domain), so I never really understand this kind of thing. Purity doesn't say much about safety or semantics of your code. By that logic you might as well introduce a recursion type and now you're tagging everything that is recursive because you can easily kill your program with an unexpected input in a recursive function. To me this is just semantics you have to think through anyway, putting this into the type system just ends up creating more convoluted programs.

Re: I learned Haskell in just 15 years

#33

Post by Dylan16807 »

elbear wrote: post #26
TrackerFF wrote: post #12

What's the benefit of learning a PURE functional programming language, opposed to just using a language which has adapted the best bits and pieces from the functional programming paradigm? Given that you want write code that sees "real world" use, and is used to handle data and events from the real world. To me, sometimes the line between optimized code and intellectual curiosity blurs.

What's the benefit? You start to see functions as self-contained things, as lego blocks. All the logic of the function is there in the function. It only works on values it receives as inputs (it can't read global variables). It only outputs its results (it doesn't assign them to some other global variable that you have to track down). This makes your code modular. You can add a function in a chain of functions, if yo…

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 new object. But, similarly, I bet that a lot more people know about pure functions than have any working knowledge of Haskell.

Re: I learned Haskell in just 15 years

#34

Post by realPtolemy »

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…

Or Elixir! Quite easy to grasp as well.

Re: I learned Haskell in just 15 years

#35

Post by fire_lake »

IshKebab wrote: post #28
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…

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

Re: I learned Haskell in just 15 years

#36

Post by fire_lake »

leononame wrote: post #16

Great read! Can anyone here recommend a good resource for learning Haskell that's in the style of "Text-Mode Games as First Haskell Projects"? Haskell has been on my radar since forever, and I've got some FP concepts internalized by making a side project in F#, but I have no idea what a monad really is and a fun prohect to code along might be perfect.

Write a few computation Expression builders in F# and monads will quickly make sense.

Re: I learned Haskell in just 15 years

#37

Post by armchairhacker »

munchler wrote: post #19
nequo wrote: post #6

Earlier quoted context omitted.

That’s interesting because F#’s OOP, as someone who knows neither C# nor Java, makes it more intimidating to me than OCaml. Also interesting that when FP is mentioned, Hindley-Milner is implicitly understood to be part of FP too even though it doesn’t have to be. Clojure emphasizes immutability and FP but with dynamic typing and everything that comes with that.

Doesn't the "O" in OCaml stand for "Object", though? I think you could pick up either F# or OCaml just as easily. The nuances of OOP in F# can be ignored by beginners, so I really wouldn’t let yourself be intimidated coming from Clojure. [0] https://ocaml.org/docs/objects

OCaml classes and objects are (ironically) rarely used and generally discouraged. There are some cases where they’re practically required, such as GUI and FFI (js_of_ocaml). But otherwise, most code does encapsulation and abstraction using modules and functor modules (which are more like Haskell and Rust typeclasses than traditional OOP classes).

I don’t know much about F#, but last time I used it most of its standard library was in C# and .NET, so F# code would interact with objects and classes a lot. AFAIK F# also doesn’t have functor modules, so even without the dependence on C# code, you still can’t avoid classes and objects like you can with OCaml (e.g. you can’t write a generic collection module like `List` or `Set` without functors, it would have to be a collection of a specific type or a class).

Re: I learned Haskell in just 15 years

#38

Post by wruza »

initplus wrote: post #3
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…

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, which are useful but I can live without. Sometimes not having these makes you write effing code instead of fiddling with its forms for hours.

Still waiting for the returns from arcane fp-like code I produced earlier. Cannot recognize nor understand none of my projects in this style that I bothered to save in vcs. Imperative code reads like prose, I have some of it still in production since 2010.

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.

Re: I learned Haskell in just 15 years

#39

Post by cornel_io »

anon291 wrote: post #13
richrichie wrote: post #9

Earlier quoted context omitted.

But why do we need Haskell for this?

Realistically we don't but it's very rare to meet a programmer who understands these distinctions thats not also a great functional programmer. This is my experience after spending five years as a Haskell programmer and managing a Haskell team for several years and now moving back to the c++ world to play with AI. I know lots of good c++ programmers working on cutting edge stuff, real experts in their field, but they…

I've actually had to fire a technically exceptional Haskell programmer because of the damage they did to our C# codebase (and arguably moreso, the team). Sometimes it's not a matter of talent or skill, but culture fit.

In my experience FP-aligned people on non-FP projects tend to be more likely to overengineer, more prone to argue in favor of the Great Rewrite For No Reason Except Aesthetics, and more likely to abuse "lesser" programmers when they put up PRs. They suck as team players on teams that are not made of language nerds. I am not just talking about the one person here who I fired, this is a legit pattern I've noticed over at least a half dozen people.

Conversely, they are exactly the right people to deploy when you have really tough, self-contained problems to solve that you wouldn't trust the normal Java 9-5ers to tackle.

No matter how they do it, you can always rewrite their working code in a more maintainable language later once it's working, and make it integrate well with the rest of your stack. :D

Re: I learned Haskell in just 15 years

#40

Post by elbear »

Dylan16807 wrote: post #33
elbear wrote: post #26

Earlier quoted context omitted.

What's the benefit? You start to see functions as self-contained things, as lego blocks. All the logic of the function is there in the function. It only works on values it receives as inputs (it can't read global variables). It only outputs its results (it doesn't assign them to some other global variable that you have to track down). This makes your code modular. You can add a function in a chain of functions, if yo…

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.

Post reply on HN