Live data from Hacker News

I learned Haskell in just 15 years

duckrabbit.tech

141–150 of 240 posts

Re: I learned Haskell in just 15 years

#141
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 would recommend neither of those. Haskell has very bad syntax (with extensive backing from Microsoft, iirc the guy who writes the compiler is a Microsoft's Research employee). F# is a straight-up Microsoft's language. It doesn't matter what other benefits it has. Just don't touch anything created by that company, and you will have one fewer regrets in your life. But, if you still want a language from that category:…

> Just don't touch anything created by that company, and you will have one fewer regrets in your life.

:-)

Re: I learned Haskell in just 15 years

#142
post #117
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,…

Ocaml definitely doesn’t make you more productive

I have not used OCaml, but presumably Jane Street thinks OCaml makes their coders more productive.

Re: I learned Haskell in just 15 years

#143
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…

In modern Fortran, functions should be pure (although the language does not require this), and procedures that mutate arguments are made subroutines (which do not have return values).

Re: I learned Haskell in just 15 years

#144
post #25

Earlier quoted context omitted.

> What's the benefit of learning a PURE functional programming language 1. It makes it easy to learn how to structure a program in a pure way, which is hard to do in languages that offers you a easy way out. 2. Since "everything" is pure, writing tests is easier. 3. You know for certain that if you discard the result of a function call, all the side-effects that it would normally trigger would be stopped as well. 4.…

The problem with Haskell is that it's slow and memory-heavy (and OCaml is the same, but worse). F# and Scala (and Clojure?) are pretty much the only reasonably usable FP languages.

Where are you getting your info from?

Typical OCaml programs, when compared to similar C++ would be slower but use less memory.

F# and Scala are both OCaml in disuse. I don't know what you mean by "reasonable"... but, if the idea is "easy to reason about", then these two don't particularly stand out much.

Languages that are easy to reason about would be generally in the category where you need to do fewer translations before you get to the way the program is executed (i.e. bytecode adds an extra step, thus making a language harder to reason about). Also, languages with fewer primitives are easier to reason about, because the program text becomes more predictable.

In general, "functional" languages are harder to reason about when compared to imperative, because computers inherently don't work in the way the programs are modeled in "functional" languages, so there will be some necessary translation layer that transforms an FP program into a real computer program. There are people who believe that FP programs are easier to reason about due to the lack of side effects. In my experience, the lack of side effects doesn't come close to compensating the advantages of being able to map the program to what computer actually does.

All kinds of behind-the-scenes mechanisms in the language, s.a. garbage collector, make the reasoning harder too, in a sense. We pretend that GC makes reasoning easier by making a mental shortcut: we pretend that it doesn't matter when memory is freed. But, if you really want a full picture, GC adds a whole new layer of complexity when it comes to understanding a program.

Yet another aspect of reasoning is the ability of reasoner to act on their reasoning. I.e. the reasoning might be imperfect, but still allow to act (which is kind of the human condition, the way we are prepared to deal with the world). So, often, while imperative programs cannot be formally easily reasoned about, it's easy to informally reason about them to be efficient enough to act on that reasoning. "Functional" programs are usually the reverse: they are easier to reason about formally, but they are very unnatural to the way humans reason about everyday stuff, so, acting on them is harder for humans.

"Functional" languages tend to be more in the bytecode + GC + multiple translations camp. And, if forced to choose with these constrains, I'd say Erlang would be the easiest and the best designed language of all the "popular" ones. SML would be my pick if you need to get into the world of Haskell, but deciphering Haskell syntax brings you to the boil.

Re: I learned Haskell in just 15 years

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

[deleted]

Re: I learned Haskell in just 15 years

#146
post #131

Earlier quoted context omitted.

> I still don't understand Haskell It's not you. Haskell has very bad syntax. It's not hard to understand it, it you rewrite the same things in something saner. Haskell was developed by people who enjoy one-liners and don't really need to write practical programs. Another aspect of Haskell is that it was written by people who were so misguided as to think that mathematical formulas are somehow superior to typical imp…

That's what (some) other people do. None of that stops you writing Haskell in whatever style you want, with meaningful variable names, curly braces and semicolons!

Unfortunately, writing isn't even half the battle. Before you start writing, you need to read a lot. And Haskell code is, in general, atrocious. It always feels like there was a normal way to do something, but the author decided to chose the most convoluted way they can imagine to accomplish the same thing for the sake of a bizarre fashion sense.

Re: I learned Haskell in just 15 years

#147
post #14

Earlier quoted context omitted.

This is all myth. People don't write Haskell, because they read why other non-Haskellers also don't write Haskell, based on what other non-Haskellers wrote. > a language which has adapted the best bits and pieces from the functional programming paradigm? Why write in a statically-typed language when dynamically-typed languages have adapted the best bits and pieces from statically-typed languages?

> Why write in a statically-typed language when dynamically-typed languages have adapted the best bits and pieces from statically-typed languages? Unfortunately, dynamically-typed languages haven't adapted the best bit from statically-typed languages: that all types are enforced at compile-time!

Yep, that's the parallel I was going for.

Functional languages give you the same output for the same input, and almost-functional languages ... probably give you the same output for the same input?

Re: I learned Haskell in just 15 years

#148

Earlier quoted context omitted.

The problem with Haskell is that it's slow and memory-heavy (and OCaml is the same, but worse). F# and Scala (and Clojure?) are pretty much the only reasonably usable FP languages.

Where are you getting your info from? Typical OCaml programs, when compared to similar C++ would be slower but use less memory. F# and Scala are both OCaml in disuse. I don't know what you mean by "reasonable"... but, if the idea is "easy to reason about", then these two don't particularly stand out much. Languages that are easy to reason about would be generally in the category where you need to do fewer translation…

Heh, no.

You are suggesting to replace FP languages with powerful type systems that perform marginally slower than C# and Java (and can access their ecosystems) with a language that is dynamically typed and performs, in most situations, marginally slower than PHP and marginally faster than Ruby.

Re: I learned Haskell in just 15 years

#149
post #13

Earlier quoted context omitted.

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…

Your story matches my experience, but it always makes me think, why did this person want to work with you in the first place?

A great Haskell programmer (generally speaking) is going to be a culture misfit in any Java, C#, golang, etc shop. I know because I've been that miserable bastard who loves functional programming working with Java devs who don't know anything about FP and couldn't care less. To be clear I'm not saying you can't find a compatible Java shop (I actually did find a startup with a lot of Java devs who appreciated FP and used much of it in Java, and that was pretty great honestly), just that the odds are highly against you.

My biggest advice to people who like FP is: Find a job in a language like Clojure, Elixir, Scala, etc. There are a lot more jobs than you'd think. But if you can't, Ruby and Javascript/Typescript can be pretty close depending on where you go. Talk to existing devs and see how feel about FP in general before you join though!

Re: I learned Haskell in just 15 years

#150
post #125

Earlier quoted context omitted.

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

An execution pipeline in a functional language is just half a relation in Prolog. Prolog allows you to also run it 'backwards', you can provide the output and have it figure out what the inputs would need to be.

Run in backwards, so they say, but not really. Most things you'll write can't run backwards. You have to write them in a special way for that to be possible, and even then what it means is that you can do a depth first search to find the value.

There are some useful extensions like clpfd and asp but really if what you're doing is solving a constraint programming problem, you're much better of with OR-tools or MiniZinc.

Prolog is beautiful. I have practically no use for it. I've struggled to find something I can do better with Prolog than other tools, but I just love it aesthetically and that's enough for me sometimes.

Post reply on HN