Learning Haskell is no harder than learning any other programming language

https://williamyaoh.com/posts/2019-10-05-you-are-already-smart-enough.html

by nuriaion • 7 years ago

292 432 7 years ago

jimbob45• 7 years ago

No one has ever been able to explain to me why I should use Haskell instead of something else. I get answers about idempotence and list comprehension and strong typing which are great tactics but I never get the sense that they fit into an overarching strategy for how my life will be made easier by using Haskell.

I know Carmack has presented a case to code in a pure functional style here https://www.gamasutra.com/view/news/169296/Indepth_Functiona... but that somewhat precludes the necessity of switching to another language from C++. Further, he advocates for a new keyword 'pure' to assist the compiler like const does, perhaps not knowing that const doesn't actually help the compiler out in practice.

rumanator2• 7 years ago

but I never get the sense that they fit into an overarching strategy for how my life will be made easier by using Haskell.

I would add that the elitist signaling that is rampant in functional programming in general and the Haskell community in particular is also not helpful.

raverbashing3• 7 years ago

I guess that's the main problem.

And look, defining a problem functionally works great on 10% of the cases, but it complicates some 40% of other cases (very imprecise numbers).

The world is not functional, as it turns out. And a lot of those cases where you can write functionally don't gain much from a performance or correctness perspective compared to the procedural version

jstimpfle8• 7 years ago

Absolutely. "I'm just not smart enough to use mainstream languages" - "In fact we both know you are very smart. But, as we've just learned, also not competent enough to hide your elitist signaling in subtlety".

z3phyr7• 7 years ago

Yeah, the elitist attitude around the language is a shame. Haskell is actually pretty easy to learn and teach, and is very useful in certain domains.

Functional programming is just one of the paradigms, and useful in it's own domain. Its not a end all solution to everything.

atemerev3• 7 years ago

This is what has killed Scala. It was a fine pragmatic hybrid language which perfectly combined FP and OOP. Now it is attacked by hordes of type astronauts which will look down to you if you are not using Tagless Final, Cats, or whatever new fad is now in vogue.

ShinTakuya• 7 years ago

As a counterpoint when wanting to promote any of the "new wave" (even though Haskell isn't new) languages like Haskell, Go, or Rust for certain use cases it's become too common lately for people to dismiss it as evangelism (or indeed, elitism), and that is also unfortunate in my opinion.

xfer• 7 years ago

Really? Might i ask which places are you visiting, where you see this behaviour? I have rarely seen elitist behaviour in r/haskell or freenode #haskell. Mostly i see people complaining about eliticism on HN.

08-152• 7 years ago

GP complains that nobody can explain to him why he should switch to Haskell, but when somebody tries, that's "elitist signaling"?!

You know what, use whatever makes you happy, while we continue to avoid success at all cost.

openfuture• 7 years ago

It's just a solid mature programming language.

mkl2• 7 years ago

There are plenty of those, though, and most others seem to make both getting started and doing practical things a lot easier.

z3phyr7• 7 years ago

Short answer: Because of the features you mentioned, You will be able to write code which is correct, self documenting, and achievable in fewer lines of code[.].

Your life won't be easier if you solve problems, because solving problems is hard. But you get a lot of benefits from using any language which has features similar to Haskell because of the above reasons. If you are into programming language research, compilers, theorem provers etc, Haskell comes with a lot of idioms, features and tools that it is a viable language for the tasks at hand.

[.] a lot of languages rightly claim it like lisps and modern lisp derivatives, but Haskell brings with it a top of the line type system, (imo) a clearer syntax and tooling than OCaml, and a decent support from the industry and the academia..

empath75• 7 years ago

It’s self documenting if you consider a type signature to be documentation.

capableweb• 7 years ago

Now I don't know Haskell particularly well but I have found another language I'm focusing on, that people basically have the same question about.

For me, the quest is to be able to build more with less effort, with less bugs and make things more maintainable for the future. For this, I've found Clojure (of the 10+ languages I've professionally worked in) to be the best one, but like all the rest of the languages, it doesn't fit every single use case. But most of them, so far at least.

I could go on and on giving you arguments for/against, but I think these goals are the same for most programmers who aim to learn/use some of the lesser known languages.

malux852• 7 years ago

"Idempotence, list comprehension and strong typing", efficient communication is done succinctly through terminology.

Idempotence eliminates the need for a whole bunch of retry and error checking code, which themselves are often highly stateful and susceptible to race conditions and bugs.

List comprehensions can make allow for certain guarantees about parallelizing which is becoming ever more relevant as processors scale with threads / cores rather than clock speed. All without explicit programmer intervention.

Strong typing means the compiler can check types at compile time rather than runtime - this (largly) eliminates entire classes of errors before they happen. If errors happen at compile time, the programmer fixes it, if errors happen at runtime the user gets annoyed.

These are just trivial examples of some of the benefits of these technologies - see how these strategies eliminate not single errors but entire classes of errors. Selecting the right technologies means less bugs, less headaches for users, less support calls, less firefighting, and THAT is how your life will be easier with Haskell, for example

jstimpfle8• 7 years ago

Idempotence means spending days thinking about how to rewrite large parts of your application to get in "stateful" actions (for example, logging?) or how to make your list processing actually fast (hint, it doesn't work with lists). Idempotence makes it extremely hard to control when something actually happens or how much memory is used.

Strong typing means you'll spend your time waiting for the compiler to finish, or thinking how to unwrap this monad stack in a way that doesn't suck. It also means large parts of your app will have very unstable interfaces with way too many dependencies, you'll constantly be fighting with cabal or whatever, you'll often have to do busy work to keep track with external dependencies, you'll constantly be tempted to represent a different or additional subset of your invariants in the type system using the newest fancy language extension (that slows your compiles down even further, and may have subtle interactions with some of the other extensions you're already using).

hardwaresofton• 7 years ago

If you're having trouble justifying the switch to Haskell and are primarily concerned with systems programming, I'd recommend try out a language like Rust. Many of the features present in Rust were inspired by Haskell, and there is quite a bit of overlap between the communities.

As far as Haskell itself goes I've written a little in the past in comments on here about why it's useful:

https://news.ycombinator.com/item?id=20111321

https://news.ycombinator.com/item?id=20260095

These days when I want to start a new project the decision on whether to use Haskell or Rust is the biggest consideration I make -- the expressiveness and safety and correctness Haskell can provide versus the raw speed, ease of build, memory safety rust provides.

e12e• 7 years ago

I get answers about idempotence and list comprehension and strong typing which are great tactics but I never get the sense that they fit into an overarching strategy for how my life will be made easier by using Haskell.

First, I suppose those three things fit together in the sense that they make list comprehensions safe and fast.

But as you say, Haskell isn't the only language that gives you that.

I think the killer feature of haskell is that the community went through ridiculous contortions and pain to get rid of side effects.

Which means that Haskell programs exclude certain kinds of bugs - so it's not just that you can program in a functional style, but that you can be fairly certain there's no "shifting sands" under your functions.

On the other hand, I see many haskell programmers say that the powerful type checker forces them to think a bit differently, and perhaps harder, when writing - with the result that once the type signature fits, the function tends to "just work".

Anyway, I never did really enjoy Haskell - not as much as StandardML anyway. Sadly there doesn't seem to be any sml with good real-world libraries, so I've not really been using that either, outside of university :/

Perhaps looking at one of the few popular haskell utilities, and see if you feel Haskell is a good fit? I'm honestly not certain myself.

https://github.com/jgm/pandoc/blob/master/src/Text/Pandoc/Re...

codebje2• 7 years ago

Haskell's type system works best for me in allowing fearless changes, even significant ones to the core of a code base. The compiler won't let me overlook something.

A comprehensive test suite would achieve the same thing, but I'm rarely confident that my test suites are truly comprehensive.

29athrowaway• 7 years ago

If someone from the 50s told you "no one has ever been able to explain to me why I should use stored-program computers instead of my cables and plugboards", what would your answer be?

Maybe your answer will be that that the stored program is an abstraction of the cables and plugboards, so you can be more productive.

Today, there are several additional layers of abstraction on top of that, functional programming is one of them.

s_Hogg• 7 years ago

From that article:

"I do believe that there is real value in pursuing functional programming, but it would be irresponsible to exhort everyone to abandon their C++ compilers and start coding in Lisp, Haskell, or, to be blunt, any other fringe language."

Even Carmack has a subliminal jab at languages on the basis of popularity from time to time lol

lucasdicioccio• 7 years ago

This comment misses the point of the article, which argues against a urban legend that Haskell is too difficult "unless you are this tall" (a Phd, an E.T., a superhuman). I also had a shot at explaining why people are already tall enough in a past short "comic strip" [0]. I think the article makes a good job re-assuring the urban legends are a myth.

Now. there are many reasons why one would want to use Haskell. For instance, to have fun, to understand better some pattern, to write expanding-brain memes, or, because they are good at solving problems with it. It is fine if your reasons do not intersect with other people's reasons. You can try finding answers whether Haskell matches your reasons in some other essays [1,2,3]. Maybe it is true for many people that their needs and desires are entirely covered with their own toolset. As a curious/optimistic person I find it incredibly pedant to say I'll never ever need to learn/use something (there's different goodness in everything).

Personally, practicing Haskell led me to appreciate the importance and trade-offs that occur when isolating/interleaving side-effects. Similarly, it gave me some vocabulary to articulate my thoughts about properties of systems. Both are super important in the large when you architect softwares and systems. There are other ways to learn that (e.g., a collection of specialized languages), but at least for me, Haskell helped me build an intuition around these topics. That said, the prevalence of negative and derailing comments in discusions about Haskell can be demotivating (but our industry is like this ️).

[0] https://patrickmn.com/software/the-haskell-pyramid/ [1] https://www.snoyman.com/blog/2017/12/what-makes-haskell-uniq... [2] https://www.tweag.io/posts/2019-09-06-why-haskell-is-importa... [3] http://blog.vmchale.com/article/functional-haskell

veezbo• 7 years ago

For me, the reason is rather simple- every single program I wrote in Haskell, once successfully compiled, ran correctly.

tluyben2• 7 years ago

I think it has a lot to do with taste; you really need to like typing and abstracting everything; which I do in C# (no stringy types unless i'm in a blistering hurry) because I get paid to program C# because I actually find this very beneficial, but not limited to Haskell; Haskell taught me to do it to extremes though which, in my opinion, is what you are basically asking. That 'elitist' community in Haskell teaches a lot of abstractions, that, once practically understood, for me, give a great amount of power (which, for me again, means a far better understanding of large codebases and easy adding of features. For me that would answer the question you ask as a lot (most) of these are just very hard (not impossible which is why we see more and more of them, but not at the speed the Haskell community introduces them) to move to other languages.

Dude20293• 7 years ago

I would expect to get paid more though and that is not happening (except niche places). Same story with F# and Scala. Not worth it.

atemerev3• 7 years ago

Scala software engineers are some of the best paid out there.

Dude20293• 7 years ago

What are the examples? There is no requirement for specific domain experience?

gb• 7 years ago

I don't know whether this is true or not, but either way, working with Haskell makes my job more enjoyable than if I was writing some other language anyway.

octagonal• 7 years ago

Coincidentally: it’s also the only programming language I know of where someone has written a lengthy blog post about how I’m in fact, not too dumb to comprehend it.

giancarlostoro• 7 years ago

I didnt think about how hard Haskell is because I never forced myself to learn it. It just didnt interest me. With Java or C# I can make so many things with minimal friction. The other language that people talk about being hard is Rust. I am going to assume theres blog posts about it not being hard.

I like that with Go or Erlang everything I learned 5 or more years ago has still stuck to me. With D I can be effective quickly. With Rust I struggle a bit. Rust is probably great for building a web browser but doing backend web development feels way more work than Go or even Python (CherryPy). Haskell I dont even remember a darn thing anymore.

Tempest1981• 7 years ago

Maybe I missed it, but what's the best way to learn basic Haskell? I was expecting a tutorial. Or link to one.

tome42• 7 years ago

This is the canonical resource, I believe

https://github.com/bitemyapp/learnhaskell

colluphid• 7 years ago

http://learnyouahaskell.com/chapters

ahartmetz• 7 years ago

NO. Not that one. It explains the easy parts at (boring, pseudo-funny) length and expects you to understand the hard parts after a few sentences.

massysett• 7 years ago

http://haskellbook.com/

nvarsj• 7 years ago

I really like the concise, well explained university course Brent Yorgey put together several years ago [1]. It also works well as a book club at work.

https://www.seas.upenn.edu/~cis194/fall16/

AnthonBerg3• 7 years ago

I love this one: https://atypeofprogramming.com/

rishav_sharan• 7 years ago

Followup on this; Is there an interactive online tutorial like codeacademy for Haskell?

yakshaving_jgt25• 7 years ago

There's Exercism.

olah_1• 7 years ago

For me, Get Programming with Haskell by Will Kurt was much better than the 1300 page Haskell book. I loved it.

https://www.amazon.com/Get-Programming-Haskell-Will-Kurt/dp/...

fooker3• 7 years ago

Everyone is smart enough to write Haskell. Almost no one is smart enough to read Haskell.

There is a reason loops are easier to read and maintain compared to a fold(map(filter(zip(...)))).

graphpapa• 7 years ago

I dunno. I like that style, makes more sense to me.

IceDane• 7 years ago

Okay - so what is that reason?

tome42• 7 years ago

There is a reason loops are easier to read and maintain compared to a fold(map(filter(zip(...)))).

Absolutely not, and I read and maintain loops in both Python and Haskell!

mjn• 7 years ago

Even in Python I find the vaguely more functional style of list comprehensions easier to read than explicit loops. I've taught enough classes to know that many students who've had only a CS-101 type class do prefer explicit for loops that accumulate a result rather than list comprehensions, though. Seems like any statements about clarity (in either direction) have to include a fairly big caveat about who the audience is.

kccqzy3• 7 years ago

That's your opinion. And one that's not terribly well-informed. I find complicated loops difficult to read. Multiple things (besides the loop induction variable) are being mutated. I had to manually pattern-match whatever is in the loop back into well-known operations like fold and map and filter. And I can easily cut and paste portions of that expression into a REPL to see what it's doing.

Long before Haskell became as mainstream as it is now, C++ people have discovered the benefits of STL algorithms over raw loops.

pwm9• 7 years ago

To give you a counter example: when i write code in an imperative language i always first write the logic out as fold/map/filter and then translate that into an imperative loop.

fooker3• 7 years ago

That's not a counter example. I stated map/fold/filter is difficult to read. You said they are easier to write.

These are not opposite, and I happen to agree with you.

sullyj3• 7 years ago

well, it'd be more like

(fold op . map f . filter p . zip) l1 l2

Which I think is very understandable as long as you're familiar with what all of them do. Which you become, very quickly.

hobofan2• 7 years ago

That just reads as:

"You are already smart enough to write Haskell"... if you accept that you are too dumb for most of Haskell and are therefore okay with being cut off from most of its ecosystem.

Digging into a dependency due to a bug or custom feature is something that usually happens on any bigger project of mine. If I have to expect that I won't be able to work in a dependencies codebase because it will most likely contain (multiple) concepts that I won't be able to understand, then that's a big no-no.

chii2• 7 years ago

most people drive cars, and yet have very little understanding of how it actually works internally. As long as the interfaces are well designed, this works fine for most.

I say the same is for haskell.

hobofan2• 7 years ago

That's fine if you use your car for commuting (= casual projects with no special requirements) but not if you want to compete on the race track.

Of course you can optimally keep out of the dependencies, and a lot of people don't even think about digging into them and unnecessary limit themselves, but as I said in my initial comment, every bigger project I worked on involved tweaking dependencies in one way or another.

kungito• 7 years ago

I have only done Haskell during college and my friend is doing Haskell in web backend in production so I'd say I have a pretty good feeling about the skill gap in Haskell. There are many concepts that he tries to explain to me which I don't get 100% but it really does feel like all I need is more time. It was like that at first with monads and then phantom types, row types, hkt etc. I'd say the biggest detractor for people is that it takes more than 1 blog post and 1 hobby project to comprehend everything. It may take 1-2 years to learn all the concepts. To me the beautiful thing is that the concepts learned aren't some language quirks but instead general programming/math concepts which you simply cannot think about in simpler languages like C#. With all that, I'm still heavily put off from Haskell by all the tooling and I just can't let go of the comfort of working in Visual Studio. In 10 years I hope either C# gets some of my favorite things from Haskell like HKT and better inferrence or Haskell gets better tooling and broader ecosystem. My bet is on the former but gafter keeps postponing HKTs spec after spec.

pwm9• 7 years ago

If you feel like messing around with Haskell again for an afternoon then install VSCode with ghcide (and a syntax highlighting plugin ofc). You might get surprised ;)

li4ick• 7 years ago

The biggest lie about Haskell is that it's easy to learn. No it's not, and I do use it at work. Sure, it's not THAT difficult to get a basic understanding until you get to the usual Functor, Applicative, Monad stuff, which you can understand if you imagine them as context bubbles. Once you put something into a side-effect bubble (IO), you cannot take it out, so you're obligated to work inside of that bubble. This analogy should get you far enough. You're now ready to build toy projects.

But, even if you finish the Haskell Book(http://haskellbook.com), which is like 1300 pages, you're still going to be unable to contribute to a serious code base. Anyone who says otherwise is lying. Now, you have to understand at least 20 language extensions which you find randomly at the top of files {-# LANGUAGE ExtensionHere #-}. Now you have to understand how to really structure a program as either a stack of monad transformers, or free monads or anything else. Then you get into concurrency and to do that you have to understand how Haskell actually works, what non-strict computation does etc. etc. Otherwise you're going to get some nasty behaviour.

You think I'm done? Let's get to Lens. You can use Lens after a relatively short time of reading the docs. But to understand Lens? Very few people actually understand Lens.

Don't get me wrong, Haskell has spoiled me, and I don't really want to touch any other language (I still like Clojure, Rust, Python, Erlang). Once you get past that the language is a joy to use.

yakshaving_jgt25• 7 years ago

You don’t need to understand the internals of a thing to use the thing.

Quekid5• 7 years ago

This is exactly right. I use lenses all the time, but I have absolutely no idea how they're actually implemented, nor do I need to know.

This is abstraction. If there's one thing Haskell does well it's abstraction.

EDIT: It's really bizarre. We see these same responses to all the Haskell-or-Idris-or-whatever threads -- I wonder if there's some imposter syndrome going where "I can't immediately read/write Haskell" somehow morphs into "Haskell is useless". IME it's really rare for people who actually program in Haskell to have serious issues with the language. Yes there are issues from a smaller ecosystem, package management was bad (Stack fixed that), etc. etc. but there are very few fundamental problems with the language. Something so small as just Pattern Matching is a huge increase in productivity. Thankfully, quite a few languages have adopted pattern matching these days (Scala, Rust, TS, maybe even C++23?).

(The really big payoff comes from granular effects, but I'm sure the rest of the world will realize in about 20-30 years' time. The Erlang people already have, albeit in a different way.)

mantap• 7 years ago

Only if you have infinite memory. In theory there's no difference between folding left and folding right (if associative), in practice there is a right way and a wrong way.

tutfbhuf• 7 years ago

You don’t need to understand the internals of a thing, until you do. Everything works fine as described in documentation until it doesn't for your use case. You might be lucky and find help from stackoverflow, otherwise you need someone who really grok it.

barrkel5• 7 years ago

This has not been my experience of using technology effectively. Without an understanding of the implementation details, you inevitably use something inefficiently or for not quite the right purpose.

I cannot imagine anyone using a database effectively on any significant amount of data without understanding indexes, how different joins work, why join order is important, what effect join orders have on performance, etc. Get to a certain scale and it's not enough to know about indexes; you need to understand the structure of b-trees, disk I/O performance, how CPU cache performance affects b-tree navigation even when index is cached in memory, how to use compound indexes effectively to reduce random access through the index, etc.

The constraints of CPU and memory never go away, and if you're trying to scale something, you're going to be limited on either or both of those resources. That in turn forces you to understand execution and memory behaviour of the abstractions you're working with. All abstractions leak when pushed.

mehrdadn4• 7 years ago

There was this piece of common knowledge floating around a number of years ago about how you need to know at least 1 level of abstraction beneath you well, and have a working knowledge of the second one below it, to use your tools effectively. I don't recall where the advice floated around or came from but it was something along those lines, and it's pretty true.

kccqzy3• 7 years ago

But to understand Lens? Very few people actually understand Lens.

That's a lie. The basics of optics can be taught to even new Haskell programmers in an hour or so. Don't start in the deep end with generic optics with scary signatures like (Profunctor p, Functor f) => p a (f b) -> p s (f t). Start with something concrete like (String -> IO String) -> (User -> IO User) and then introduce the type variables one at a time. I've taught the basics of lenses, traversais, folds and other useful optics many times.

z3phyr7• 7 years ago

But that is true for many other languages of the similar caliber, like Rust and C++ are also extremely complicated!

IshKebab2• 7 years ago

In terms of mental concepts I will maybe give you Rust - lifetimes, and the borrow checker take some getting used to. But C++ doesn't really have any complicated concepts. Sure it has a lot of features, and some of them have complicated edges (ADL, template metaprogramming, etc.), but most application code rarely uses those things.

Izmaki• 7 years ago

This. Remember that to be functioning in Python, C++, and many other languages you don't need to learn most if not all concepts. That is not true for Haskell where if you know a lot but not everything, you are likely running into trouble quickly. Example from my own experience: I've read 1/5 of "The Haskell Book" and know the essentials pretty well, but throw mature Haskell code (as in "something people made for a real purpose") at me, let alone monads, and chances are I'm blown away.

mlthoughts20184• 7 years ago

You may have a point with Rust, but you don’t have a point with C++, and certainly not with other mainstream languages like Python, Scala, Java, C#, and others.

In C++, you can focus on subsets of the language that eschew whole huge paradigms (like templating or inheritance) and you’re roughly no worse off in terms of the scope of practical programs you can write with basic software patterns.

You can’t do this in Haskell. You really do have to learn all the complex hierarchy of paradigm-committing patterns and use nearly all of them nearly all the time, making it much harder to learn than C++ even though C++ is complicated.

Languanges can be complicated in different ways, and Haskell is unique in that you have to engage with every complicated aspect of it nearly all the time.

mlthoughts20184• 7 years ago

Another item is the crazy amount of compiler pragmas you have to use literally modify the meaning of syntax to get to a minimally viable state to work on a real project.

moocowtruck• 7 years ago

There is plenty to agree with here! But learning haskell isn't the biggest issue for me, I work in a large org and getting ppl to want to learn it with me or care at all is the biggest roadblock for me. The first thing they are looking for is nice IDE like and tooling experiences among many other things.

efnx2• 7 years ago

I used to want that too. Spacemacs has pretty good support out of the box if you’re willing to use stack. Vim w/ the haskell-vim-now collection is good too.

But soon after you realize that all you need is any text editor and a terminal (to run ghci(d)).

agumonkey4• 7 years ago

May I ask you about your drafting/recruitment process regarding haskell ?

coldtea• 7 years ago

Sure, it's not THAT difficult to get a basic understanding until you get to the usual Functor, Applicative, Monad stuff, which you can understand if you imagine them as context bubbles. Once you put something into a side-effect bubble (IO), you cannot take it out, so you're obligated to work inside of that bubble. This analogy should get you far enough. You're now ready to build toy projects.

The analogy with Promises, which by now everybody knows, even if pedantically flawed because they don't fit this or that criterium of Monads, is quite useful to get the idea...

falcolas2• 7 years ago

which by now everybody knows

I wouldn't make that assumption. Between people who program in languages that don't offer promises, and people who use promises but still get them wrong, there's not exactly what I'd call a strong base of understanding.

duckqlz2• 7 years ago

Come on it only took me 3 semesters of category theory and I was ready to use ‘do’

SomeOldThrow• 7 years ago

How do you even take 3 semesters of category theory?

platz7• 7 years ago

Thinking that you need to learn "Category Theory" in order write Haskell is like saying you need to read George Boole's 'Investigation of the Laws of Thought' (1854) in order to write a conditional statement.

In other words, it's not.

"Category Theory" is for mathematicians and people interested in highly abstract mathematical theory. It doesn't help you write Haskell programs.

whateveracct5• 7 years ago

I was able to use `do` with only C programming experience under my belt and a little LYAH. Cmon now.

dreamcompiler• 7 years ago

Do still bugs me because it obscures what's really going on. I'd rather work with monads directly, even though it requires more verbosity.

random314• 7 years ago

You think I'm done? Let's get to Lens.

Couldn't you also say that about C? If you think K&R C is enough of an introduction, wait until you see the Linux kernel!

pjmlp5• 7 years ago

Or those 200+ UB use cases.

willtim5• 7 years ago

You think I'm done? Let's get to Lens.

Lens is a library, not part of Haskell the language, it's also not particularly widely used. If you are going to conflate the ecosystem with the language, then we could equally talk about the complexity of dependency injection frameworks, AbstractSingletonProxyFactoryBeans, aspect-oriented bytecode weaving, and enterprise Java beans when discussing how much "easier" Java programming is.

I have programmed both Java and Haskell professionally on multiple codebases. I honestly found more ad-hoc and incidental complexity in the Java world. At least the Haskell libraries generally were consistent in the abstractions used. Java the language, also had a lot of hidden complexity, for example its memory model (required knowledge for concurrent programming).

karmakaze4• 7 years ago

Not to refute your findings but it seems unfair to call commonly selected aberrations not hidden complexity and the Java memory model as such. The only things you can compare is the complexity inherent to the task vs that which is added by the choice of implementation which is subjective based on familiarity.

marcosdumay2• 7 years ago

Yes, you should consider all of those when you talk about how hard Java is to learn. Java is a notoriously complex language and one should expect to put a lot of hours into learning it.

Haskell has a different kind of difficulty. One must expect to feel dumb for a long time, because it's composed of hard concepts. Those are much simpler concepts, but they aren't any quicker to learn.

glutamate• 7 years ago

SingletonFactory is an oxymoron.

Edit: oh wow, it actually exists

caconym_3• 7 years ago

I agree. I've never used Haskell at work (apart from some toy projects I did completely on my own as proof-of-concepts and/or quick-fixes) but I did spend a fair amount of time learning it myself, and that's what it took to get to the point where I could understand what was going on in "real" projects, let alone contribute at that level.

And, yes, Lens is where I stopped. I grokked the basic mechanism and used the library in some limited cases but a real understanding of the whole zoo of Lens-related types always eluded me. Doubtless I could have figured it out given time, but working on my own toward my own goals it was a real slog. So I started learning Rust instead. :)

Oh, and TH is an absolute nightmare. Just putting that out there. No, I don't know how I'd do it better.

tome42• 7 years ago

As someone who is very interested in the experience of people learning Haskell I'd like to ask a question. Why did you stop learning Haskell after lens eluded you, rather than just turning your attention to some other aspect of Haskell instead?

(After all, I've been interested in lens since it first came out seven or so years ago. I'd consider myself an expert in that type of technology and yet there are still parts I don't understand!)

methehack• 7 years ago

The article is called "you are already smart enough to WRITE Haskell" not "LEARN Haskell".

I think the point is that Haskell is quite powerful and useful without learning the whole of it. Basically, nobody knows the whole of it.

This is a perspective worth considering. The bones of Haskell are great and it's academic origins (god bless them) have it running around in knight's armor and a tutu (or something).

You could most likely use it effectively on a properly advised, disciplined team ("we don't use language extensions").

It might also get dressed up in other clothing and be what we're all using some day. The power and expressivity seem immense.

Imagine, for example, if the Rust documentation team got a hold of it. Holy crap!

KirinDave• 7 years ago

you're still going to be unable to contribute to a serious code base.

How is this different from Ruby with Rails, or Erlang and OTP? Or Python and Tensorsflow?

Now, you have to understand at least 20 language extensions which you find randomly at the top of files {-# LANGUAGE ExtensionHere #-}.

I absolutely agree it can be super irritating when you find a new extension that radically changes syntax. I have made jokes and complaints you can find in my comment history on this very site about it.

But I don't think this is very different from C# or C++. Folks tend to exclude and create style guides for their language. At least Haskell has the decency to label these features explicitly.

Most of the really exciting libraries of 2018-2019, fused-effects and polysemy come to top of mind but there are many others, don't use terribly exotic extensions. My favorite web framework Spock also doesn't use anything to exotic either (and in fact uses nearly identical extensions to the more popuplar Servant, nearly).

So I think that the community is moving forward with a consensus on what the valuable and expected extensions are. What we could do to improve this is make the consensus more accessible to newcomers both by talking about it (and not in the context of Alexis's great extensions post last year [0] or Chris Martin's suggestsions and awareness-raising efforts (e.g., [1]). Hopefully the community can agree to raft a bunch of uncontroversial extensions together and say, "This is GHC 2020, we just agree this is the default language spec unless you tell ghc otherwise."

You think I'm done? Let's get to Lens. You can use Lens after a relatively short time of reading the docs. But to understand Lens? Very few people actually understand Lens.

Is this any different from ANY data structure library an the majority of its consumers though? I still run into senior software engineers with amazing history who still don't understand things like, "What is the asymptotic runtime of a modern sorting algorithm" or "what alternatives to cardinality estimation could we use here than the default library bloom filter?" or more frustratingly to me, "Why this HAMT is not in fact constant time access even in practice for your specific use case, yes they're rad all praies Bagwell but it's the wrong structure for this case."

We could write a whole thing about sane uses of lens and ways to resist its excesses. Maybe now that I have finally quit twitter, I will do that this year.

[0] https://lexi-lambda.github.io/blog/2018/02/10/an-opinionated...

[1] https://twitter.com/chris__martin/status/1102457521380442112

whateveracct5• 7 years ago

I've only ever read half of LYAH and a few chapters of a couple other books. I don't know how Lens works under the hood. I've been writing Haskell for pay for several years with no problem. The rest of the stuff I should learned on the fly by reading Haddocks, misc articles, and plugging away with ghci & sketching ideas by hand (e.g. writing my own state monad for learning)

segmondy• 7 years ago

You can say this about most languages. C++, Forth, Prolog, Rust, lisp, etc.

Most languages are easy to learn, and that's what the article is talking about. Mastery is a whole other topic.

paultopia• 7 years ago

Yes yes yes on the serious code base. Or even a non-serious code base: the problem is that everyone else's code uses these fancy features. So, for example, you read the docs to some open source library, and all the examples use these 20 language extensions. So congratulations, you can't tell what the code does without learning them.

pyrale• 7 years ago

Anyone who says otherwise is lying.

Anyone who has experienced things you didn't should be discredited, because obviously your personal take is the definitive take about it.

vogre• 7 years ago

...but have no reason to.

kccqzy3• 7 years ago

There is some utility in carving out a subset of a language to make the remaining part easy to comprehend and easy to contribute to. C++ is a large and complicated language but every team seems to be using a different subset of it. The same thing would happen with Haskell. Every one might have a different idea of where to draw the line for restricting advanced features. The author might decide that Haskell 98 plus OverloadedStrings is good enough. That's a valid stylistic choice. I would have drawn the line further; I personally think features to simulate dependent types aren't worth it (think singletons or DataKinds or TypeInType) but lens is absolutely necessary even though it is difficult for beginners to understand. But ask a colleague of mine, and you might receive a response that we should embrace complicated type-level programming like the kind seen in Servant, but instead restrict TemplateHaskell. All these are valid stylistic choices but they fragment the community. And eventually debugging other people's code bases (say dependencies) you would sooner or later have to face features you don't use.

Let us not forget the roots of Haskell as a research language where ideas in functional programming are to be tried out. When it emerged in the 1980s it was literally because a committee wanted a solid foundation to replace a disparate mélange of functional programming languages. It succeeded in that, and immediately introduced new features then considered highly novel (e.g. type classes). In this sense, Haskell will never be as practical and pragmatic as Go, where moderately modern language features aren't even in the language. Choosing a language like Go could be a valid choice, and so is choosing a language like Haskell.

verttii8• 7 years ago

The real question is is it worth the time & effort.

amelius• 7 years ago

The funny thing is that software engineering tools exist to relieve programmers of mental overload. This in turn can be used to build more complicated systems, at the cost of another level of mental overload.

So this begs the question: where are the complicated systems written in Haskell that could not have been realized in other languages? Or are Haskell programmers only using the language to sleep better at night?

tome42• 7 years ago

Or are Haskell programmers only using the language to sleep better at night?

For me, the balance point lies definitely closer to the latter. I'm not writing hugely more complicated programs in Haskell than I did in Python but I feel much better knowing they're not likely to fall into pieces next time I touch them.

verttii8• 7 years ago

I guess it ultimately boils down to productivity. I mean that's what high level programming languages are built for to begin with right?

bob10292• 7 years ago

From my perspective, it isn't cut-and-dry. The quick response I give is:

If you are developing a business application and no one dies if something goes wrong for a few hours, the answer is "hell no". Productivity takes a hit for no strong upside to the biz.

If you are developing a safety-critical system, the answer is "maybe". This one is more obvious.

The more complex reasoning is that ultimately, almost every software system has to interface with the outside world in some way. Putting your functional programming layer as your principal interface between your internal and external domains is an extremely high-cost endeavor due to the complexity of handling things you can't predict. If your system is safety-critical, and you have extensive control over the external domain (e.g. dedicated, redundant sensor networks), you might be able to justify this added complexity because you can control many more variables than you would be able to otherwise.

An alternative approach that seems ideal to me at this time is to use imperative techniques as the principal architecture, and then use functional within that domain in the specific cases where it can be justified. Good examples of this would be C#/LINQ, or even invocation of F# from C# (e.g. rules engine). Imperative is extremely good at handling side-effects and managing exceptions. Functional is deterministic if you can keep it on rails. Using both where most suitable w/ interop between seems to be the most productive approach.

A quick corollary could be: "If you are exclusively using functional techniques to build your application, you are probably making a mistake".

platz7• 7 years ago

as your principal interface between your internal and external domains is an extremely high-cost endeavor due to the complexity of handling things you can't predict.

I fail to see why if you believe this is true of haskell, it would not also be true of C#

verttii8• 7 years ago

I'm writing most of my apps in Elixir which is also functional. I got no problems wiring side effects with it despite it being less imperative than some C#/Java/friends. In fact, I'd write high availability apps on Elixir any day over C# or other OOP/imperative lang. I don't ever want to touch any safety-critical systems though, but I do care about correctness of the business logic. Somehow I have zero interest in Microsoft langs/runtimes in general.

That said, Haskell just feels like a different beast. I also don't know how interop would actually work with these different solutions, would feel like unnecessary complexity if anything. Only to end up losing the benefits of Haskell's strong typing.

I've been struggling to justify spending more time & effort on concepts mostly exclusive to Haskell, only to be able to be productive on it. I keep thinking I should brush up my Elixir skills instead.

eklavya• 7 years ago

I write Scala and Java for a living and it absolutely is :)

sitzkrieg• 7 years ago

haskell is easy to learn if you want to ignore a bunch of floofy high level math concepts and just paste how to parse a json library.

lets be real, software engineering that brings results is i/o. i see the appeal in pure functions and guarding that out but the shit that matters is going to be the nasty mess of stuff that saves business logic that was hacked together over 10 years of rnd, interns and crunches

UK-Al052• 7 years ago

Algebaric data types and monadic types are perfect for business logic.

Read the book domain modelling made functional.

carapace• 7 years ago

This too, eh? "Domain Modeling Made Functional" - Scott Wlaschin

https://www.youtube.com/watch?v=Up7LcbGZFuo

ducaale2• 7 years ago

Blog post that explains Functors, Applicatives, And Monads in pictures http://adit.io/posts/2013-04-17-functors,_applicatives,_and_...

pwm9• 7 years ago

Honestly, this blog post is cute but it does not actually give you understanding and insight into these concepts. Imho the only way to internalise these are through practice. Write code, get annoyed by repetition/boilerplate/etc... and discover that abstraction Foo solves that problem.

modernerd2• 7 years ago

This blog post may help some but readers shouldn't expect it to magically flick a switch that allows them to use or create monads.

Instead, I really like:

1. Stephen Diehl's “Eightfold Path to Monad Satori” from “What I Wish I Knew When Learning Haskell”:

http://dev.stephendiehl.com/hask/#monads

“Much ink has been spilled waxing lyrical about the supposed mystique of monads. Instead, I suggest a path to enlightenment:

1. Don't read the monad tutorials. 2. No really, don't read the monad tutorials. 3. Learn about Haskell types. 4. Learn what a typeclass is. 5. Read the Typeclassopedia. 6. Read the monad definitions. 7. Use monads in real code. 8. Don't write monad-analogy tutorials.

In other words, the only path to understanding monads is to read the fine source, fire up GHC, and write some code. Analogies and metaphors will not lead to understanding.”

2. Chris/kqr's “The ‘What Are Monads?’ Fallacy?”, which mirrors the advice from Stephen Diehl:

https://two-wrongs.com/the-what-are-monads-fallacy

“Instead, learn to use specific monads. Learn how Maybe a works, learn how Either e a works. Learn how IO a and [a] and r -> a works. Those are all monads. Learn to use them with the >>= operator and with do notation.

Once you've learned how to work with all of those, you'll have a really good idea of how monads can be used.

Asking "What is a monad?" to learn how to use monads is as wrong as asking "What is a musical instrument?" to learn how to play musical instruments. It's a good start, but it won't teach you very much.”

tome42• 7 years ago

Asking "What is a monad?" to learn how to use monads is as wrong as asking "What is a musical instrument?" to learn how to play musical instruments. It's a good start, but it won't teach you very much.”

This is such a great analogy!

JCoder58• 7 years ago

Eric Lippert's blog series on Monads[1] follows this approach and is very effective in teaching the concepts behind Monads. He starts out with standard concepts from C# that are Monads and shows how they're implemented and what they have in common. It is very approachable for an object-oriented programmer who's curious about functional programming.

1: https://ericlippert.com/2013/02/21/monads-part-one/

roenxi• 7 years ago

Asking "What is a monad?" to learn how to use monads is as wrong as asking "What is a musical instrument?" to learn how to play musical instruments. It's a good start, but it won't teach you very much.”

Another good analogy might be learning circular breathing for ordinary everyday conversation.

You might hear the circular breathing is an amazing thing that allows you to do things you couldn't otherwise do. If you are trying to use that trick without ever learning to play an instrument then there will be a great air of mystery to it all.

Monads solve problems that are only made apparent by other design decisions in Haskell. In a non-functional, loosely typed context they are not so useful.

goto1114• 7 years ago

Condescending tutorials seem to be an integrated part of Haskell culture. The rationale might be that people who don't already know Haskell should to talked to like kids. "Don't be scared, a monad is just like a Burrito!" and so on.

I can't recollect I have ever learned a programming concept through metaphors. The only way I have learned concepts is though solving tasks in a language and thereby learning to use the tools available.

I actually think Haskell is a very enjoyable language, but there is a culture around it which treats the type concepts (arrows, monads etc.) like goals in themselves rather than tools to achieve something useful.

tome42• 7 years ago

Condescending tutorials seem to be an integrated part of Haskell culture.

Could you perhaps link to one? I know of plenty of misguided tutorials that try to be helpful but aren't. I've never come across one I'd call "condescending".

I can't recollect I have ever learned a programming concept through metaphors. The only way I have learned concepts is though solving tasks in a language and thereby learning to use the tools available.

Yet for some reason newcomers (reputedly) want to know what a monad is before trying to use one! I agree with you: they should go ahead and use one and not worry about what it is!

AnthonBerg3• 7 years ago

The only condescension I see in Haskell-related discussion is condescension towards Haskellers, claiming that Haskellers are condescending and say condescending things like writing condescending tutorials.

As I see it it’s actually not very nice.

With the utmost respect, truly, humbly: I am against this custom that it’s just fine to call well-meaning people for condescending. As it appears to me, claiming condescendence is more of a statement of the claimant, but this is still an unfortunate custom. Who are we really to claim condescension? Really?

The article linked to in the post starts off with quotes from people who directly state that they feel like they would need to be smarter to use Haskell. It’s a common thing. The article addresses that. It is literally the opposite of condescension.

Then there’s the burrito tutorials with pictures. I for one actually think in weird abstract sloppy metaphors and colors. My head really is full of burritos and inaccuracies. I was helped enormously by the burrito concept. Textbooks generally don’t speak in burritos. I work with people to whom the burrito class of analogies is not helpful. They think in a more direct and crystalline way. I wish I were more like them. And I try try to be. And I can. And it makes me better. And I really do think I also bring something to the table by spraying flaming burrito concepts and lateral jumps into the team zeitgeist.

scotty79• 7 years ago

The one thing that made monads clearer for me was this thing https://youtu.be/b0EF0VTs9Dc Monads and Gonads

It's probably condescending for haskellers because it shows that monads are not some enshrined primary concept but just a kind of dumb wrapper you can write in any language and you do when it's useful for you.

ducaale2• 7 years ago

Comparing monads to burritos https://chrisdone.com/posts/monads-are-burritos/

willtim5• 7 years ago

Those weekly Monad blog tutorials probably annoyed the Haskell community more than anyone. Extremely readable and well written papers had already been published by the Haskell community (e.g. Phil Wadler). Read the papers first.

crimsonalucard5• 7 years ago

I actually think Haskell is a very enjoyable language, but there is a culture around it which treats the type concepts (arrows, monads etc.) like goals in themselves rather than tools to achieve something useful.

I get it though. The concepts are so advanced that you have to internalize the concept first before it can even be used.

karmakaze4• 7 years ago

This is one of two posts that made things click for me. This one clearly distinguishes Functors, Applicatives, and Monads visually so that I don't get hung up on the names every time I encounter them.

The other article that demonstrated the practical purpose or path to constructing Monads showed a number of them using nested procedural syntax formatted to look like do-notation. [I can't remember the title/link, if anyone knows please post.] It went through async/await, maybe or list and showed them rearranged with the 'monad'ic parts off to the right where semi-colons might be.

Do-notation just took that and flattened the nested structures. The appreciation that these different computational contexts could all be structured the same way while focusing on what's happening apart from these contexts really demonstrated why it's useful and the power of being able to encapsulate these seemingly different ideas.

I'm sure I'll need to find a part-3 in my journey (perhaps Monad transformers) and so on, but I've at least got a good footing from those.

ghostwriter• 7 years ago

The best intro to monad transformers that I've seen so far is https://mmhaskell.com/monads/transformers

gassah_qwert• 7 years ago

Haskell is no doubt an interesting language. I have yet to work on a project where it was the obvious choice but I’ve played around with it enough to like it.

What I don’t like are some (not all) of the people who use Haskell and talk about it online. They can be incredibly obnoxious. Haskell is not a tool they work with, it’s their entrance to a class of software engineers that you’re not capable of being part of.

Just for the record: Anyone can learn Haskell. If you’re struggling with it that’s because of a tooling / literature issue. Haskell people (even the nice ones) are bad at explaining the language. The tooling isn’t very friendly and the language is a shit sandwich to debug.

The concepts therein are no more difficult to grasp than any other in programming. Is a Monad a box or a burrito? Please stop. It’s a language feature that allows you to do certain things more concisely than the alternative. Stop pretending it’s magic and show people how to use it and why they should. Stop drawing pictures.

No, algebraic data types are not hard to understand. You just make a big deal out of them because you think the word algebraic sounds cool.

I could keep going but I think I’ve made my point.

Dear Haskell people: Get over yourselves. Do not mistake the larger software community’s disinterest in your pet language for their inability to use it. That’s simply not the case. If people had to use it even ‘lowly js devs’ would master it.

Everyone else: If you haven’t used it already it is a very cool language and worth learning even if just for personal edification. Don’t let the self appointed high priests turn you off. Don’t expect their help either.

tome42• 7 years ago

Sorry you've experienced this obnoxious behaviour. I've been in the community for years and never seen it. Maybe I'm not hanging out in the same places as you or I have some sort of unconscious bias that means I don't notice it.

Could you link me to an example? I have some measure of authority in the community and would like to help decrease the amount of obnoxiousness but I can't unless I know where it happens.

Dear Haskell people: Get over yourselves. Do not mistake the larger software community’s disinterest in your pet language for their inability to use it. That’s simply not the case. If people had to use it even ‘lowly js devs’ would master it.

This is really interesting because the Haskell community I hang out with (mostly on Reddit) would love it if "lowly js devs" would master it. In fact we all too often get told by non-Haskellers that "Haskell will never succeed because it's too hard for most programmers to learn"!

CJefferson4• 7 years ago

Well, what about this article? It claims I just have to understand 4 basic concepts to replace java, python and Ruby.

Great, so using those simple properties let's reimplement Eclipse. Let me use tensor flow. Replace my Ruby on rail website.

AnimalMuppet6• 7 years ago

I think that the obnoxious smugness is felt by those outside the community, not by those within it. This could be because the community is nicer to those inside, or because those outside perceive smugness where those inside do not. (I make no claim as to whether that is the fault of those inside, or those outside.)

thrower1235• 7 years ago

Haskellers do tend to be very identitarian. Not unlike vegans, or CrossFitters.

alkonaut4• 7 years ago

Haskell was used in the first programming class at university and that was excellent. Some people that already know how to program had to throw their preconceptions out the window. So everyone was either a novice at programming entirely or at least a novice at functional programming. It wasn’t problem at all. I’d argue most students wrote better code in that class than they did in the imperative/OO classes that followed. Especially the students that weren’t (and likely never did become) programmers.

The thing about imperative and OO programming is that it’s hard to do well. I honestly havent seen more than 1/10 developers write ”good” OO code even after 10 or 15 years as professionals. Large scale OO is a cognitive load that requires extreme focus, skill and talent. I prefer functional (or OO using an extreme functional discipline like all immutable types etc) because I don’t have that talent, focus and skill.

My point isn’t that Haskell should be the language of choice. I think it’s a great language but I think e.g laziness makes it too hard to reason about performance and behavior. Today I’d recommend F# I think.

Mirioron2• 7 years ago

And how many people dropped out of CS because of that first Haskell course? I saw plenty of people struggling with Python initially and I know exactly how they felt later when we had to learn Haskell.

I think if I had to learn Haskell first, then I would've just given up at the start.

alkonaut4• 7 years ago

I think they deliberately did some really “rough” math and CS classes up front because they knew some would drop out and they preferred them to drop in the first few weeks so someone could take their spot.

thrower1235• 7 years ago

Yeah, my university did something similar. The very first computer science course was a bog-standard Java course - this was often an elective that engineers or science folks took also. The first CS-specific course used Haskell, and it probably turned off 75% of the people that tried taking it.

nh2• 7 years ago

Where I did my CS degree (Imperial College London) , Haskell is the first language taught (before Java and C).

To my knowledge across 4 years there, nobody ever dropped out because of the Haskell.

People usually struggled with the maths instead.

People also did not have more problems getting Haskell concepts right than linked list modification in Java.

K0nserv• 7 years ago

My university(Gothenburg University) did this for the CS course. Haskell does a very good job at levelling the playing field since it was new even to those who had prior programming experience. As I recall about 40 people out of 70 did drop out during the first semester.

randomsearch• 7 years ago

Lisp (Scheme) was chosen for the same reasons at my uni, but I think is a superior choice as the syntax is so small and it’s very appropriate for teaching.

preommr• 7 years ago

Haskell was used in the first programming class at university and that was excellent.

I don't think getting started in haskell is that hard. If you're just doing theoretical exercises like building data structures and their related operations then it might even be easier than other languages.

Building a bigger application that does things like create a mini game or act as the backend for a web service, you know the cool stuff, becomes a lot harder.

alkonaut4• 7 years ago

Yes. I think we wrote a guessing game and a miniature parser etc. The concept of "web service" wasn't invented, sadly.

nec4b2• 7 years ago

Programming in any language or paradigm is hard to do well. Since vast majority of software that we are using is written in imperative and OO paradigm it is probably safe to say that it doesn't require any special developer power as you claim.

truculent• 7 years ago

I don’t have that talent, focus and skill.

Same. I'm perfectly happy to fall into the pit of success[1].

1. https://www.youtube.com/watch?v=US8QG9I1XW0

macando• 7 years ago

I always wondered whether imperative languages feel more intuitive to most programmers because they are:

a) Inherently simpler and require no prior advanced knowledge of math.

b) They are the default in every curriculum and once your brain is wired that way everything else seems counter-intuitive.

I remember in the first grade of my elementary school we were taught basic algebra and how sets work (union, intersection etc). I understood both concepts but I couldn't relate sets to the outside world. Like why do I even need this. Maybe new programmers feel this way about functional languages and Haskell.

ThrowawayR2• 7 years ago

Try:

c) That's the way microprocessors actually work. Machine language is just imperative commands and branch instructions.

foxes• 7 years ago

Mirroring some of the comments here, just because you don't understand the internals does not mean you can't pick it up and be productive with it. This is what you do with any other language, but it just seems more natural to you (even though they are really just as complicated).

Hence I feel like one of the big issues is that people learn to program in a non declarative/imperative way. When you first pick up python / c / c++ etc, there are plenty of details you don't necessarily understand (who here has absorbed all of the c++ spec?).

At most Haskell is just different and I don't think it requires more mental effort than anything else.

kunos• 7 years ago

Honestly I think Haskellers should spend less time writing blogs and more time writing code that does something interesting/useful. When the language you claim being so superior comes with such bad tooling and usability your claim instantly looses any substance.

yakshaving_jgt25• 7 years ago

Strange. I spend the vast majority of my time writing code that does something interesting/useful. In fact, it puts food on the table and a roof over the heads of several families.

The reason why I’ve given up my own time to write some blog posts (apart from it just being an occasional pastime), is that everyone complains that Haskell doesn’t have enough documentation or tutorials.

Damned if we do; damned if we don’t.

tome42• 7 years ago

* "Haskellers write to much code but don't explain the language. They should write tutorials."

* "Haskellers just write tutorials but there's no good practical code."

* "Haskell will never catch on because it's too hard. They think it's easy but that's just because they're geniuses."

* "Haskellers are obnoxious and condescending. The language is easy but they want to pretend it makes them special and clever."

* "The Haskell type checker only checks really simple properties that are easy to prove by hand"

* "Haskell doesn't come with tooling that automate refactorings that are easy to make by hand"

The list of contradictory complaints goes on ...

verttii8• 7 years ago

We absolutely need more hands-on Haskell tutorials and blogs. I've been massively more productive with Haskell with the help of just a few well written blogs that are full of tutorial posts.

We got a lot of books detailing various type theories, algorithmic nuances and so on in Haskell, but very little resources to actually help anyone get off the ground with practical web development.

aaronmu• 7 years ago

The company I work for defaults to F# when choosing tech for a specific project.

We defaulted to PHP and C# in the past.

We have quite some experience training people who just graduated and even people with backgrounds outside of tech.

Training someone from zero to autonomously writing production code is a lot easier in F# compared to PHP and C#.

We educate people in Elm and Haskell and switch over to F# when they’re ready to try building the first real thing end to end.

thrower1235• 7 years ago

F# is really a very nice pragmatic language. C# keeps cannibalizing features from it, which is both good and bad...

bob10292• 7 years ago

As a die-hard .NET/C# developer, I would be curious what you perceive to be the 'bad' side of that coin. I assume something like LINQ would be classified as 'good'?

ngcc_hk• 7 years ago

Not la. Clojure.

mac01021• 7 years ago

Learning Chinese is no harder than learning any other language. Unless there's a language you already know that is unlike Chinese and more like other languages.

thrower1235• 7 years ago

Learning Chinese is objectively more difficult than learning alphabetic languages. Although learning Chinese really would be more like learning APL.

AnimalMuppet6• 7 years ago

That's written Chinese. Learning spoken Chinese is more difficult if you're not used to a tonal language, though.

JanisL• 7 years ago

Maybe things have changed since 2005 when I first used it but Haskell was certainly harder for me and the people I knew to learn than other languages. For languages of a similar power I can see Haskell being similar difficulty to learn. But compared with something like Python the amount of effort needed to go from zero knowledge to being able to write some sort of program that produces some useful real world results is much higher in Haskell.

I say this as someone who quite likes Haskell, when you have a problem that fits well with Haskell it's really amazing.

yakshaving_jgt25• 7 years ago

Things have changed significantly in the last four years, so they definitely will have changed a huge amount in the last 14 years.

agumonkey4• 7 years ago

I'd argue that it's not as simple. But there's a relativity factor here.

1) Haskell is much like math. You look at some concepts and ideas and fail to see what it is about, until 20 years down the road you finally click that "maaan" discrete mathematics was already encompassing 90% of computation it just wrapped it in counting instead of concrete computer instructions. Mathematicians have this culture of going too far, too concise, too fast for most of the population.

2) Mainstream culture imposes a negative toll on this because when you're fed Java or PHP (let's say you learned in the 2000s when they were peak fad) you'll interpret Haskell through them, brain already set on a belief, and it will make it twice harder. And it's really hard to disentangle the weird bliss of being able to manipulate elements through an interface (here it would be the syntax its idioms) from "objective reality". I too was enamored by PHP associative array syntax (so fun compared to C or Java lack thereof) and F5 to see a website change before my eyes. Haskell feels like a punishment compared to this. Not even counting the social aspect of it .. wordpress made people have colleagues and money.

Anyway, keep learning haskell (and FP, and logic, and math).

defanor• 7 years ago

I mostly agree with the article, but not with the HN title (which doesn't match the article's title). The article itself has a nice statement:

If you’ve already learned another language, you can learn Haskell. And even if you haven’t, learning Haskell is no harder than learning any other programming language.

But most of the programmers are familiar with imperative languages, and can quite easily switch between them (possibly writing non-idiomatic and awkward code, but without having to really learn the language from scratch to do so). While a purely functional language with unfamiliar syntax doesn't let one to do it as easily. So indeed, if you haven't learned other languages, probably it's not harder, and if you have, you still can learn it, but likely it would be harder to learn than other imperative languages if you are already familiar with a few imperative languages.

tome42• 7 years ago

I mostly agree with the article, but not with the HN title (which doesn't match the article's title).

I think the HN title used to be correct. Perhaps the mods changed it. I can't imagine why. It's a completely different claim from the article!

bryanrasmussen5• 7 years ago

If learning it is no harder than any other programming language that presumes that every other programming language is equally easy to learn. Furthermore it assumes that people have an equally easy job learning whatever language they learn.

Neither one of these conditions are remotely indicated by research on the subject, therefore the statement is false.

Also I did try learning Haskell at one point and I found it harder than some other languages, I would say I found it Erlang level hard which I tried at about the same time( about 2009) but I think Erlang has a little more inclusiveness to their community IMHO

yakshaving_jgt25• 7 years ago

Neither one of these conditions are remotely indicated by research on the subject, therefore the statement is false.

What is the standard unit of measurement for quantifying just how difficult a language is to learn? Is there a standard unit of measurement for quantifying the competence of a person learning a programming language?

bryanrasmussen5• 7 years ago

I'm pretty sure the field is too young to have developed a standard unit of measurement of either of these things, if there were such units their creation would be one of the stunning intellectual achievements of mankind in recent history and would have such obvious benefits to many other parts of human endeavor that I would expect it would be a field more investment heavy than machine learning at the moment.

However it has been shown that there are people who seem more attuned to different learning styles, styles of programming, there are differences in difficulty between first language acquisition and later (dependent on language similarity, language domain), and many other studies regarding programming language learning that it can be said not everyone learns equally well every language, and not every language is equally as learnable.

tome42• 7 years ago

If learning it is no harder than any other programming language that presumes that every other programming language is equally easy to learn.

Did you click through to the article? The HN title is (currently) "Learning Haskell is no harder than learning any other programming language". The article's actual title is "You are already smart enough to write Haskell".

You appear to be responding to what a zealous mod wrote not what anyone actually believes.

bryanrasmussen5• 7 years ago

I am responding to what the modded title is because it is wrong.

the article's actual title is wrong in other ways.

1. because someone might not be smart enough to write Haskell (is that different than program in Haskell?)

2. Because someone might be better suited to other language types than Haskell.

language types I prefer - small instruction sets, functional or declarative (that however is my preference) someone might just find object orientation a more natural way of thinking.

AnimalMuppet6• 7 years ago

Neither one of these conditions are remotely indicated by research on the subject, therefore the statement is false.

That does not follow. "Research does not prove it" means "therefore we don't know it's true", not "therefore it's false".

To your wider point: I think (but cannot prove) that some peoples' brains find FP easier to learn and some peoples' brains find procedural easier. And I think (but can prove even less) that the large majority find procedural easier.

pi-victor• 7 years ago

i've learned rust in a month of coding sparsely. in fact, i'm as comfortable today at writing rust as i am at writing go. i've been struggling to learn haskell for over half a year. i think it's an amazing language, don't get me wrong. but the fact that haskell is not harder to learn than any other programming languages is false. after taking a few online course, tutorials and so on, i still believe it's one of the most interesting (if not the most interesting) programming language in existence and also the hardest.

tome42• 7 years ago

Did you click through to the article? The HN title is (currently) "Learning Haskell is no harder than learning any other programming language". The article's actual title is "You are already smart enough to write Haskell".

You appear to be responding to what a zealous mod wrote not what anyone actually believes.

Elrac3• 7 years ago

As a Haskell n00b, I'd like to mention something I can do in about 20 other languages but not in Haskell:

( UPDATE: I stand corrected, in a reply by tome. )

I'm writing and debugging some functional code - in Clojure. There's a function I've smoke-tested on its own but that's failing me with "real" data. Lacking a decent debugger for Clojure and being too lazy to isolate my problem into a test setup, my tool of choice is the lowly "debug print."

In Clojure, the body of a function is essentially imperative, and I can insert a `(println "label:" value)`. To do the same thing in Haskell, I'd have to restructure my whole damn program.

I understand the rationale for purity in Haskell, but sometimes I see it as badly standing in my way of accomplishing what I want to do.

tome42• 7 years ago

Have you heard of Debug.Trace? It gives you exactly what you are looking for.

https://hackage.haskell.org/package/base-4.12.0.0/docs/Debug...

Elrac3• 7 years ago

Wow, cool! Thanks. I hope to do more with Haskell once I retire, and this may stand me in good stead.

I think my point is still supported to some extent by the fact that this is knowledge from outside of the language that I'd need to know to accomplish. It's something I need someone helpful like yourself to tell me about. Also something that only works because this library deliberately breaks Haskell's rules.

nickbauman2• 7 years ago

I remember Rob Pike unveiling Go at a Google talk years ago and some Googler got up and said "why would Go be better than Haskel?" and Rob said "Because I can't understand Haskel source code and I'm pretty sure you could understand Go source code right now."

arendtio• 7 years ago

I think this is still one of the strongest selling points for Go. It is a pretty solid language with a few basic concepts which are repeated constantly. Sure, it doesn't have generics, error handling is a mess and the language design isn't as consistent as it should be.

But what it does, is pushing everybody to write simple code which is easy to understand. So many times I found the documentation (of some library) to be incomplete, but jumping right into the code answered the questions I had. I can't say that about every language.

nickbauman2• 7 years ago

Totally agree. When I first encountered Go, I kinda hated it for its lugubrious combination of being rather "braindead" and opinionated about being braindead at the same time. Typing it every day gave me flashbacks of programming Java circa JDK 1.4 (before the compiler-only based generics were introduced in 1.5, which I still believe didn't solve enough problems for the complexity it added). In short, it felt like a step backward.

But after seeing its gc performance sitting at the single-digit ms timeframes with huge heaps (60 gigabytes!) I realized I needed to hold my nose.

What helped me make peace with it is its automated testing story. It's baked into the language in a way I've rarely seen in any other runtime.

vojta_letal2• 7 years ago

I am a skilled Scala developer with knowledge of FP sufficient enough to make two contributions to the Typelevel cats/kittens ecosystem. Yet I was not even able to start a hobby project in Haskell. I always start and fall back to Python shortly after. Is it just me?

agumonkey4• 7 years ago

That's actually interesting. Was it the base prelude typeclasses that are too different ? AFAIK scala uses monadic code too .. I expected not too much difficulties using haskell. Maybe that's the syntax ?

vojta_letal2• 7 years ago

Scala has an awesome IDE support, familiar rich JVM ecosystem, familiar syntax, ability to ignore the fact that logging is a side effect...

I had a hard time understanding the Haskell ecosystem, plus the syntax is just way too different and restrictive.

For example the last tutorial I tried to follow recommend using nix package manager to install Haskell. I failled missereably, it just did not work out of the box.

yomly2• 7 years ago

Imagine you spent a career learning the piano. Would you expect to pick up the violin as if you were an expert?

Would it be reasonable to declare violin sucks! I've played piano for 30 years, vibrato is so hard it must be wrong, tell me why I should learn the violin?

Actually probably a lot will come with you, your dexterity and music theory will be quite useful, as will your ear.

But really, the instruments are very different and if you want to level up your sense of pitch or really learn how to sing a melody, the violin can be great for that...

cuddlecake• 7 years ago

Are you replying to the wrong link? The link is about programming fyi

yomly2• 7 years ago

I'm trying to draw analogy to maybe something less inflammatory.

Most of us here are programmers, a lot of us professionals.

Music is the output of musicians, as perhaps code is the output of programmers.

But music comes in all kinds of flavours: classical vs jazz vs pop

Performance vs composition

Recital vs improvisation

And then choice of instrument within any of those areas.

I feel a lot of people misplace their aversion to Haskell because they fail to recognize how different Haskell is.

It's a bit like when English speakers think Chinese is a "hard" language. It's not, linguistically it's actually a pretty simple language (whether the script is easy/hard is up for grabs...)

Actually Chinese is just different to English so you have few anchors and familiar friends to base things off so it feels hard cos you're starting afresh, like a child. And yet children of a china manage quite fine learning chinese....

Meanwhile, ask a Spanish speaker about their experiences learning Portuguese...

ummonk6• 7 years ago

Violin is definitely much harder to pick up than piano though, regardless of experience with other instruments. Obviously mastery is hard for both, but getting a basic pleasant melody out of a piano is far easier than doing the same with a violin.

Haskell is rather similar to a violin in that respect.

koala_man• 7 years ago

Would you expect to pick up the violin as if you were an expert?

Rightly or wrongly, in programming we do expect this. We keep saying things like how languages are only tools, and how terms like "Java programmer" is as absurd as "Casio mathematician".

If you have effortlessly switched between imperative OO languages many times before, it's easy to think that any language you can't quickly learn must be because it's fundamentally and abnormally difficult.

blurbleblurble• 7 years ago

It's not the language that's frustrating to learn, it's the tooling.

Mugwort• 7 years ago

Haskell basics are easy to learn. Nobody learns Haskell to linger on the basics. Haskell is a useful tool for express a deep ideas which aren't basic and require time, effort, focus and guidance to learn properly. You can still do quite a bit with the basics. I solved many Euler problems using Haskell and prefer it over Python.

nec4b2• 7 years ago

There are languages that attract people who want to get things done (mostly multi paradigm languages these days) and there are languages that attract people who want to feel special (languages oriented on one true way or obsessed with a particular purity).

ben509• 7 years ago

I'm not sure the idea of a "beginner" language should be a design goal, and I don't think Haskell being a hard langauge to learn means it's a bad langauge.

Easy as a design goal has led to many languages like AppleScript that try to ape natural language, or to visual languages, and those consistently seem to be bad choices.

Haskell is probably not as hard as many people who haven't made the jump think it is. But it is hard.

What do you need to write real Haskell? The core of the language is extremely simple. If you understand how to write and use [four items broken out below] then you already have everything you need to write useful programs that solve real-world problems.

The core is admirably simple, but simple doesn't mean easy. Easy to learn is when you have intuition and existing skill that readily map to the core constructs used in a language.

pattern matching

There are cases where pattern matching is obvious, but this is not how most people have learned to structure a problem.

People aren't naturally good at breaking problems into parts, that's a skill you have to develop over two or three years, which is my guess from observing myself and peers.

sum and product types

Explicit types are already hard; you're already excluding many people who have trouble making the leap from Javascript to Java.

But Haskell's type system is heavily generic. And its support for container types is not so great. Making them easy was a major reason Perl, Python and Ruby grew quickly, and landed us a ton of horrible code.

To understand how Haskell makes these container types hard, compare the API for Data.Map to the API for java.util.Map[2]. You can ignore Java's rather pathetic facilities for FP entirely because you don't need them.

The Haskell version has functions to do lookup, union, intersection and various predicates. In Java, they're trivial to implement with a loop.

pure functions and values

The intuitive way to change a thing is... well, to change a thing. I can express it directly in plain language. To express the pure way, I have to describe it as "construct a new value such that all properties are the same except for the changed properties."

I've seen a meme that shows Common Core multiplication in a pedagogical context, and contrasts it with the traditional long-form multiplication. It completely misses what CC is trying to do, but it's useful in showing what people are comfortable with: they grok procedures much better than abstractions.

Functions are the part of math where most people who were okay with algebra nevertheless started tuning out. First-class functions are weirder still. Haskell also mandates currying, and being strongly typed every function gets a confusing type signature.

All that said, keeping track of state changed by mutation is deceptively hard. It's a case where your intuition routinely leads you to build things you can't maintain. But sticking strictly to the claim in the OP, it's easy to learn to mutate state but hard to do.

how to glue together IO to make side effects

This shows that monads are core to the language, and they have all the difficulties of generic types as well.

Everyone has jumped on how hard monads are already so I won't belabor the point, just to say that except for concurrency / parallelism, I don't think there are any core language features as hard to understand as monads.

(And I'm not sure exactly what the "core language" is, but I think anything in the Prelude is fair game.)

Haskell does make them dramatically easier with "do" notation, but I think you really do need to grok monads for your learning to progress beyond simple examples.

[1] https://hackage.haskell.org/package/containers-0.6.2.1/docs/... [2]: https://docs.oracle.com/en/java/javase/12/docs/api/java.base...

tome42• 7 years ago

To understand how Haskell makes these container types hard, compare the API for Data.Map to the API for java.util.Map[2]. You can ignore Java's rather pathetic facilities for FP entirely because you don't need them.
The Haskell version has functions to do lookup, union, intersection and various predicates. In Java, they're trivial to implement with a loop.

I don't get it. I don't see how you do lookup with a loop at all. As for union and intersection, are you sure you write them in Java with a loop? The way that's obvious to me would be quadratic. Is there a better way?

AnimalMuppet6• 7 years ago

All that said, keeping track of state changed by mutation is deceptively hard. It's a case where your intuition routinely leads you to build things you can't maintain. But sticking strictly to the claim in the OP, it's easy to learn to mutate state but hard to do.

Hard to do... safely. Easy to do wrong, though. But wrong might still work most of the time. [Edit: "Works most of the time" is not praise, nor endorsement of the approach.]

To me, this is the fundamental thing that the FP people have right. Constrain your state space or die.

spicyramen• 7 years ago

I took a Haskell class couple of years back (Functional Programming) as reference I worked for 12 years before as Software Engineer using Pascal, C, C++, Java, Perl, Shell, Python, Visual Basic, and I felt like I was learning Chinese, I really put extra effort, but Monads, Applicatives, etc were complicated and way above my head. I really never found a reason to continue that punishment, I admire the teacher and the community who work on it, maybe not for me. But not easy

rmtech• 7 years ago

Can anyone recommend an intro to Haskell for me? ~4 years of Python experience and a math background. Ideally something online/interactive ...

tome42• 7 years ago

The canonical source for Haskell introductions is the following, I believe

https://github.com/bitemyapp/learnhaskell

ummonk6• 7 years ago

What do you need to write real Haskell? The core of the language is extremely simple. If you understand how to write and use
pure functions and values pattern matching sum and product types how to glue together IO to make side effects

You can do pure functions, pattern matching, and sum and product languages in plenty of other languages that have much more user-friendly syntax, community, and documentation. Also doesn't hurt that they have impure IO so you don't have to jury-rig impure IO using a monad.

tome42• 7 years ago

I don't think what you say contradicts anything in the article ...

ummonk6• 7 years ago

It does. Haskell is harder to learn than other languages because it has a difficult syntax, navel-gazing community, and complex documentation.

ConcernedCoder2• 7 years ago

Yeah, ok, let's say it's true that it's no more difficult to learn Haskell as opposed to any other... with a mindshare of 0.29% ( according to something like this: http://pypl.github.io/PYPL.html ) isn't that like saying that it's no more difficult to learn "Upper Egyptian Arabic" ( see: http://pypl.github.io/PYPL.html ) rather than something a little more esoteric? ... i.e. WHY would you want to learn it unless you have a very specific use-case, i.e. moving to Egypt

(edited for a word)

tome42• 7 years ago

You appear to be responding to what a zealous mod wrote not what anyone actually believes.

ConcernedCoder2• 7 years ago

  My point was/is that even if it IS easy to learn, relatively speaking, WHY would you want to learn it when it's obviously a niche language... I mean a REALLY small niche at that...

viburnum• 7 years ago

When I tried to learn Haskell, I tried doing the kind of stuff I usually do in Ruby: parsing log files, converting text formats, etc. It seemed hopeless. I'm curious to hear about the experience of someone who uses Haskell for everyday tasks. Does anyone do that?

iLemming• 7 years ago

I've struggled with Haskell for a long time. Surprisingly, learning Clojure made many Haskell concepts clear and more approachable for me.

Learning Haskell is no harder than learning any other programming language

Related Stories