Hacker News Reader

Comment by li4ick | Hacker News Reader

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.

View on HN

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

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.

I was calling out the Java memory model and concurrent programming in Java as being very complex. It's inherent to the language itself and almost impossible to change. I was only calling it "hidden" complexity as most people do not see an issue when writing single threaded programs. Concurrent programming I genuinely believe is easier in Haskell.

And also using the java.util.concurrdent package sidesteps most foot-guns involving roll your own synchronization.

Perhaps most, but not all. Even something as simple as a date formatter in Java is not thread-safe.

That was fixed with the Java 8 package java.time.format, https://docs.oracle.com/javase/8/docs/api/java/time/format/D...

Ok bad example, but it shouldn't have taken them 15+ years to fix it.

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.

Understanding the Java memory model properly is not easier than anything Haskell throws at you.

SingletonFactory is an oxymoron.

Edit: oh wow, it actually exists

> SingletonFactory is an oxymoron.

It's not, you still need to create the one instance when it is first needed. It's possibly excessive abstraction, but it's not an oxymoron.

I've come to believe that "excessive abstraction" is practically a synonym for "object oriented programming". It takes an incredible amount of discipline to not abstract unnecessarily in an OO shop.

It's not just excessive abstraction, separating Singleton and SingletonFactory can even reduce encapsulation since you can't make the Singleton constructor private.

You can if it's in the same file.

A factory method returns instances, but there is no obligation for those instances to be created on demand or each time the function is called. Some Singleton implementations only initialize the Singleton object at first call, for example, and other implementation units the object at startup.

That's not oxymoronic at all.

You have a Factory<T> interface. Depending on T and context, it may be reasonable to provide an implementation of Factory<T> that returns a singleton, something taken from an object pool, or a new instance of an object.

I haven't worked in an IoC-heavy world for awhile, but a SingletonFactory is neither silly nor an anti-pattern.

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

How do you even take 3 semesters of category theory?

By failing twice.

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.

You need it for a deeper understanding of type classes and algebraic data types. You can get by without it but I would say your understanding of things like a "functor" will be flawed.

This is not true. For example, The typeclassopedia contains all you need to know about functors and doesn't go into detail about the underlying Category Theory.

Agreed. Having worked closely with them, I would say such Haskell luminaries as Simon PJ, Lennart Augustsson and Neil Mitchell have not "learned category theory" (and I don't think I'm being too offensive to them if I state that). In fact the only figure of highest repute in the community who puts much stock in category theory is Edward Kmett.

excerpt from typeclassopedia:

"The wise student will focus their attention on definitions and examples, without leaning too heavily on any particular metaphor. Intuition will come, in time, on its own."

typeclassopedia admits that the intuition is missing. I would go on to argue that just going from the definition alone you would think that a functor is anything that is mappable and that fmap simply maps a function across a functor to produce a new functor.

The intuition that cannot be grasped without some category theory is that fmap actually lifts a regular function of standard types into a function between functors. A functor is more than just fmaps.

you draw the wrong conclusion from that excerpt. It does not say "Intuition that cannot be grasped without some category theory". It is saying that you need to see many concrete examples to learning something abstract. This is how it works in all of education basically, and there's isn't an easy substitute. Learning "category theory" will not replace your need to see concrete examples to grok something inherently abstract. You'll have to go through the concrete examples anyway.

Those concrete examples aren't visible until you do category theory. That is what I'm saying. You are drawing the wrong conclusions.

There is literally not enough information from the definition of the type class Functor and from examples of usages of that definition for a programmer to truly understand the concept of a functor. That is the conclusion I am deriving. It is not wrong. You are wrong. What's going on is you are deriving a conclusion convenient to your view point.

Sure you can get by programming haskell without category theory just like you can program without knowing the notion of an algorithm. However in both cases you are worse off without the knowledge.

Never did I assert the need to learn category theory to write Haskell. I was speaking of my own experience and if you can understand the underlying category and type theory that goes on behind the scenes implicitly and can write Haskell programs without ever thinking of the theory behind them that is awesome. Personally I don’t like languages that feel like magic so I strive to learn what is behind the abstractions and for me that meant getting a deeper understanding of category theory. Furthermore I feel as a computer scientist the more math I can learn and absorb the deeper my understanding grows on a multitude of subjects. Sorry if my post came off as flipped I was simply trying to use humour to accentuate the difference in the conceptualization of Haskell vs. a non-pure procedural language.

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

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.

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

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

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

Or those 200+ UB use cases.

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.

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!)

I felt that I'd reached a point of reasonable proficiency with the language, and since I'd been learning it mostly for my own entertainment I decided to turn my attention to some other new hotness (Rust, IIRC) rather than slog through increasingly more difficult and obscure (to me) features of the language with diminishing returns for my personal projects.

Entertainment is maybe not the right word, though it was definitely entertaining. Learning Haskell was the beginning of a personal renaissance in my approach to programming, and as a self-taught programmer (and professional software engineer looking to expand my horizons) that was a huge deal.

> I felt that I'd reached a point of reasonable proficiency with the language

Ah, well that puts quite a different spin on things!

What, you think I was wrong? :)

(that very well may be the case)

No, not at all! I previously thought you meant "Haskell was hard for me to learn because I couldn't even learn lens" when you meant "I learned a lot of Haskell but couldn't be bothered to learn lens"

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

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

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.

I’m not sure lifetimes are that much more complicated than the way C++ does implicit type coercion of user classes, resolution of compile time polymorphic functions, namespaces or SFINAE. I do agree it’s more like death by a thousand paper cuts rather than the torso-cleaving katana of the borrow checker. However I tend to believe any C++ codebase of consequence will run into some of this stuff, unless practices that avoid all the pitfalls are metoculously followed. Which implies a rather thorough understanding of said complexities.

Those are all advanced C++ features. Lifetimes smack you in the face 5 minutes into "Hello world".

Maybe not complicated in terms of how abstract it is, but pretty much everything in C++ is very complicated in terms of all the little rules and exceptions and subtle interactions between behaviors and compilers leveraging UB to do insane things. You can do a lot without thinking about it but if you want to have a precise understanding of things prepare to have to read a ton of rules. It's a language lawyer's dream language.

I think the complexity of C++ comes from the edge cases, unexpected interactions between features, conflicting syntax, and bad assumptions made over its long history.

I mean, the rule of three is just insane. How is anyone supposed to anticipate that behavior?

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.

But it I throw mature Python/C++ code at you, with concepts you don't know, how is it easier?

Those Haskell threads are full of exaggerations. I don't know/use a lot of Haskell concepts and I can still produce software with it. You can be just fine with IO and passing everything as arguments. Which is, well, what article is talking about.

Why do you write Python and C++ in one line? C++ is an extremely hard and esoteric language. Python is very easy language. They are like two opposite points.

C++ can be quite manageable in a professional setting, where you get Qt or boost. Then it's like any other programming language.

I think the major troubles for beginners with C++ is that you can't do anything out of the box like work with files, create a directory or perform a HTTP request. Whereas python or java are ready to use.

Eh, I strongly disagree with this characterization. I did c++ for a few years at Google and am now back to developing in it, and I'd say it's probably my favorite language to work in a codebase that sets the right constraints on it. But that doesn't change the fact that it is replete with unintuitive footguns even for those comfortable/experienced with it, in a way that Python or Java absolutely isn't.

The closest thing i can think of in Python is passing a mutable object (like an empty list) as a default param value. C++ is littered with bug-prone landmines like that.

It's easier because Python/C++ have huge communities at this point and Haskell does not. It's also easier because most people learn some variety of Java/Python/etc as their first language. So languages with similar structures and conventions are easier to grasp.

Every time someone has suggested I learn Haskell the discussion goes similar to suggesting I learn German. Sure German from a language perspective has some advantages over English in some situations. Some even argue that it's an objectively better language. But I live in Pennsylvania and speak English as a first language. Outside of moving to Germany/Switzerland/Austria, how do the advantages of German provide enough benefit for me to invest the massive amounts of time to become fluent?

Sure if we could turn back the clock on Computer Science education and have everyone learn lisp as their first language maybe we'd all be avid Haskellers these days and be better off for it. But given how history went it is "harder" to learn and less productive to work in due to external factors alone, regardless of how intrinsically easy/hard the language may be (which is entirely subjective).

There's still plenty of value in learning Haskell even if you're not going to use it daily.

I'd go as far as saying it's essential for anyone who likes programming beyond just a profession. Same with lisp.

You don't need to learn all of the language extensions or how to architect serious applications with free as the OP said but it's very useful knowledge and one of the pedestals from which all other languages should be judged.

Plus you'll understand why Idris and dependent types are an interesting future development in safety and language design. While also understanding the source and inspiration of many features in far more popular languages like JS and Rust. And there may be a real future in it via PureScript and other similar projects.

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.

> You can’t do this in Haskell. You really do have to learn all the complex hierarchy of paradigm-committing patterns

Err, no you don't. The only slightly unusual concepts Haskell 98 has (from a functional programming point of view) are monads, type classes and laziness. Haskell 98 is a perfectly decent language to write computer programs in. In fact it's even perfectly decent if you largely avoid monads and type classes!

The "you can focus on subsets of the language" claim is no weaker for Haskell than it is for C++.

> “The only slightly unusual concepts Haskell 98 has (from a functional programming point of view) are monads, type classes and laziness.“

Exactly. The way they manifest in Haskell requires huge time investment before you can write basic programs. For example, how do you write dynamic dispatch in Haskell 98?

If you give an answer that either (a) involves exotic use of type classes or (b) say “don’t desire dynamic dispatch in a functional paradigm and instead restructure the whole program to avoid needing it” then you’ve proven my point.

That fact that you think monads, type classes and laziness, being “three” concepts (except really they unpack into way more top-level concepts, especially the first two), means you have a huge blind spot. Your experience makes you think of them as self-contained things but they aren’t and even just those three things yield huge complexity sprawl in Haskell.

I'm sorry, I'm not sure what this has to do with the "you can focus on subsets of the language" claim being no weaker for Haskell than it is for C++. Perhaps you can clarify?

Your claim now seems to be "Haskell contains a great deal of complexity" or "You can't implement dynamic dispatch in Haskell" which are different things entirely.

(FWIW I'm not quite sure what dynamic dispatch is or whether I've ever needed it, in Haskell, C++ or Python)

Suppose you wanted to write professional software in Haskell using only the IO monad and modules of functions. How would you do it? I don’t believe it can actually be done in a serious way.

Suppose you’re using C++ but you don’t want any objects, exceptions or templating. Ok, you’ll be fine. It will be a lot like C, but you’ll be fine. Nothing will be substantially harder to solve, design or implement.

> Suppose you wanted to write professional software in Haskell using only the IO monad and modules of functions. How would you do it? I don’t believe it can actually be done in a serious way.

People write professional software in OCaml and Scheme so I hardly believe your suggestion is impossible.

> Suppose you’re using C++ but you don’t want any objects, exceptions or templating. Ok, you’ll be fine. It will be a lot like C, but you’ll be fine.

Sure, and the same applies to Haskell, except with Standard ML instead of C.

I'm not suggesting that one would be particularly productive like that, only that the level of complexity of Haskell is about the same order as the level of complexity of C++, and one can reduce one's subset of Haskell (all the way down to SML if necessary) in the same way that one can reduce one's subset of C++ (all the way down to C if necessary).

> Nothing will be substantially harder to solve, design or implement.

That surely can't be the case. If it were then objects, exceptions and templating would never have been implemented.

I must be missing the point here because if you wanted to “write ... Haskell using only the IO monad and modules of functions” you could simply write your modules (Haskell supports modules) and then write your IO. Done.

Is that what you mean? Or is this really about something else?

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!

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)

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.

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

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

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.

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.

> 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

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

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

People look at weird syntax and discussions about things that have no resemblance to the problem they are facing, and conclude it must not be useful for anything real. Yes, those problems have no resemblance to any real problem because of abstraction, but most people's experience with abstraction is in a Java-like language where nothing good ever gets out of it.

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.

> In theory there's no difference between folding left and folding right

There's no difference in practice either for a sufficiently small dataset.

> in practice there is a right way and a wrong way

Sure, but that's true of all technologies.

Yes, Haskell can't help you escape the limitations of our world — or indeed our hardware — but it doesn't pretend to either.

> There's no difference in practice either for a sufficiently small dataset.

As a non-Haskell user, just for reference what's "sufficiently small"?

It depends on your needs. This is neither constrained to Haskell specifically nor functional programming more generally.

If you were building a website for your local Italian restaurant, what would your needs be? Do you need an ElasticSearch cluster to handle customer menu item queries? Do you need a database at all?

In Haskell's case it's best to avoid lists entirely, as they're _usually_ not the optimal data structure. But best for whom? Does the beginner care that a set operation would be more effective than a list operation for their given use-case?

Not sure how that's an answer to my question?

In my day job, I frequently generate records returned from a database along with local changes to be posted later, and say compute the sum of one of the columns. That sounded like something I'd use folding for, with my limited knowledge, so I was just curious at which point (order of magnitude) I'd have to worry about doing it this way or that.

But if lists are not to be used, what should I use for the above? And will the data structure you propose be fine with either fold?

Again, it depends. A left fold might be fine (and likely will be). Lists might be fine (and likely are). I don't know anything about the size of your data, or about the business you're writing software to support (who knows, maybe you're writing a FPS game, or some real-time aviation software!).

At this point (taking into account the extent of your knowledge as you yourself described it), my advice would be to just use basic folding and lists. At some point in the future, if you observe some performance issue in exactly that area, you might remember this and think "hmm, memory consumption is bit excessive here; maybe I'll try a foldr instead", or "finding the intersection of these two big lists is a little slow; maybe I'll convert them both to sets instead?"

>There's no difference in practice either for a sufficiently small dataset.

So what happens in practice with unfortunately large datasets?

>Yes, Haskell can't help you escape the limitations of our world — or indeed our hardware — but it doesn't pretend to either

Then what is Haskell's value-proposition when it comes to solving real-world problems?

> So what happens in practice with unfortunately large datasets?

You take a different approach. Haskell provides plenty of options.

> Then what is Haskell's value-proposition when it comes to solving real-world problems?

There are many. You can consult your favourite search engine to learn more.

>You take a different approach. Haskell provides plenty of options.

So do other languages. Why is Haskell special in this regard?

>There are many. You can consult your favourite search engine to learn more.

None that seem to address the problem of diminishing returns.

> So do other languages. Why is Haskell special in this regard?

I never suggested other programming languages don’t also have value. Again, if you want to educate yourself further on a specific technology’s benefits, I invite you to make use of a search engine instead of sea-lioning on a technical forum.

> None that seem to address the problem of diminishing returns.

That’s your opinion. Nobody is forcing you to like Haskell. You are free to just ignore it.

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.

Sure and at that point you need to learn those internals. That's just the way it is with everything, no?

When things go wrong, you might not have time to do so. When my project started to leak memory at enormous rate, I was able to find the issue quickly enough. But if I didn't know how all those things work, I would spend weeks or months learning all those things. Restarting application every 10 minutes for a week is not a good idea.

How is this different for Haskell than with anything else? If you want to be an expert in something, anything you do need to put in the work and learn it inside-out. There is no royal road. I fail to see how this is specific to Haskell...

It boils down to the steepness of the learning curves.

If I am in the business of system reliability, I will choose the language with shallower rabbit holes.

Abstraction layers are great for builders and terrible for fixers. I am both, so I need to strike a balance.

I agree with you, I don't think that it's different for Haskell.

Haskell's internals are actually pretty easy to inspect!

- Haddock hyperlinked source makes it easy to understand libraries if you need to dig into internals

- ghci makes it easy to interactively learn the language - and a new codebase!

- Haskell can dump the stages of its codegen pipeline (Core, STG, Cmm)

- Profiling and Event logging exist and are easy to use

- You can even write an inspection test to assert certain behavior holds. For instance, that no allocations occur or that some abstraction (e.g. Generic) is truly erased by GHC's optimizations

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.

> I cannot imagine anyone using a database effectively on any significant amount of data without understanding…

You'd be surprised just what proportion of systems running in the market operate on amounts of data you would not deem "significant".

And as I said in another comment, Haskell doesn't try to pretend that computations run with no hardware constraints.

> All abstractions leak when pushed

Yeah. But we might have wildly different ideas for where that boundary is.

I wouldn't be surprised because I seek employment in areas where my skills are valuable.

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

But conversely you probably didn't have to understand what filesystem the database runs on, whether it is in a RAID array, whether the network connection was over Ethernet or T1, etc.

All abstractions leak. The question is how leaky they are. In my experience Haskell abstractions are much less leaky than most.

I did and do; when performance at the database level isn't right, you need to look into OS stats, I/O stats, disk stats (the SAN is an area ripe for unexpected contention, RAID5/6 act like a single spindle and inhibit random access in ways that RAID1 or RAID10 don't, stripe length in RAID5/6 bloats the size of small writes, etc.), but I had to stop somewhere :)

> but I had to stop somewhere

Why? You seem unsatisfied with any of the previous layers of abstraction, so where does it end? When can I truly call myself a user of a database?

When you don't have to fix it when it stops servicing requests, or worry about scaling workloads.

When you treat it as a black-to-grey box, not a grey-to-white box.

So I'm confused - how many years did you have to study before you felt confident enough in your grasp of all the underlying concepts to write your first "Hello World"?

Hello World doesn't push much to the limits.

I’m not much of a haskeller, but friends’ war stories indicate that laziness leaks quite a bit.

Aha, yes! You are right. But then so does strictness. See https://augustss.blogspot.com/2011/05/more-points-for-lazy-e... for some examples.

Laziness is a definitely a double-edged sword, with sharp edges.

Thunk leaks happen, but they aren't that scary. They all pretty much have one of a handful of root causes.

It's definitely a wart of laziness, but it's also pretty easy to avoid.

As far as abtraction goes, laziness doesn't leak. In fact, it's a big reason Haskell performance composes. The head . sort example is contrived, but it holds true in more complicated & useful examples as well!

I am in the Database-as-a-Service world.

I have to understand all the intricacies of the system, so people who choose to treat databases as black boxes don't have to. There is only so far this abstraction holds.

Stateless (immutable) code scales horizontally. ACID[1] doesn't.

[1] https://en.wikipedia.org/wiki/ACID

Fun aside, coworker recently had a fun issue where the database server would halt due to running out of disk space... except the disk had over 100 GB left.

Turns out NTFS has a maximum number of file fragments a file can have, and if it exceeds that it will refuse to grow the file (for obvious reasons).

Hardly everyday stuff though.

This interesting, I work as a data engineer but never had to really understand how joins or indexes work because I work 99% of the time with denormalized data. I also do not know much about b-trees. I think you come from the database developer point of you rather than the database user point of view.

There is also other aspect of this, even if I do not understand joins or b-trees I can measure performance so I can figure out which combintion of joins are the faster. The reason that I prefer performance testing over getting to know the theorethical background for certain things is because in many cases your performance also depend on the implementation details, not only on which tree data structure backs your implementation.

It's exactly because the performance depends on the implementation details that when you understand implementation details, it can guide what you test and help find an optimization peak faster - or come up with a theory of another peak more distant, and journey through the performance valley to find it.

Implementation details follow the contours of the fundamental algorithms and data structures. You understand the outline of the implementation details - the bones, if you will - from that. And you can dive into the source (or disassembler - I've done that on Windows) to fine tune knowledge of other specifics, with e.g. gdb stack traces on the database engine when it is abnormally slow to focus attention.

Without having gone to battle together over some performance problems, or me writing significantly longer battle-story posts, we're probably not going to be able to communicate effectively here.

Do you struggle to use a computer due to not having an expertise in semiconductor physics?

<rant> I work with a team that has a 16 TB database, who doesn't understand how it works. They seem really surprised when their queries run slow. </rant>

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.

I’m not sure I agree with that.

How does this work in the context of CSS? Do people making websites need to understand how WebKit paints the screen?

The word “effectively” seems rather arbitrary here too.

I feel like being able to find an exception doesn't mean the rule is invalid?

How many exceptions should I find to invalidate the rule?

Enough to show it's at least on the same order of magnitude as the number of situations where the rule does hold.

I actually think you do need to understand rendering logic to some extent to use CSS effectively.

For example I have seen many having a hard time understanding why it is trivially easy to align an element to the top of the screen but tricky to align something to the bottom of the screen - something which would be symmetric and equally simple in a typical application GUI framework.

But understanding how layouts are generated makes this clear.

IMO the conceptual level below CSS is in the design sphere - the box model itself. You would not believe the number of people who hack together properties until they get something that looks right, without understanding the box model, who think they're really good frontend developers.

Were you thinking of Joel Spolsky's Law of Leaky Abstractions[0]?

[0] https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

I don't think so, though it's close.

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.

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

Reply on news.ycombinator.com