Hacker News Reader

Comment by shiado | Hacker News Reader

In university I was obsessed with Haskell and being clever and writing code that was an unholy stack of lambda functions and fancy constructs like monads and monad lifting. I used the typical intellectual supremacy argument inherent to many fields of study where you reason that something isn't used in industry because industry people are stupid and cannot possibly grasp all these advanced abstract concepts.

Eventually I realized that Haskell code is slow to write, hard to reason about efficiency, lazy evaluation sucks for most things, and most importantly Haskell is hard to read by others. Going on Hoogle to look up some package and seeing some abandoned doctoral thesis used by nobody where the only documentation is types becomes exhausting after a while.

Go is now my favorite language.

View on HN

Surely there's a middle ground here. Most code written by university students in any language is problematic and not professional-quality. The specific deficiencies exhibited may vary from language to language. The extreme you illustrate here is clearly undesirable in any professional context, but that doesn't mean it reflects the code written by any professional Haskell developers out there.

Yea to me his comment reads as a whiplash to realizing some of the downfalls of haskell. But he seems like he takes it way too far.

I dunno, not being able to reason about performance is a pretty big deal. I've only ever fantasized about learning haskell, but I can tell you that this quality is what makes sql (or god forbid an ORM) a pain to deal with in production. The explain plan for a given sql query can change on you for no reason other than your table has grown. You can go from using an index for speedy queries to a full table scan because your sql engine decided to no longer use any of your indexes.

I don't know what the equivalent cases might be for a more general purpose language, but I strongly suspect it's a problem all declarative languages suffer from.

>The explain plan for a given sql query can change on you for no reason other than your table has grown

True, but that may well lead to more predictable performance. If you write a procedural program and then the dataset grows, your programm might slow down dramatically while the new execution plan generated by the SQL engine would adapt and keep performing well (...ideally).

You could argue that a procedural programmer could anticipate the growth of the dataset and choose a suitable algorithm from the start. But if you have not one but tens of datasets and value ranges whose size relative to each other determines what the best algorithm is then manual optimization becomes very difficult indeed.

A Haskell compiler doesn't use knowledge of input data to optimize the program though (at least not to the extent a database engine does). So I think a relational database engine is more useful in this regard.

Haskell is not declarative, however, so the programmer actually has control over the evaluation order through ordering demands for the results of computations. It does, however, take a little longer to fully grok how lazy code evaluates compared to a simple left-to-right eager evaluation a la Scheme, so it can be a bit of a rough start (and many usually only decide to take the full time to understand laziness when they're in the middle of a critical issue due to it). However, a large domain of problems (for example, search) are more easily expressed in a compositional manner using laziness.

Forgive my ignorance, I really only have a passing familiarity with haskell, and I did a quick search before trying to lump it in with sql as declarative, but http://www.haskell.org states above the fold, "declarative, statically typed code". If it's not generally considered a declarative language, is there a better way to describe the language?

I think "declarative" exists on a spectrum. There's no clearly defined line between declarative and nondeclarative that I know of. For instance I would say Haskell < Prolog < SQL are on one end of the declarative spectrum, but in each case you do end up reasoning about the underlying execution model.

This is a fair statement. What I (and I believe most others) mean by declarative programming is more specifically logic-and-constraint programming, but in many ways you could view Haskell's type system, typeclasses, and laziness in combination as being more declarative than, say, a purely functional subset of Scheme. To the grandparent post I originally responded to - If you wanted to take a look at a more purely declarative language, see miniKanren https://docs.racket-lang.org/minikanren/index.html There exists an extension with constraints as well, cKanren http://scheme2011.ucombinator.org/slides/Alvis2011.pdf

To try to summarize, a declarative language is one in which you tell the computer what you want, but not so much how it is done. Logic Variables (Unification) are the key differentiators of these systems.

Take a look at chapter one of CTM for a really nice breakdown of the different orthogonal components to a language. I have a feeling differentiable programming and (dependent+) types belong on that list, too.

As an additional question of my own for anyone reading - is there anything that should be on that list thanks to modern CS research, that isn't?

> It does, however, take a little longer to fully grok how lazy code evaluates

I doubt it would take anywhere near as long if students were told from the get-go that the only thing triggering evaluation is the destructuring as it happens during pattern matching.

Unfortunately it seems like most teaching resources would prefer to uphold a sense of mysticism.

It's extremely frustrating, isn't it?

>Surely there's a middle ground here.

LINQ. Monads that are easy to reason about without the need to speak about monads, functors and so on.

To communicate we need names for things; "thing that has a suitably associative implementation of flatMap" is an important concept, and "Monad" is the name that exists for it.

The attraction of Haskell is to build correct software in a mathematically principled way. With practice, it is also remarkably productive, certainly more so than Go when used as a general purpose language. Haskell is simply much more expressive and capable of abstracting over many more things (perhaps this is why you say it is hard to read). The Haskell ecosystem is also constantly evolving and solving more and more real world problems, often problems that have not been solved in other languages. Modern Haskell effectful streaming libraries actually make reasoning about stream processing much easier than in say Java, where the presence of effects (exceptions etc) destroys reasoning.

> Go is now my favorite language.

Is this really true? Or is it just the tool you are now most familiar with? It's certainly a much more riskier proposition to try and feed the kids writing Haskell.

Quoting Rob Pike on Google's own Go programmers: "They're typically fairly young, fresh out of school, probably learned Java ... They're not capable of understanding a brilliant language ... So the language that we give them has to be easy for them to understand and easy to adopt."

The Go toolset can obviously get the job done, but I don't understand why it would be anyone's favourite language, it doesn't even sound like it's Rob Pike's favourite language.

>certainly more [productive] than Go when used as a general purpose language.

Come on, there isn't really any evidence that Haskell is more productive than Go. It's not as if anyone's run a controlled experiment.

Anecdotally, I've written code in both languages and not found much difference in productivity. I think a lot depends on the size of the team, the size of the code base, the nature of the algorithms being implemented, and the amount of IO that's performed. Haskell's abstractions have saved me time in some cases. But then again, I've also spent unproductive hours figuring out the complex abstractions that someone else decided to use. Haskell's so-so tooling and culture of using unqualified imports compound this problem.

And then there's the issue of compile times. Do monad transformers make me more productive? Do functional dependencies make me more productive? I'm not sure. In contrast, I have no doubt whatsoever that fast compile times make me more productive. Most go codebases compile in under a second, whereas GHC's compile times are absolutely abysmal.

Go is a language without intellectual insecurity. It doesn't care if you think it's stupid, or if you think that go programmers are stupid. It focuses on features that are known to make everyone more productive (e.g. fast compile times) at the expense of features that make you feel smart.

> There isn't really any evidence that Haskell is more productive than Go.

Go appears to be a network services language. Although Haskell has equally good for-loops and channels, it does not have an incremental garbage collector or fast build times. So Go has its place.

For general purpose programming, Go is lacking so many features and provides such verbose syntax for what little it does have (worse than modern Java, e.g Lambdas and conditionals), that one can certainly say it is starting from a disadvantaged point with regard to productivity.

It sounds like you've had some bad experiences with some of Haskells libraries and tooling. The ecosystem is certainly still rapidly evolving and good documentation and libraries may not exist in all areas. With regard to complex abstractions, the Haskell community usually likes to formalise and reuse them. Learning an abstraction usually results in a big payoff.

EDIT:

> Do monad transformers make me more productive?

Monad transformers are specific to pure functional programming, but yes they aid productivity. For example, I can build an effectful streaming type with resource management and other desired features by stacking existing transformers. In Go I would be solving such problems with for loops.

> Do functional dependencies make me more productive?

Functional dependences are specific to Haskell type classes, but yes they can aid productivity. For example, you want to express arithmetic ops on matrices and scalars and have the compiler figure out the correct dispatch and return type depending on the type of the values. In Go I can't overload operators or do multiple dispatch.

>The ecosystem is certainly still rapidly evolving and good documentation and libraries may not exist in all areas.

Hmm, that's what people have been telling me since I first learned Haskell in 2002. Your brush this off as if it's a minor point ("some bad experiences with Haskell's libraries and tooling"), but libraries, tooling and compile times are a major, major influence on productivity. If you're at leisure to wait for decent libraries and tools to become available, then good for you! I was kind of hoping to get stuff done now, though.

Abstractions have both positive and negative payoffs. Take MTL as an example. It certainly increases code reuse and makes code more concise. On the other hand, it's also partly responsible for Haskell having a gazillion different techniques for handling errors, with little community consensus on what the best techniques are (see e.g. https://www.reddit.com/r/haskell/comments/5bkqf1/exceptions_...). I spend at least some time thinking about this stuff when I write Haskell code. I spend no time thinking about it when I write go code -- I just write the same error handling boilerplate that every go programmer uses. It's not pretty, and I don't get to pat myself on the back for understanding something complicated. But does it make me less productive? Not sure.

Response to edits: I think you're misunderstanding my comment. I use these features and know what they are. I'm telling you that I do not see any clear productivity benefit from them in practice. Haskell advocates do have a maddening habit of assuming that anyone who criticises any aspect of the language must be a complete novice.

> If you're at leisure to wait for decent libraries and tools to become available, then good for you!

As I said, it depends on the area you are working in. Haskell does have some good libraries.

> Haskell advocates do have a maddening habit of assuming that anyone who criticises any aspect of the language must be a complete novice

Please don't take it personally, I was attempting to explain those features that you mentioned to others who might read our posts (perhaps wishful thinking).

I try to promote Haskell whenever I can because it has been enormously successful in everything I have applied it to and needs all the help it can get. It doesn't have a billion dollar company behind it, just a small community of mostly volunteers.

> I was attempting to explain those features that you mentioned to others who might read our posts (perhaps wishful thinking).

/waves from the gallery

Tool quality and compile times are an issue whatever area you are working in, however.

Compile times are often mitigated by just using the runHaskell interpreter, or turning off optimisations.

What sort of tools does Go have that Haskell doesn't? From what I can see, most Go projects just use Makefiles and text editors. The package manager is described as "experimental".

In Haskell land we have many good choices, with my favourite (for deterministic reproducible builds), being nix and cabal new-build. I've also seen Haskell Shake replace C++ Makefiles at work for a huge speedup.

Haskell has good API search (Hoogle), docgen (Haddock), lint (HLint) and graphical profiling tools (Threadscope). Refactoring tools like HaRe and others, are also starting to appear.

>Compile times are often mitigated by just using the runHaskell interpreter, or turning off optimisations.

No, not really. If you touch a module that a lot of other modules depend on, then you have to recompile a lot of code, and that takes ages (even without optimizations). I'm hardly the only person who has this issue: https://www.reddit.com/r/haskell/comments/45q90s/is_anything...

To be fair, fast compile times are something that's hard to get excited about in the abstract. Before I tried Go, I'd read that it compiled super fast, but that wasn't something that really attracted me to the language. I certainly didn't think that it was worth giving up, say, generics to achieve those fast compile times. But now that I've actually experienced the joy of never having to wait for code to compile, it's really changed my perspective on language features.

As the reddit thread explains, the only people who are really motivated to work on GHC are people who want to add yet more features to a language that's already extremely feature rich. Compile times are getting worse and worse, and the value added by the additional features is getting less and less.

Honestly, Haskell 98 gives me 95% of what I'd want from a pure, lazy functional language. I'd much rather have a simple, fast Haskell 98 compiler than a beast like GHC. But unfortunately, it's too

>What sort of tools does Go have that Haskell doesn't?

For me, VSCode integration that just works. I get instant highlighting of compiler errors and I can jump to definitions, rename variables, run tests from within the editor, etc. etc. I'm aware that the Haskell ecosystem has at least some of this functionality in principle, but it's way more fragmented and less reliable.

Pure FP is just using math as its primary source of programming patterns and techniques, while most other languages, like OOP, use arbitrary conventions to abstract code. Because mutation gives you tremendous flexibility, you can model many kinds of patterns, give it some analogy like inheritance in animals, and then write a language that has it out of the box. Haskell on the other is using math to construct its patterns, so while the learning curve is higher, eventually you realize this is the ultimate abstraction (category theory), and it cannot go more abstract than that. This is useful in some scenarios requiring more logical rigor, but I agree it's not always the best tool.

> eventually you realize this is the ultimate abstraction (category theory), and it cannot go more abstract than that

This is exactly the kind of false sense of intellectual superiority to avoid. Mathematicians and category theorists don't talk like this. Even the parts of Haskell that have the flavor of category theory aren't really all that much like category theory.

Maybe you can expand on that, and/or show me something more abstract than category theory. Programming = abstracting information processing. Category theory = the mathematics of abstract functions (or morphisms a.k.a. changing something)... so it makes sense that CT captures something very fundamental about computation.

Technically, category theory is not more abstract than the rest of (abstract) algebra.

You can derive all other math branches with CT, so yes, it is more abstract. It is "higher level" (in the same sense of programming languages) than other maths.

Please point out where somebody genuinely puts an effort to found math on category theory? The standard way to do so is set theory, and the more recent hype is type theory.

Category theory in itself is pretty useless. Categories are a bit like graphs in that: they are too general.

There are serious mathematical theories using category theory as their language (mostly commutative algebra and whatever it touches) just as there are serious theories using the language of graphs, but in both cases the meat of the math is not in the underlying language.

There are serious efforts to found maths on elementary toposes, which are categories with certain properties. Much the same way that the axioms of ZFC model the properties of sets in terms of the "is element" relation, you can give first order axioms for how the morphisms and objects of an elementary topos behave. Then you may add more axioms to assert that the elementary topos you're talking about is really a category of sets in the sense of ZFC.

If you want to research more about this, I can recommend sheaves in geometry and logic by Maclane and Moerdijk. You can also search for "algebraic set theory" and go from there.

And btw, type theory is essentially the same thing. The axioms are IMO uglier and more ad-hoc, but there are (some proven, some conjectured) equivalence results.

https://homotopytypetheory.org/book/

That is a) a great project b) not category theory.

>Please point out where somebody genuinely puts an effort to found math on category theory?

What about the following: https://ncatlab.org/nlab/show/foundation+of+mathematics#CFM

Even if the meat of the math is not in the categorical aspects of a theory, the categorical input can be useful - if nothing else, then as a convenient language.

No, you can’t. The vast majority of analysis cannot usefully be represented in category theory. You can’t express everything in analysis using morphisms and maps.

When you’re working with structures (algebra, geometry, topology, etc), sure, you can construct them in the language of categories. But that’s very far from “all of math”.

You can derive all other math from any Turing complete system. Category theory is no more powerful than that.

Given that turing complete systems are not total, you can actually derive anything, including falsehood, from them. The point being that a general 'turing complete' system is about as useful to use as the basis of mathematics as a banana.

Category theory is not a great basis for mathematics, but at least it's not inconsistent.

CT exists at the same level as some other "fundamental level" fields of maths like topology and abstract algebra (/algerbraic topology).

It's certainly very abstract and fundamental, but it's definitely not the root field.

You can't derive CT with CT. Though that has nothing to do with your point, just suggesting that we aren't there yet.

You are missing his entire point.

I know, which is why I asked for some clarification. I actually think haskell is able to directly implement CT, there is HASK category after all. If it's that this is too pretentious to even mention in HN, then I'm completely lost.

Hask is not a real category.

> there is HASK category after all.

This is disputed and seems to be at best conjecture/intuition without adequate formal definition supporting it.

1. Just because we have not thought of something more abstract does not mean category theory is the "ultimate" abstraction that cannot be surpassed. You would have said the same thing about sets before category theory was invented. 100% guaranteed there will be another, more abstract paradigm when the need arises.

2. Just because one thing captures something fundamental about computation does not mean it captures everything fundamental about computation, nor does it mean nothing else can capture fundamental aspects of computation (disjoint from what may or may not be captured by category theory). For example, category theory does a terrible job representing the mathematical subfield of complexity theory, despite it being entirely about computation. For that matter, "how abstract" is not always comparable, and the intellectual dick measuring of what is the most abstract is counterproductive. Even basic questions in particle physics have no known model in mathematics that doesn't break under gentle prodding, so is particle physics more abstract than mathematics?

3. Haskell does a lousy job representing the majority of ideas that make category theory useful to mathematicians. For example, universal properties are neglected Haskell, and at best they're implicit. Nobody actually thinks about the math when they're writing Haskell programs, they just think about Haskell types and programs, which makes the "techniques and patterns" of Haskell programming just as arbitrary as the conventions in random Javascript libraries. It's just that there are fewer names for the same thing because fewer people write serious programs in Haskell.

> Haskell does a lousy job representing the majority of ideas that make category theory useful to mathematicians. For example, universal properties are neglected Haskell, and at best they're implicit. Nobody actually thinks about the math when they're writing Haskell programs, they just think about Haskell types and programs, which makes the "techniques and patterns" of Haskell programming just as arbitrary as the conventions in random Javascript libraries. It's just that there are fewer names for the same thing because fewer people write serious programs in Haskell.

That’s an excellent point. So many people think they’re doing category theory when they’re writing Haskell, but Haskell is essentially nothing like the mathematics it borrows terminology from. They’re really not comparable. Which is absolutely fine, but then people shouldn’t draw parallels to the actual mathematics when the terminology is similar in name only.

>Even the parts of Haskell that have the flavor of category theory aren't really all that much like category theory.

Can you expound on this? Just because the type classes defined in Haskell can't represent a wider range of categorical structures they purport to capture, does not mean that more structure doesn't exist throughout a Haskell code base. For instance, many argue that the only type of functors used in Haskell are endofunctors, but thats not really true unless we have a narrow definition of 'functors used in haskell', no?

The typeclass Functor represents endofunctors from * to *. That's a pretty limited notion of "functor" when considered mathematically but also extremely useful for programming!

> ultimate abstraction (category theory), and it cannot go more abstract than that.

I’m curious. What makes you think that?

Not the other poster, but CT is the language of composition and abstraction, it's the high level language of math.

I think people are just butt-hurt that he used the word 'ultimate'.

Category theory is not “the high level language of math”. You cannot universally apply category theory to all other fields of mathematics.

What fields of math do you think it doesn't apply to?

Analysis.

Not true: http://www.math.cornell.edu/~oconnor/sia.pdf https://ncatlab.org/nlab/show/synthetic+differential+geometr...

You cannot build all of analysis from category theory. Categories, morphisms and functors are not nuanced enough to encapsulate everything in analysis. The question was not, “Can you restate some results in category theory”, the question was “what cannot category theory build?”

What you’re linking to is part of a relatively small corpus outside of e.g. algebraic geometry and topology that has successfully been used for nontrivial results. And as another commenter said, while it can be used for e.g. computation, it is extremely poor for complexity theory. There is a reason why basically any analyst (as opposed to algebraic geometer) will use set theory instead of categories for their work.

Because you cannot discard more detail than what CT has chosen to discard. You start with objects and arrows, and how the arrows compose. Every object has an identity which is another arrow, so in some sense you have just a composition of arrows, and that's it. CT starts really simple, and I don't think there's anything left to hide or abstract.

You may be wrong here, there have been some discussions - see for example https://www.quora.com/Whats-more-general-than-category-theor...

Every category is an infinity category, but the converse is not true. Thus, infinity categories are more general than categories.

But you don't have to go that far: Just remove e.g. identity morphisms from categories, and you get something that is more general than categories.

It is of course another matter completely whether these structures are a useful abstraction for what you want to accomplish. I've never come across something reasonable that has arrows and associative composition, but no identities. As for infinity categories, I remain very skeptical that they abstract any problems programmers not concerned with topology (i.e. > 99%) have.

So yeah, categories are a reasonable baseline from where you can build. But you can't show anything relevant and non-trivial that holds in any category. You'll need more structure, hence less generality, for that.

"Because mutation gives you tremendous flexibility ... Haskell on the other is using math to construct its patterns" - so mutation is somehow outside of math?

x = 0 and x = 1. Therefore by the reflexive and transitive property of equality, 0 = 1.

OK - it uses different notation where '=' is not the same as in maths. But that is kind of trivial. There are perfectly mathematical semantics of both functional and imperative languages.

> Because mutation gives you tremendous flexibility,

Interesting how perspective works. I frequently think of mutation as a really annoying restriction. In the presence of mutation, I can no longer assume things are what they say they are -- for they mave have changed between when I looked at them and when I speak of them.

That is fine, if you have a way of separating state from identity, and a way of synchronising the two when it makes sense to do so. Unfortunately, languages with uncontrolled mutation lack both.

I think Haskell is full of good ideas waiting to be reused in a successor language, with a focus on software engineering as well as just purity (Multiple senses of the term!) and rigour in abstraction.

The ideas are sound - When I write pseudo"Haskell" in other languages (Especially those with enforced purity), the rewards are fairly good for relatively little extra work - but Haskell (The language) is, even putting nicely, rough around the edges.

> [...] Haskell is full of good ideas waiting to be reused in a successor language

Thanks. You managed to articulate something I've been thinking for a long time.

To me a good programming language has empathy. Many languages that have some clever ideas have little empathy with programmers.

or you could simply use it as a 'better java', and forget all the extra bells-and-whistles.

I feel like this is a sentiment sort of echoed by it's creators: I believe they've stated that they (paraphrasing here) "don't want haskell to become successful". Not in that they don't want adoption at all, but they don't want to have to support commercial requirements around stability and whatnot that companies usually require.

As such, I think a language that comes along and takes a subset of the best features and learnings from Haskell would be a really great idea. Maybe like a python but for haskell?

I've been waiting for this for a very, very long time. I've not learned Haskell yet but generally speaking I'm very fond of FP in all languages, including Python.

However, the BDFL has arbitrarily decided that Python shouldn't even have remotely easy-to-use FP semantics (even though Python being so multi-paradigm is often touted as a major advantage), so (as an example) while he gave up on trying to remove `lambda`, he didn't make it simpler and more useful, which makes it so that whenever someone runs into it as a beginner they say, "Oh, what a stupid little thing that I can replace easily, FP is stupid." [1] I've been very upset generally speaking at how much control the BDFL is taking - not necessarily directly, but indirectly through people who seem to think that Pythonic™ programming is literally God and anyone who doesn't do Pythonic is Bad.

[1] https://stackoverflow.com/questions/890128/why-are-python-la...

I agree completely. Other choice decisions include:

"No tail-call-optimisation because I don't like recursion and I reckon the stack traces would probably be ugly"

And "python doesn't need to be any faster" even though it should be possibly to do so without compromising development speed.

If you want more functional style stuff in Python, check out Coconut: http://coconut-lang.org

I think an ideal candidate would look like Coconut with its python X haskell feel. Maybe target LLVM for nice compile time checks and performance benefits.

People often attribute this to careful language design - and to be completely honest, I can't say anything about that since I'm just some kid, but I feel like that doesn't make the BDFL immune to criticism. TCO, for example, would change almost nothing that already exists in the language, and would make it faster in at least some cases. As evidenced by Coconut, and in fact the number of libraries that smack TCO onto Python, albeit in a very inelegant way.

And sometimes it seems he intentionally cripples certain features so he can "prove" that certain ways of programming are bad.

> filter(P, S) is almost always written clearer as [x for x in S if P(x)], and this has the huge advantage that the most common usages involve predicates that are comparisons, for example, x==42, and defining a lambda for that just requires much more effort for the reader (plus the lambda is slower than the list comprehension)

(Quoted from https://www.artima.com/weblogs/viewpost.jsp?thread=98196)

If he had made lambdas even a little bit easier to write, then this criticism is completely blown out the window.

I'm not saying that FP is the holy grail and all must bow down to the ivory tower. But it disturbs me that the BDFL seems to be waaayyyyyyy to cautious about adding useful features to the language because Python Is Not A Functional Language.

I never went to university and don't have a PhD.

I find Haskell prevents me from being too clever and keeps me honest.

Monads are a part of that toolbox which prevent me from using unconstrained effects in my code.

https://patrickmn.com/software/the-haskell-pyramid/

parts of it's type system has a lot of gnarly dark corners, but the those parts aren't necessary to line-of-business kind of programming. unfortunately, those are the ones that get discussed on social media - which it sounds like you were inundated in / attracted to

the core type system is pretty lean

This is pretty similar to what happened to me. I was implementing an algorithm that had multiple parts and the data would arrive asynchronously.

The first time, I wrote the multipart algorithm using a functional style to encode each state. As the algorithm grew, it became more and more difficult to reason about and managing dependencies between the parts was harder, not easier.

When this became unwieldy, I rewrote it. However, when I wrote it the second time, I wrote the algorithm in a way that made it appear imperative. Everything was linear, starting with part B, then part C, etc. A small backend managed state, but you could read through the algorithm code and it almost seemed like it would run synchronously.

The second method was easier to read, debug, and modify. I will probably not go back to the functional method anytime soon.

Be weary of "programmer's rewrite bias". Anything you rewrite is likely going to be easier to read, debug, and modify since you understand the problem better the second time.

Also the first version may have had post-release bugfixes etc which are frequently omitted from the rewrite and then rediscovered later on.

Haskell's value was never in actual "engineering" (someone somewhere is itching to point me to no fewer than 4 Haskell projects that nobody cares about) but rather in "research". To this day, I don't understand Monads, even though somehow I used the heck out of them in my C# days, and I loved "reactive" programming which also supposedly comes from Haskell, and for that - I'm grateful. Haskell tries dozens of ideas nobody but computer language theorists care about but, once in a while, something cool drops out that is adopted and made usable for mere mortals like myself.

I think you're rather putting it on a pedestal. for the truck-driving contingent of haskell programmers such as myself, i assure you i'm not interested in theory much and simply enjoy haskell as a 'better java'.

May be "better than java" in your use case, but it's not "better java", as it's nothing like Java at all.

Seems unrelated to the topic under discussion.

Welcome to Hacker News.

I'm not sure. The subtext is "monads are one of many clever ideas in Haskell that make it hard to use in practice." And thus it answers the very (very very) specific question posed by the article, just in a more general context: "Are Monads a waste of time?" "Yes, Haskell is not worth the effort."

Monads are not a clever idea that makes Haskell hard to use. Purity is a clever idea that makes Haskell hard to use, and Monads are the best solution so far.

I’m in the same boat. I deep dived into Haskell for two years. It was fun and interesting at first but lost its appeal for some of the reasons you mention. I also enjoy using Go.

Even the creators of Haskell have conceded that lazy-by-default was problematic

https://www.google.com/search?q="the+next+haskell+will+be+st...

I think his point was more that it is purity rather than laziness that has been the big contribution from Haskell, despite the original research goals. A good language should allow for both strictness and laziness, as Haskell already does.

So true. Haskell is great to learn about functional programming and programming language theory in general. But to get things done, it's just not as practical.

it's pretty practical if you're building line-of-business apps, web servers, or other things you would use java for.

Yes, miss one character in a thing that looks like HTML but is actually a gigantic function call, get an incomprehensible failure message about how the meta-template macro expansion has an error.

macros/templates are usually confined to borders, databases, routes. not the business logic. Lisps are more susceptible to that.

Not even talking about business logic, just talking about page layout.

https://www.yesodweb.com

Yes, c# and Java do codegen for you too, in the same way. This is how templating in static languages work.

you should try modern erlang. If you try really hard, you can get both the advanced abstract concepts plus obscure machine specific optimizations.

I'd encourage you to look into Kotlin. It's got the 20% of FP features that give 80% of the benefits, while still having generics and a thriving ecosystem (JVM). As someone with a similar personal trajectory, it really hits the sweet spot.

I'm sorry, but it just sounds like you're a terrible functional programmer. There are basic software engineering principles you need to use when using a functional language, just like any other programming language.

Think you should tone it down a little, whether or not I agree

Reply on news.ycombinator.com