> nowadays every 16-year-old web-dev reaches for Array.map(x => <div>{x}</div>) when they write their pages in the most popular framework. These higher-order functions have now become part of the “hello world”
It's just wrong to ascribe the popularisation of HOFs like `map` to Haskell. `map` was there in good old (practical) Lisp 1.5 back in the 1960s. Why ascribe this to Haskell (released 1990) rather than Lisp? Guido said Python v1 (1994) got HOFs "courtesy of (I believe) a Lisp hacker who missed them"[1], Ruby had blocks in V1 (1995). Haskell's research direction was not about very, very old news like HOFs, it was about non-strict evaluation, and cool type system stuff.
I would assume that most of the popular high-order functions came from the lisp world; 16 year web devs are using Javascript which took more than a bit of inspiration from the lisps.
That said, to really squeeze the most out of HOFs the language probably needs a well developed type system. I've noticed with untyped code that at some point HOFs start becoming hard to write because the layers of abstraction get confusing in a way that static analysis would be helpful with. Although my lesson there is to not go overboard with HOFs - if I need static analysis to write working code it is probably too clever to understand by reading it! The Haskell community might succeed in proving that view wrong, but until then...
> I've noticed with untyped code that at some point HOFs start becoming hard to write because the layers of abstraction get confusing […]
I have the same with Nix (from NixOS).
It’s a really nice idea to have a functional language that compiles to a working linux installation, but those abstract functions can get really complicated, especially when I return to something I wrote six months ago.
The issue with Haskell is that it doesn’t live up to the promise.
The promise is that you learn this difficult language and you gain a higher-level, cerebral understanding of software, and the type system protects you from bugs.
The reality is that you realize that this language was designed by a merry bunch of category theorists who had little interest in software engineering. The effort put into different parts of the language is super unbalanced. GHC is an impressive feat of compiler engineering. But the other tooling is poor, and so is support for basic features such as records.
Whatever extra bugs are caught by Haskell’s elaborate type system that wouldn’t be caught by a simple type system like Java’s, are replaced by bugs introduced by laziness.
Jazz is a bit different. Non-musicians generally don’t enjoy it. The more knowledge you have of Jazz the more you appreciate it.
> The reality is that you realize that this language was designed by a merry bunch of category theorists who had little interest in software engineering. The effort put into different parts of the language is super unbalanced. GHC is an impressive feat of compiler engineering. But the other tooling is poor, and so is support for basic features such as records.
> Whatever extra bugs are caught by Haskell’s elaborate type system that wouldn’t be caught by a simple type system like Java’s, are replaced by bugs introduced by laziness.
I think you're simply wrong. I've been writing software professionally for almost 30 years: say what you will about Haskell's weaknesses, I've consistently found it to provide a better _software engineering_ experience than most other languages I've used. The only thing I think comes close is Erlang/Elixir, and even then I miss the sophistication of Haskell's type system all the time--the ability to make a change one place and have the type checker tell me so much about where else I need to make corresponding changes is invaluable.
Feeling constrained in what I can express because the type system forbids it almost always leads me to realize a logical fallacy in how I've been considering a given piece of code. And yes, Haskell records are bad in a lot of ways, but it still isn't enough to make me throw the baby out with the bathwater, and the existence and utility of row polymorphism in PureScript in my mind dismisses the notion that this has something to do with the type system.
In fact I think this article is frustrating and off base because I value Haskell so much for its ability to help me write useful, maintainable code; I don't care about esoteric extensions or type-level programming other than how much it enables me to solve problems.
I don't get why so many people have the attitude about Haskell that you do. I think a lot of people bounce off of it but this is not the same as asserting that it doesn't live up to the promise--it does, and then some, as far as I'm concerned.
Also, it's worth watching a bit of this talk (link at a particularly relevant time to start) because while Haskell is an "ivory-tower language," it is not _just_ an ivory tower language, and the people working on it are very much not just "a merry bunch of category theorists who had little interest in software engineering."
Talk is cheap. Haskell has an endemic problem where way too many development resources are put into fringe parts of GHC and way too little is put on other tooling: package management, debugging/profiling, editor support, etc. It’s like, guys GHC has enough Template Haskell features please work on the basics.
Haskell has the worst support for records of all its peers. SML, OCaml, F# all have better records.
Without good records it’s unreasonably hard to write large software projects. Just look at any Java code, what’s it full of? class declarations. What’s C code full of? struct declarations. What’s JS code full of? object literals. Structures are a critical part of any programming language. A significant part of all code involves declaring structure types and marshaling things in and out of structures.
One of the issues is that Haskell added a lot of type system features without thinking how they’d interact with records. AFAIK it’s hard to retrofit ML-style structural subtyped records onto Haskell, because the type system is designed around that not being possible. But they could still have much better nominal records.
I love Haskell, it’s frustratingly close to being a great language, but it needs a push to prioritize developer experience.
> Haskell has an endemic problem where way too many development resources are put into fringe parts of GHC
There has been an incredible amount of work over the last decade put into all the things you mentioned, which it sounds like you're unfamiliar with. https://github.com/haskell/haskell-language-server in particular is a pleasure to use in my experience. Package management is far from perfect, but it's always being worked on and I'll take it over anything in Python or the Node.js ecosystems any day. Developer experience has improved a lot since I started using the language and this is an area that the community and leadership absolutely cares about--I'd be surprised if anyone spent time reading relevant discussions in https://github.com/ghc-proposals/ghc-proposals or https://discourse.haskell.org/ or etc. and agreed with you.
> Haskell has the worst support for records of all its peers. SML, OCaml, F# all have better records.
> Without good records it’s unreasonably hard to write large software projects.
> AFAIK it’s hard to retrofit ML-style structural subtyped records onto Haskell, because the type system is designed around that not being possible.
Haskell is not ML, and while Haskell records are weak they are not what is preventing people from writing big projects in Haskell. There is much more to the language than records. But I said this in my previous comment.
Nothing you've written resonates with me, and I've written Haskell and PureScript professionally as well as Java and JS along with a bunch of other languages that haven't been mentioned. I'm also actively working on an open source project in my spare time with thousands of lines of Haskell and PureScript code (https://github.com/ddellacosta/automation-service), not to mention a half dozen other random half-done projects and contributions I've made to other open source libraries and applications. What have you written in Haskell that has made you dislike it so much?
How many major open source applications are built on Haskell? How many Trillion dollar tech firms have core infrastructure written in Haskell? How many average conglomerates use Haskell?
I feel pretty confident that Haskell is generally unpopular and so would be poorly represented in any of the statistics you asked about, but you can take a look at the SPJ talk in my other comment if you want some seven-year-old numbers--I suspect its status hasn't changed substantially since that talk though.
Regardless, this has nothing to do with what I wrote in the comment you were responding to, so I'm not sure what your point is in raising these questions.
My theory on Jazz is that it is the coffee palette cleanser for people who work too much with regular music patterns. The appeal is that it is not appealing
That's a bit reductive. Jazz covers a lot of ground from Dave Brubeck[0] to Sons of Kemet[1] to Mopo[2] to Hiromi[3]. There's very different reasons to find each of them appealing.
My experience is the exact opposite. I like jazz because it engages my brain, but it can be fatiguing. (One does not simply not count while enjoying Take Five!) Hit me with a standard 12 bar blues, or even a four-on-the-floor pop anthem, and we'll be back in business!
What bugs are introduced by laziness? I have been using haskell for years and never seen a bug due to laziness, I don't even see how it can happen. Only excessive memory usage in rare cases but that is usually quickly resolved.
Just mix nontrivial data structures with algorithms that iterate until numerical convergence. Team of experienced devs fought space leaks for weeks, project schedule crashed, directly caused by Haskell's lazy eval. Management and customers angry. Good times, good times.
Sorry to be "that Haskell guy", but this kind of space leak is a solved problem. I call the technique that solves it "make invalid laziness unrepresentable"[1]. That doesn't mean it's a trivial effort to apply the technique to everywhere in your codebase that needs it, it doesn't mean that every library you use will have applied the technique[2], but it does mean it's a solved issue with a fix that follows from best practices. Space leaks don't take the insight of gurus to fix.
With all due respect. That is not a bug. That's like saying python slowness is a bug or that you can write undefined things in C is a bug. It's just the way the language works. Besides in the worst case you slap `StrictData` on the relevant modules. In the worst of the worst case you disable laziness altogether with `Strict` for the relevant modules. Frankly if an entire team of professional haskell devs are chasing a space leak for weeks then something is going very wrong and it's not the use of Haskell.
Great! If you had such a special use case that you'd use hyper specialized programming language for numerics like Julia to solve why choose haskell at all? This confirms there was something very wrong in that development team. It's like having to write a web application and choosing CUDA.
For routine fast numerical algorithm dev, Julia is like a modern c++ or fortran. Hyperspecialilzed isn't the right adjective here.
Our team's big mistake was believing blog posts that swept laziness problems under the rug. In hindsight, there's plenty of criticism about Haskell's laziness in complex apps, and we should have taken that criticism more much seriously.
> Our team's big mistake was believing blog posts that swept laziness problems under the rug
I linked a blog post[1]. I wouldn't say it sweeps anything under the rug. In fact it takes laziness out from under the rug and shows you exactly how to deal with it. If you think that approach wouldn't have solved your problem then perhaps you could elaborate why.
We had lots of legacy subcomponents that permeated throughout the app's data structures, and as a practical matter, we couldn't reopen all that existing code. Some of that legacy code crossed organizational boundaries, so eliminating laziness throughout simply wasn't do-able.
So given all the above, there are two reasonable conclusions, which aren't contradictory:
1) If we could have reworked lots of existing code, we could have eliminated space leaks via @tome's approach.
2) Haskell's laziness is fundamentally misaligned with projects like ours, which has cross-organization code, long-running iterative algorithms, and complex data structures.
In desperation we used deepseq, which everyone knows is bad, and shortly thereafter we cut our losses by switching platforms.
Thanks! Although I'd be interested in debating the topic at length (and I also have a longstanding offer to resolve anyone's space leak problems) I don't want to be That Haskell Guy^{TM} who won't let the topic go, so I'll leave it up to you whether you want to continue the debate. I will say however, that this most recent comment is significantly less pessimistic than your original one (https://news.ycombinator.com/item?id=41170695) and I don't think I disagree with it (except if it subtly implies that Haskell must use laziness everywhere -- that's not true!).
I'm reluctant to pick holes in what you describe because I know that I'm not getting a full picture and you have much more context than me, but with that disclaimer out of the way, I think I disagree fully with the details (despite, I think, agreeing with the broad picture).
Firstly, I disagree that laziness vs strictness is an engineering trade off. There are not domains where a strict language is the best fit and others where a lazy language is the best fit. That's like saying there are domains where indentation sensitive languages are the best fit and others where languages that use braces are the best fit. Laziness, like indentation sensitivity, has some syntactic and semantic consequences and you just have to use it accordingly. Laziness, like indentation sensitivity, has costs and benefits, but there is no cost/benefit trade off! It's just a fairly arbitrary choice. It is a not a factor "when choosing a platform". There are no platforms where strictness is the best choice and no platforms where laziness is the best choice!
Now, I appreciate that the Haskell community has not produced enough educational material and tooling for many users to feel fully comfortable with the correct style for avoiding space leaks. That is a somewhat different issue that the one you raised. However, once one does know those techniques, space leaks are basically a non-issue. I take the point that rewriting your application in Julia resolved the problem, but I find that hard to reconcile with the following:
> We had lots of legacy subcomponents that permeated throughout the app's data structures, and as a practical matter, we couldn't reopen all that existing code
If you could rewrite in Julia, surely you could also rewrite in Haskell and avoid all that legacy.
The advice I'd give anyone struggling with space leaks today is to use the th-deepstrict[1] package to discover which of their long lived data types has been specified to allow space leaks, and then plug those leaks as explain in my article[2]. Easy.
"But I shouldn't have to make an extra effort to avoid laziness!". I agree! I think strict data would be the correct default (but lazy function arguments). But also, in Python I shouldn't have to take extra care with scopes when creating lambdas, in Java I shouldn't have to deal with nullable object references, in X I shouldn't have to deal with Y. I agree! In the real world we just learn the ways of coping and get on with it. Haskell's laziness is a less severe impediment than either of the above issues, in my opinion.
> SPJ's hair shirt presentation: "The next Haskell will be strict."
Meh, this comes up a bunch because SPJ said it, but he only said it once and never again. It's not clear he really believes it. PureScript is basically "strict Haskell" and Haskellers aren't flocking to it because of that. You win something by moving to a strict language, and you also lose a lot.
It's great you found something that worked for you. For the spectators I think it's also worth reiterating that putting strictness annotations in data definitions that you didn't want to be lazy would also have solved it, just as rowanG077 suggested.
You definitely gain a deeper understanding of software if you follow through. Of course, if you only do the learnyouahaskell.com tutorial there will not be much in there that couldn't be done in other languages. The real insights are not in the language itself (except for laziness and some other cool bits like levity polymorphism) but in the ecosystem of libraries and blogs.
As for the type system preventing you from bugs, I agree that it doesn't really live up to the promise.
This is kind of the thing that's stopping me from learning Haskell. My first language is javascript and my fluent language is python. And, I just can't see really getting any work done quickly, fastly, and efficiently not in either of these languages.
Even though I am studying category theory right now I feel I have so little incentive to learn Haskell because I don't think I'll ever use it except with category theory. And I get that category theory is kind of like native to Haskell but I could still explore those concepts in a lisp but that compiles to Javascript or something.
My concrete example is the Haskell Web framework IHP. I tried to get it working on my windows machine for two days and couldn't get anything smooth to work. Granted I have rsi and cannot use my hands as much as the next developer. However, when new frameworks like fastHTML pop up where everything is on one python file and immediately ready to go, It's really hard to convince myself to go through the trouble and pain to get to the same spot with Haskell as I can with another language immediately.
Learning Haskell was very useful to me, not because I became a Haskell programmer, but because it made me a much better Python programmer. Approach Haskell, not with the goal of becoming a productive Haskell programmer, but with the goal of getting immersed in a new way of thinking about programming and computation.
This is also why I recommend something completely different as your next language to learn - learning something completely different will open your mind and teach it to see patterns you previously had no idea existed, just because you couldn’t see them. Haskell is an enlightening experience not unlike your first Lisp.
I'm currently learning Haskell and some mathematics (proofs, logic, sets).
I think Haskell's great. I got over my hesitation to learn it by accepting that it's a useless language. I just treat it as an intellectual exercise.
Web programming is very important and useful. Haskell is ill suited for it and it's ecosystem around it is very weak. You make a great point comparing it's experience with other options.
Post admitting Haskell's uselessness, I would put web programming towards the end, on a tier list of things to do with Haskell. If one of the goal is having a fun experience.
Laziness in Haskell is so hard for me to understand. I never have any idea what the runtime performance of something I write in Haskell will be. It's either blazingly fast or molasses slow, and I can never tell.
Avoid String, use Text or ByteString. Avoid [] for data processing, prefer Vector. Avoid lazy IO, use Conduit (or similar). Prefer newtype to data, and make data fields strict where appropriate. Make sure you're building with -O2 (has to be explicit, none of the tooling enables it by default).
These rules cut out 99% of space leaks. The profiling tools are a big help for the last 1%.
This article is just about Haskell. Jazz and pure math are far from hated. Even if many people can't play jazz, they can enjoy it. And let's be honest, nobody even knows what pure math is. Ask anyone who hasn't actually done pure math, and they will have no idea what pure math is. I know because I am a pure mathematician, and I've never met a single person who knows what pure mathematicians actually do.
Actually, let's be honest, there is hardly a soul that knows what Haskell is either. So hate is not really a great word for this title, nor is the use of jazz and pure math.
During my postgrad years in logic I eventually started describing pure maths as a journey into priesthood. It seemed to be a more relatable analogy for non-maths people - and put a stop to the incessant question of utility that pure mathematicians everywhere have to spin stories around! =P
That is exactly what a person in 1500s would have said about e.g. imaginary number. In fact, this was the opinion on that at the time.
> it was Rafael Bombelli who first set down the rules for multiplication of complex numbers in 1572. The concept had appeared in print earlier, such as in work by Gerolamo Cardano. At the time, imaginary numbers and negative numbers were poorly understood and were regarded by some as fictitious or useless, much as zero once was.
I absolutely agree. People who make that argument are either kidding themselves or looking for funding haha. Everyone I knew in my department was there because they liked it (or because they liked teaching and had to produce papers as part of the job), not because they had ambitions of solving practical problems.
I think pure math is simply not applied math - so math that is not being done in direct service of a particular goal, such as working out insurance pricing or perhaps ML/AI etc.
So it's essentially about who pays you. Seems fairly clear to me.
What I meant was what it is as a practice, not how it is used. "Applied vs pure" anything could be defined as such and it's not particularly helpful, beyond showing you have a basic grasp of English.
Not really, because many disciplines are inherently applied. There is, for example, no such thing as "pure teaching", since teaching is always practical.
To me the lack of a practical purpose at the moment is the defining characteristic.
As a math major, programmer and musical snob (I do hate jazz though) I figured that there are people who love complexity and nuance and their brain lights up with sense of awe getting into Haskell, jazz, and pure math. And there are people who (1) do not necessarily enjoy complexity and nuance that much and just want to get the job done and (2) hate us, pesky snobs (we can be pretty annoying).
Much real-world software development is pretty complex, but experienced developers understands complexity is the beast to be tamed, not a goal to be achieved.
Haskell fans seem to delight in making simple problems complex rather than complex problems simple.
> Haskell fans seem to delight in making simple problem complex rather than complex problems simple.
That’s a reductive way of talking about a group of people. Is that from your personal experience with Haskell fans?
My personal experience with Haskell fans doesn’t match that at all. The Haskell fans I meet tend to be reasonably pragmatic, but care more about correctness. There are some who do research, but they acknowledge that research doesn’t always yield practical advancements. The Haskell fans I know will acknowledge that Haskell is not most people’s first choice for a language, and that one of the main benefits of Haskell is to yield insights that can be ported to other languages.
You also get a different section of programmers on HN and Reddit. You might think of Rust users as annoying evangelists, if you base your assessment on HN comments. My interactions with Rust users in-person differs wildly from interactions online.
- "Haskell fans seem to delight in making simple problems complex rather than complex problems simple."
Could be an observational bias. I think the silent majority are quietly using the simple, easy parts of Haskell to solve problems in simple ways, and aren't tweeting about it. Because it's boring.
To continue the jazz comparison, I guess this would be the competent jazz trio knocking out by the book jazz standards in the corner of a bar. They'll probably never make it big or become famous, and most people will forget about them quickly enough, but they'll have a steady stream of gigs and just about everybody there will be happy enough listening to them in the background and have a good time.
Cabal has never treated me poorly, though broken packages do happen (usually due to unnecessarily restrictive upper version bounds on libraries - unpack and fix the .cabal, add directory as extra-dep, move on with your day).
For the last long while, though, Stackage (versioned repository of packages that build together under a fixed computer version) and stack fix this problem. It's one of the things I miss when I use other packages/build managers from other languages.
Joking aside, 80% of the benefit of functional programming in practice, in my experience, comes from referential transparency, expression-based programming, and sum types. It's even fine to allow for procedural code inside of these referentially transparent functions. The effects these features have on program structure, logic flow, and data structures are profound enough that the benefit of IO monads and other more pure features have diminishing returns for the extra elbow grease that needs to be put in. It's also fine to break the rules in a number of cases you can hopefully count on one hand; stateful code needs to be isolated and well-understood.
> Joking aside, 80% of the benefit of functional programming in practice, in my experience, comes from referential transparency, expression-based programming, and sum types.
It's an interesting mix that you picked.
Rust shows that sum types are useful even outside of functional programming.
Just like Java (and others) have shown that garbage collection is useful even outside of functional programming; but functional programming was where GC was 'born'. Just like functional programming was where sum types were 'born'.
Incidentally, garbage collection was born with Lisp. And Lisp is arguably a functional programming language (or family of languages), that for the longest time didn't have sum types.
What we call functional programming is a grab bag of features and absence of some other features, but the exact contents vary over the decades. Even C++ got closures these days.. and that's how progress looks like!
Sorry, I take GC/RC as a given these days, but yes, the effect this alone has (not needing to write any memory semantic code the vast majority of the time) is revelatory. Especially for any language that compiles to a native executable. Huge performance for very easy-to-write and -maintain code.
Oh, I agree. It's progress! Any new language these days either has to have automatic memory management (GC or RC), or have a good story for why what they are doing instead is different and worthwhile (like Rust). Or as a third possibility, your new language will get mercilessly mocked.
We see similar developments for closures and support for first class functions in general.
And my sincere hope is that in the future, other features like sum-types and pattern matching over them will go the same way.
The functional programming community pioneered many of these features; but those features aren't restricted to that small corner of our industry.
I hope that relations-as-datatypes will see widespread use in the future. SQL shows that relations are good for expressing business logic, and I used them in a Haskell dialect as an internal datatype (unconnected from any database), and the experience was great.
There's no reason Python etc couldn't host relations as datatypes, the same way they already host dicts.
Yes! This is the real win of functional over imperative languages. It means you can understand blocks of code in isolation and then compose them into larger blocks. Bottom-up programming. This is what is missing from the imperative paradigm, and why that approach struggles to scale with problem complexity.
So very underrated. My program structure for years now has essentially been pyramids made of Lego-stacked functions, and I use value-returning syntactic features as often as I can.
One should write non-functional code so that it's understandable in small blocks. On the other hand, I've seen some undecidable functional code also in small quantities. Mapping arrays of tuples containing functions from strings to integers with no apparent connection to business logic.
Nevertheless, I'd take a functional language over procedural any day. The horror of mutable memeber variables changing all over their class is real.
I have personally seen production code consisting of C and PHP programs with GLOBAL shared state bounced back and forth between dozens of functions simultaneously, where the parameters reflect only a fraction of the actual input data to the functions' procedures. Expressions and airtight design may seem normal to you, but older generations of programmers either had little exposure to philosophical musings on the constitution of good software design, or received roundly awful early wisdom from the industry's nascence. Of course, C has a habit of enforcing essentially no rules on program design, so it was a wild world of scattershot practices (or anti-practices).
I benefit from functional programming without sum types in Elixir.
You also failed to mention immutability. Immutability permits trivial concurrency without requiring mutex lock semantics. I'd call that a massive benefit, especially considering how much load a Phoenix server can handle.
Referentially transparent functions naturally have immutable inputs and outputs, so that's implicit. But it's often useful to be able to write mutation-based algorithms within a function, so in that context I'm less concerned, so long as the size and scope of the function is constrained.
> But it's often useful to be able to write mutation-based algorithms within a function
I know. Quicksort comes to mind. But you then lose a guarantee. Might not make a difference practically, though (which presumably is what Rust's design banks on).
I don't think the starting premise of the article holds at all. Both jazz and Haskell are hugely popular, by listener and practitioner, and user count respectively they've probably never seen better days. Pure math I wouldn't say is really hated either, but it's rather pretty irrelevant for most people. Even in software development, I would say it's pretty rare that you actually need advanced math in your day to day work.
Sometimes I wonder if my late-in-life recent appreciation for maths* be just a symptom of having failed to die {in a bizarre gardening accident, driving off Skyline Blvd} while my body could still handle following the childish dream of hex, bugs, and rock&roll.
"Haskell? I was into those guys before they were cool. Miranda, man, that even had diagonal comprehensions... Have you heard of Hope? Kiff this, mec..."
That video must've been shot around this time of year? Google Maps shows Greenhills as being distinctly brown[0], and while we hit the low 30s here recently (the combines have been out in force on the wheat fields) I suppose you all have a good six months yet before your season.
[0] a landscape of "olive and gold" if we wish to wax poetic?
[1] the iron sights on my wife's ca.1900 service rifle can in principle be adjusted out well past 1 km but I strongly suspect that was only meant for volley fire?
We were raised (farm shooting) to think 600 yard head shots were adequate and good was north of there. Our father was in Navy after being a farm boy and routinely won inter service 'friendlies' ( AU v US v UK v etc.) so that was probably a high 'low bar' in hindsight.
Wow, there are over 20 other villages in a 4'593 m radius from here, so I guess I'll be leaving such ultras for those who have the space to see the vision splendid of the sunlit plains extended.
> they seem to be caught up in silly exercises just to show off to other nerds.
Jazz musicians literally so, and to a much more insidious degree than Haskellers or mathematicians.
That is-- jazz musicians fall prey to the tendency to fill time with content pulled directly from the exercises they used to gain proficiency on their instrument. These can be simple iterations that step through a sequence of pitches, enumerating through the degrees of the pentatonic scale, compulsively sequencing through patterns in an octatonic scale, etc.
Worse, this tendency can strike old timers just as easily as newcomers. Coltrane famously began to normalize his improvised lines to patterns he'd practice that were straight out of Slonimsky's book of exercise patterns.
To get a sense of how annoying this can be even to jazz insiders-- imagine a math paper written by five researches. They read the paper aloud at a conference, and when one of them gets to the summation symbol, they immediately explain to the audience:
"So for example, here you'd add one, two, three, four, five, six, seven, eight, nine, and so forth..."
As each researcher reads their section of the paper, they do this, incessantly, for every symbol that can possibly be explained with sequences of numbers.
The thing about everyone hating jazz feels more meme than reality; I don’t think most people mind it, and of course virtually all modern music is in some way a _descendant_ of jazz. It’s not the most popular style of music today, but, well, it’s _old_; it’d be kind of weird if it was.
The thing about everyone hating jazz feels more meme than reality
Yea, there's a reason why people like lounge pianists will often play jazz standards if they just want to create some pleasant background 'noise' and don't really want to draw attention to themselves. If a bar quietly has a "Best of Generic Jazz" playlist on, they're probably not driving away many customers. (Some) jazz is on the whole [1] probably one of the most inoffensive and generally accepted genre of music around.
[1] Yes, I know that there is plenty of jazz that isn't like this. And this is where the music nerds can get into their what is 'real jazz' arguments
I really didn't like Jazz for the longest time. Many of my friends felt the same way.
I had one friend who was musically gifted who loved it.
I really think Jazz is something that you have pay fairly close attention to in order to enjoy it. Or at least have a long term relationship with music. It usually has too many moving parts for most people to causally enjoy.
Of course, Jazz is such a large body of art, there are major exceptions to that generalization.
I don't like imperative languages trying to do functional programming. Especially Javascript. It's just pain to debug a `.filter().map().reduce()` chain, you have to create a separate variable every time you want to insert a `console.log` there somewhere to figure it out.
Also I don't like functional programming eating away the performance. You can sure write 3 O(n) loops easily, but you can't see the instant wins to optimize it the same way you can with imperative programming. Maybe the third loop wanted to reuse something that could be found in the first loop? With imperative programming: Great, put it in a variable outside of the first loop, and fill it. With functional programming: Change all the types in the loops to fit this new variable, and remember to return it through all these functions.
EDIT:
Also as jordigh pointed out here https://news.ycombinator.com/item?id=41160794 I don't like how functional programming obfuscates performance a bit. With imperative languages what you code is what you get. Functional languages do so much more behind the scenes, that it's hard to figure it out some times.
Functional programming as in map-filter-reduce? Lisp.
Functional programming as in "strong static typing and algebraic data types"? ML.
I try not to begrudge anyone their enjoyment of anything, and I like jazz, for the record. It's good that we have a language for people who want to do Haskell-y things, and y'know, Pandoc is nice.
But this blog had an opportunity to make the case that Haskell innovations are trickling down into mere programming languages for squares (for the squares out there, if you don't like jazz, you're a square), and they offered two things which don't come from Haskell.
So I put it to you, Hacker News: what did the author miss? Where are the great Haskell innovations us mere programmers now benefit from?
I just wish I could get people to pay me to write it.
I've had the same issue with Elm, although I've actually shipped a number of projects written in Elm since it can be easier to integrate.
The crux of my issue is that I often write software which will be passed onto others for maintenance. Nobody is interested in taking ownership of projects written in esoteric languages. As the old saying goes, no one ever got fired for choosing Python.
Those interested in a (much, much) simpler alternative to Haskell that catches a lot of bugs during compile time might want to look at Gleam [1]. It has excellent tooling with great developer experience and a growing community.
It is a bit like a high level version of Rust, targeted at building web applications, handling concurrency by replacing the borrow checker with Erlang's processes – since it runs in the Erlang's virtual machine.
It's hard to take too much issue with the general argument. Seems like there are loads of examples of theories developed out of "pure" intellectual pursuits that found practical applications later on.
But I quibble with the broad inclusion of "jazz" in the list. I don't really like the idea that jazz is this never-ending process of avant-garde musical boundary pushing. There are these cults of personality around artists like Miles Davis and Coltrane, and at some point people decided that "easy-listening", "smooth jazz", and "elevator music" were the nadir of "cool", but those particular cultural trends don't necessarily define jazz as a whole. It's also reasonable to regard jazz as having a matured musical vocabulary that we can construct accessible tunes out of without pushing boundaries all the time. I suspect a lot more people do enjoy "lounge" jazz than would admit it.
$(lang) is an older language with lots of existing code. New users hate using $(lang) because it has horrible build tools & a lackluster library ecosystem. There is resistance for fixing $(lang)'s issues because maintainers don't want to break compatibility.
Many languages fall into this tarpit and will never escape.
I suppose I am the target of this argument, but I would not phrase my dislike of these things in this way.
I would instead say -
I dislike Haskell because when I tried this book http://web.archive.org/web/20190705205338/https://www.cs.yal... about 20 years ago I thought it had been written in an effort to impress upon the reader how smart anyone using Haskell was, at the expense of me getting anything done.
I like various forms of Jazz but I dislike a certain type of Jazz person who seems to be in to Jazz to let you know just how much better they are than you.
I don't think I've ever had anything but enjoyment and admiration for pure math and pure mathematicians.
as I recall it was considered a real good and important book in the Haskell community at the time, but obviously I had to try to delve through Haskell documentation to try to figure out why things weren't working.
>“Geometry is knowledge of the eternally existent,” (“Sacred Mathematics”). This quotation by Plato, an Ancient Greek philosopher, demonstrates the importance of geometry to the foundations of the universe.
To me that illustrates a depth to maths which is absent from Haskell and Jazz.
Also from Wikipedia:
>Evidence for more complex mathematics does not appear until around 3000 BC, when the Babylonians and Egyptians began using arithmetic, algebra, and geometry...
Learning Haskell has its challenges but once you stop thinking of time as a sequence of events and realise it’s actually a directed acyclic graph of causal nodes, everything becomes crystal clear.
Not all problems are well suited to graph theory though. Try implementing the super trivial Sieve of Eratosthenes as a DAG. No doubt it's possible, but I'm willing to bet the complexity of said solution is going to make it hard to read and understand.
Have spent too little time with Haskell, and am fairly indifferent to pure maths beyond forcible conversion to applied maths against pure mathematicians’ will - but I have an enduring love for jazz. It is freedom incarnate, and the most perfect musical metaphor for life yet known to me.
> Whitehead explains how Machael Faraday discovered the laws of induction between currents and magnets back in 1831-32. “What is the use of this discovery?” someone asked. “What’s the use of child—it grows to be a man,” he responded. To quote Whitehead, “Faraday’s child has grown to be a man and is now the basis of all the modern applications of electricity.”
There's a difference between working on something because it is interesting and fun, essentially "hacker mentality" and it turning into something special vs pure theory and it never having use. One tinkers with the world building things, the other just adds complexity to abstract ideas with no utility.
tl;dr Faraday was a tinkerer, pure theory are fiction world builders.
Because everything, including appreciation, is normally distributed. In this case these elements share a requirement for other qualities, which are also normally distributed. Most (in the middle of the distribution) will hate a puzzle that is too difficult and it will be discarded with disgust. Some (on the left of the distribution) do not understand that it is a puzzle. Yet others (on the right of the distribution) become fascinated and may choose to dwell with the difficult puzzle over a lifetime.
Not really true. Almost no one hates those three topics because in order to hate something you need to know it, and most people don't know those as they are impopular.
Popular music with 4 cords progressions, languages like python that people need or basic math are popular. People can hate python, or basic math or reggaeton because they are everywhere.
I am a Lisper and Haskell programmer myself(along other languages) and I can tell you the proportion of people that I know that know what Lisp is is a minority, like 1% of the general population. I would say 10-20% of the population knows what Fortran or C is.
"Their practicioners seem to be divorced from the real world. They don’t actually produce anything useful. Rather than working on practical things that everyone can enjoy, they seem to be caught up in silly exercises just to show off to other nerds."
That is right. Most people in the Haskell community are totally divorced from reality. I would say more, they are not interested in reality at all. Do not tell them about engines or User Interfaces or databases. Not interested at all. They also love Pure Math problems.
I don't see the problem with that. I see the problem when people that are not interested in reality want to rule reality like millionaire children's intellectuals(Engels and Marx, Trotsky, Lenin...) wanted to rule work without having worked in their entire lives.
I see a problem if someone that told me he is not interested in how the User Interface of my app(or any user interface btw) works is telling me that I have to rewrite it in Haskell because it is perfect in his mind.
I find Haskell ideas useful up to a level, but not further than that. While science comes from philosophy and philosophy comes from love to knowledge by itself, most people doing philosophy in the past was wealthy people whose wealth came from somewhere else, like commerce having a fertile land.
It's just wrong to ascribe the popularisation of HOFs like `map` to Haskell. `map` was there in good old (practical) Lisp 1.5 back in the 1960s. Why ascribe this to Haskell (released 1990) rather than Lisp? Guido said Python v1 (1994) got HOFs "courtesy of (I believe) a Lisp hacker who missed them"[1], Ruby had blocks in V1 (1995). Haskell's research direction was not about very, very old news like HOFs, it was about non-strict evaluation, and cool type system stuff.
[1] https://www.artima.com/weblogs/viewpost.jsp?thread=98196