7 ms·

This is wonderful, and correct, theory. As the Futurama joke goes, "you are technically correct; the best kind of correct." What the Haskell community keeps ru

by tyre 11y ago

This is wonderful, and correct, theory. As the Futurama joke goes, "you are technically correct; the best kind of correct." What the Haskell community keeps running into is that most people don't think in theories. Trying to prove the theory to be practical has a poor success rate. They need to implement useful things that people love, then show how the theory got them there naturally. Sentences like this: > Category theory codifies this compositional style into a design pattern, the category. To the average person, a theory codifying a style into a pattern just isn't useful. What does that do? Monads are a common joke to this effect. They are wonderfully useful but poorly understood by most developers. It isn't being right that matters if few understand you. Why was Rails successful? Sure Ruby is nice, but Python is very similar (and it wasn't the `do...end` blocks.) It's because Rails could be used to easily build functional CRUD apps — Whoops! it works — that made difficult easy. Sandy Metz doesn't get heard if DHH isn't building Basecamp. As a philosopher, it pains me to know people don't think that way, but if you aren't changing people's lives then all the theory is just mental masturbation.

huuu 11y ago
Some time ago there was a post about this (I can't find it). People don't understand what monads are because they don't know what problem they solve. This article has the same problem. It doesn't explain what problem categories solve. Well it does but the average reader doesn't understand the problem exists.
- agumonkey 11y ago
  It's like explaining Iterable interface out of the blue.
- mbrock 11y ago
  I think they also don't understand monads because they have confused notions about the kind of concept "monad" is on the meta level. Their criteria for understanding and their methods of learning are unsuitable for becoming competent with the use of algebraic concepts. They are trying to think their way to a type of "intuition" that simply is not possible, kind of like trying to learn to ride a bike by "understanding" bikes, comparing bikes to various other things, or spamming the internet with complaints about how bikes are strange and difficult. (What's the problem with just taking the bus?!) If Haskell's "Monad" type class were instead called "AbstractComputationFactory" or some other such intimidating technobabble, then when someone looks up what is the superclass of IO they might just think "oh, that's some weird detail, whatever, I might learn about that later." Since instead the name "Monad" is vaguely funny and appealing, people want to master that concept in principle before they even get "Hello, world!" to run in GHCi. Of course people are free to focus on whatever they want, and we can talk about the possibility of improving the pedagogical aspects of Haskell, and probably university teachers have interesting things to say about that. But there is no magic way to explain an algebraic concept that will suddenly make it intuitive and easy. If people want to understand them, they'll have to study. If people want to use them without understanding them on the conceptual level, that is eminently possible. I myself don't understand monads and I've been using Haskell since 2005. I'm just not good at abstract algebra (flunked that class) and PDFs terrify me. However, even though if a mathematician asked me to explain monads I would be embarrassed, I can still use them and even define my own. That's because I've tinkered with them and acquired a know-how feel for the structure and what they are good for and how the patterns work—which is exactly how I've learned every other concept in programming. Since most concepts in programming are ad-hoc, informal, and specified by hand waving, there is not even a possibility of understanding them at the level of mathematical rigor. What is an object? What is a class? Nobody knows. They just use them.
  - icebraining 11y ago
    More than people trying to learn Monads, I see people trying to teach them. Few people write introductory guides to the "AbstractComputationFactories" of other languages, but it seems like everyone who gets (or thinks they get) monads feels the need to write a guide on them. It's inevitable that newcomers to the language will stumble upon them early on.
    - mbrock 11y ago
      True enough. That has to do with the allure of jargon, I think. It's become a meme in itself. Nowadays on the Haskell subreddit, what I see most upvoted are tutorials that involve creating software that does something concrete. If that happens to involve a clever but not overwrought use of cool type system features, all the better. If anyone reading is yearning for some internet points, go write a Haskell tutorial that's useful, concise, and mostly shies away from the rabbit hole of abstract explanations. Even if it's merely about how to run a regexp or do a POST request.
- userbinator 11y ago
  People don't understand what monads are because they don't know what problem they solve. Or for that matter, the fact that it even is a problem, because it's easy to see that there are plenty of other programming languages with which people can do lots of productive things without ever thinking of the term "monad".
deleted 11y ago
[deleted]
cristianpascu 11y ago
Reading this article I had the same feeling I had when I was a physics student in math classes: Why the haskel do I need this? Like every time some abstract math concepts were introduced with no connection to reality whatsoever.
- bordercases 11y ago
  For me, learning mathematics is a way of priming my imagination with patterns and tools that may or may not be relevant, but with the qualification that almost everything can find use if you look hard enough. I'm curious and like to think so having a library of abstractions is always satisfying. Just sitting down to figure out how math can apply to some simple object of meditation is usually fruitful. You can get away speaking English with a relatively compact vocabulary. But reading broadly to enrich your vocabulary with new words and idioms allows you to describe events more fluidly, and perhaps in a way which inspires you into better ways of describing the same thing you could have described less poetry in the compact vocab set. In that way words let you change your perspective by affecting how you frame your sense-data. Mathematics is the same way. If you want to work in a variety of domains, you're going to have to be agnostic ahead of time as to what tools might be useful, which is to say, have many tools.
  - seanmcdirmid 11y ago
    You don't learn an English vocabulary by reading the dictionary, you read literature and see how those words are used in context. Learning in a vacuum is hard for all but the most abstract thinkers.
    - johncolanduoni 11y ago
      I don't think I've ever read a math book that just went "Here is a list of definitions and the statement of some theorems. Have fun!" The problem is that math is usually built on top of more math. So the motivating examples given are often examples in mathematics, just in a different area. For example, most category theory books talk a lot about the categories of abstract algebraic structures to get you an idea of what the things they're describing look like in "the wild." If you've never done any abstract algebra, it's like trying to use the Rosetta stone when you don't know Egyptian or Greek.
smadge 11y ago
> To the average person, a theory codifying a style into a pattern just isn't useful I think the average OO programmer recognizes the value of design patterns, eg the Gang of Four book.
- danieldk 11y ago
  Only after realising what 'problem' a pattern solves, perhaps by experiencing the problem over and over. I think this is why design patterns in OO are commonly abused (overused) - people learn about them without understanding the problem.
  - smadge 11y ago
    Sure, I agree. Novice programmers are not going to instantly understand what a category is, or how to utilize compositional programming without a bunch of experience and examples. However, I think for programming to progress we need to develop theory.
    - Swizec 11y ago
      The proof is in the pudding. You know why we have JavaScript? Because someone went and built it. Once it was built, it existed and people used it. All the theories about what a scripting language for the web should look like fell out the window the moment someone went and put one in their browser. De facto standards beat de jure standards. Every time. Theory is great. It makes for amazing and stimulating conversation. But in the real world the only thing that counts is building shit. PS: this is also why English is the global language of trade and not Esperanto. Even though English is both harder to learn, has a terrible "API", and inconsistent semantics and grammar and syntax. Esperanto is clean and well designed and and learnable in 150 hours and not used by anyone.
      - smadge 11y ago
        Well, presumably an advance will eventually provide a competitive advantage. For example, before the Copernican revolution, we had a model for the cosmos that made decent predictions. The heliocentric model actually made worse predictions for a long time until it was evolutionary improved. However, to the early scientists who adopted it, the heliocentric model "felt right." Maybe right now programming in a shitty language like javascript with no regard to program structure is better at "getting shit done" than programming in a functional language using universal abstractions like composition. To people who study and think about it, though, it "feels right." Perhaps if they stick with it and perfect the art, it will eventually provide such a competitive advantage that it will be universally adopted.
fsloth 11y ago
I terms of usability this seems to me up there with the set theoretic formulation of relational model. I.e. not as something everybody needs to do but offering an efficient descriptive model for complex systems. When designing programs or datastructures I prefer to use pen and paper and some simple set theoretic ad hoc notation system. I write code for production daily and without this higher level design model my code would be uk terrible shape and very slow to modify. "As a philosopher, it pains me to know people don't think that way, but if you aren't changing people's lives then all the theory is just mental masturbation." Basically really good programmers seem to see the optimal structure for a specific problem out of practice. I need to have some sort of theoretic framework which to use to compose my program logic. I've not had the time to look into category theory but this post succeeded in convincing me it's a practical mental tool to help in program composition. So, based on my personal preferences, I disagree this would not have practical benefits.
T-R 11y ago
The theory is for getting consistent/composable APIs, and trust in the code - trust that you can optimize it, parallelize it, or just that it behaves the way it's supposed to, without having to read every line of it. You don't need to think in theory to benefit from that. While it's certainly cute that I can `gem install` a CMS, the Ruby ecosystem is infamous for its magical, non-composable, monolithic frameworks. The functional ecosystems are working toward fixing the all-too-familiar problem where you have to either start over, or hack apart some giant stateful mess anytime your exact usecase hasn't already been built as a library. It's easy to throw a nice looking house together with Lincoln Logs, but I'd take Lego instead any day. Edit: Also, just because someone hasn't built the tallest building in your neighborhood yet doesn't mean they're not building anything. JP Morgan, Kapersky, Facebook, and IMVU are hiring Haskell devs, just off the top of my head.
- virtualwhys 11y ago
  Agreed on popularity of language/framework not being an indicator of success (wrt to software evolution), quite the opposite seems to happen in the mainstream. Worth noting that finance industry heavyweights such as JP Morgan and Standard Chartered (largest Haskell shop in the world) are laying off more than they're hiring these days[0][1], though unlikely this trend would directly affect tech hires (current batch of layoffs seem to be a trimming of management tier). On a somewhat related note: were Standard Chartered to open source their fork of GHC many Haskellers not sold on lazy-by-default would rejoice; from Scala side of the fence my interest in Haskell would increase 10X were that to happen, line numbered stack traces alone, who woulda "thunk" it ;-) Moving forward Haskell's probably going to continue to be pilfered of its theoretical gems by other languages that leap frog it in terms of adoption. Not a bad thing if we take SPJ's "avoid success at all costs" at face value. [0] http://www.bloomberg.com/news/articles/2015-05-28/jpmorgan-said-to-plan-thousands-of-job-cuts-as-bank-pares-costs http://www.bloomberg.com/news/articles/2015-05-28/jpmorgan-s... [1] http://www.bloomberg.com/news/articles/2015-07-20/standard-chartered-s-ceo-boosts-direct-control-in-overhaul http://www.bloomberg.com/news/articles/2015-07-20/standard-c...
  - tome 11y ago
    > Worth noting that finance industry heavyweights such as JP Morgan and Standard Chartered (largest Haskell shop in the world) are laying off more than they're hiring these days[0][1], though unlikely this trend would directly affect tech hires (current batch of layoffs seem to be a trimming of management tier). Indeed. Hiring of Haskellers continues apace at SC: https://twitter.com/donsbot/status/654630194519646208 https://twitter.com/donsbot/status/654630194519646208 > were Standard Chartered to open source their fork of GHC many Haskellers not sold on lazy-by-default would rejoice It's not a fork of GHC. It's an entirely new compiler, called Mu.
gaius 11y ago
Monads are a common joke to this effect. So much so that I wonder if the popular monad tutorial involving spacesuits and burritos wasn't actually made as a pisstake (but I am 99% sure the author was serious).
- danidiaz 11y ago
  You might be interested in the inverse burrito-monad tutorial: http://www.cs.cmu.edu/~edmo/silliness/burrito_monads.pdf http://www.cs.cmu.edu/~edmo/silliness/burrito_monads.pdf
mbrock 11y ago
Haskell isn't designed for "average people" or "most people" and why should it be? Real human beings use Haskell every day and love it. Real human beings are capable of learning about teh scary maths and abstract theories. You studied philosophy? Are you aware that most people don't understand anything about philosophical theories other than The Secret? Have you thought about how maybe those theories can change people's lives even though they're not aimed at a lowest common denominator? E.g. by being influential in the long run, and also by being intellectually stimulating to people who do bother to learn about it? Rails-style success is not the goal for Haskell. It is an explicit anti-goal: the motto is "avoid success at all costs." Terse and rude counterpoint to your thesis: Average people are lazy idiots and designing your language to appeal to them will result in a very popular incoherent mess, like Java and Ruby, and Dijkstra will make pointed remarks at you from his grave. http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
- Numberwang 11y ago
  So the goal is for Haskell to be the Ithkuil of the programming world? That's a noble idea. Knowing this also makes it easier for me to chose to avoid reading articles about it.
  - mbrock 11y ago
    No. The goal is to be useful in both research and industry by means of principled design based on mathematics and engineering. If that scares you, fine, you don't have to be interested in everything. If you think everything that's not designed to appeal to some notion of an "average programmer" is necessarily obfuscated and impossibly difficult, that's on you. Go ahead and avoid it.
    - Numberwang 11y ago
      That sure does sound like a yes, not a no.
      - stingraycharles 11y ago
david_ar 11y ago
Replace the word "theory" with "abstraction" or "interface" then. All the article is saying is that there's a bunch of common things (Unix pipes, function composition, procedure sequencing) that all follow a few simple rules (a "contract" if you like). This means you can reason about them together without having to think about the individual "implementation details".
porker 11y ago
> Sandy Metz doesn't get heard if DHH isn't building Basecamp. Eh? Are you saying Sandy Metz isn't good, and needs DHH to provide a platform? Disclosure: I have read POODR and am not sure what to make of it, as it's pragmatic but says the opposite of other OOP books I've read
avz 11y ago
> Why was Rails successful? I don't think Haskell aims for this kind of success. Abstractions can be useful and they can be beautiful. If your goal is to "easily build functional CRUD apps" you need the former. If you do research in computing science or would like to further your understanding or simply seek to appreciate the elegance and beauty in computation, you need the latter. Admittedly, the latter goals (except research) are self-directed (they may make you a better or at least a happier programmer) and they don't directly contribute value to your customers, so I understand why you just called them "mental masturbation". However, I strongly disagree with that label. There is a long-term value in learning and general self-improvement.
- mbrock 11y ago
  Unfortunately I don't know of much research in formalizing CRUD apps, but maybe it's out there. The long-term wish as I see it would be for us as an engineering discipline to develop a really clear understanding of the domain, enough to be able to build these CRUD apps in composable ways that can be reasoned about with clear language. Guiding vague questions might include: What is the essence of a CRUD app? How could you define a CRUD app in terms of sets, functions, and categories? What kinds of laws apply in the general CRUD domain? How can we statically verify correctness properties for real-world CRUD systems? That hope has nothing to do with mental masturbation and everything to do with wanting to concretely improve the state of civilization. And of course to reduce the amount of time spent making and debugging the same kind of thing over and over again.
  - catnaroek 11y ago
    I am by no means a researcher, but, as a programmer who writes said CRUD apps for a living, I can guarantee that I derive most of my understanding of a complex business domain from the structure of the relational database backing it. And what is a relational database? A (time-evolving) subcategory of the category of finite sets! Primitive types (as sets of values) and tables (as sets of primary key values) are objects. Fields (as functions of primary keys) are morphisms. Chained foreign key traversal is morphism composition. I find this way of reasoning incredibly powerful, because it tells me quickly what kind of transactions make sense in a business domain. Of course, this is contingent on the database being well designed. It is exactly the same as with Haskell types - if you can leverage the (type system) schema to encode interesting logical properties of your (problem) business domain, then (type checking) checking a query against the schema in itself becomes a lightweight form of formal verification. One thing that must be remarked, however, is that, sadly, SQL lacks analogues of sum and product types, that is, tables whose cardinality (number of rows) is the sum or product of the cardinalities of other tables. This addition would make SQL even more powerful, but it would require a move to a more category-theory-based foundation for databases. (The relational model is based on first-order logic.)
throwawayignt 11y ago
>> Category theory codifies this compositional style into a design pattern, the category. >To the average person, a theory codifying a style into a pattern just isn't useful But you don't mean "the average person", you mean "the average competent programmer." For example I'm not an "average person" and I don't understand the sentence you linked (the one I quote at the top of this comment.) It's just gobbledegook to me, the way a bit mask is to someone who doesn't know what bits are exactly, they're just, like, 1's and 0's in the computer right? You have to explain a lot before they would even understand what you're talking about. They might not know what a power of 2 has to do with anything. This is an analogy. It's the same - average competent programmers don't have this mental infrastructure. I and most competent programmers have no idea what a category is.
- omginternets 11y ago
  >I and most competent programmers have no idea what a category is. By your own admission, you have no idea whether or not category theory is useful to you. Take pride in your ignorance if you like, but at least don't claim to know what you're talking about in the same breath.
ecthiender 11y ago
This is utterly wrong. Theory is not any mental masturbation. On the contrary, theory helps in understanding a problem with sparkling clarity and often offers a general approach or solution to the problem. The above is a problem with people who thinks everything in the world is black and white; or they themselves don't understand theories, maybe even being right in the circle which theorizes theories day and night (read academic circles). The key is to understand that all of us theorize all the time. Being programmers, whenever we see a problem, we do try to approach it scientifically. Basing parts of the problem on already established knowledge (read theory). See what we are doing here? We are theorizing a problem. It may not be any formal theory but informal theory is still theory. The point is theory is not just intellectual mumbo jumbo, sure it stimulates few of us to the point of orgasm, but theory is a very humble practice which helps us understand things better.

by tyre 11y ago

huuu 11y ago

Some time ago there was a post about this (I can't find it). People don't understand what monads are because they don't know what problem they solve. This article has the same problem. It doesn't explain what problem categories solve. Well it does but the average reader doesn't understand the problem exists.

agumonkey 11y ago
It's like explaining Iterable interface out of the blue.
mbrock 11y ago
I think they also don't understand monads because they have confused notions about the kind of concept "monad" is on the meta level. Their criteria for understanding and their methods of learning are unsuitable for becoming competent with the use of algebraic concepts. They are trying to think their way to a type of "intuition" that simply is not possible, kind of like trying to learn to ride a bike by "understanding" bikes, comparing bikes to various other things, or spamming the internet with complaints about how bikes are strange and difficult. (What's the problem with just taking the bus?!) If Haskell's "Monad" type class were instead called "AbstractComputationFactory" or some other such intimidating technobabble, then when someone looks up what is the superclass of IO they might just think "oh, that's some weird detail, whatever, I might learn about that later." Since instead the name "Monad" is vaguely funny and appealing, people want to master that concept in principle before they even get "Hello, world!" to run in GHCi. Of course people are free to focus on whatever they want, and we can talk about the possibility of improving the pedagogical aspects of Haskell, and probably university teachers have interesting things to say about that. But there is no magic way to explain an algebraic concept that will suddenly make it intuitive and easy. If people want to understand them, they'll have to study. If people want to use them without understanding them on the conceptual level, that is eminently possible. I myself don't understand monads and I've been using Haskell since 2005. I'm just not good at abstract algebra (flunked that class) and PDFs terrify me. However, even though if a mathematician asked me to explain monads I would be embarrassed, I can still use them and even define my own. That's because I've tinkered with them and acquired a know-how feel for the structure and what they are good for and how the patterns work—which is exactly how I've learned every other concept in programming. Since most concepts in programming are ad-hoc, informal, and specified by hand waving, there is not even a possibility of understanding them at the level of mathematical rigor. What is an object? What is a class? Nobody knows. They just use them.
- icebraining 11y ago
  More than people trying to learn Monads, I see people trying to teach them. Few people write introductory guides to the "AbstractComputationFactories" of other languages, but it seems like everyone who gets (or thinks they get) monads feels the need to write a guide on them. It's inevitable that newcomers to the language will stumble upon them early on.
  - mbrock 11y ago
    True enough. That has to do with the allure of jargon, I think. It's become a meme in itself. Nowadays on the Haskell subreddit, what I see most upvoted are tutorials that involve creating software that does something concrete. If that happens to involve a clever but not overwrought use of cool type system features, all the better. If anyone reading is yearning for some internet points, go write a Haskell tutorial that's useful, concise, and mostly shies away from the rabbit hole of abstract explanations. Even if it's merely about how to run a regexp or do a POST request.
userbinator 11y ago
People don't understand what monads are because they don't know what problem they solve. Or for that matter, the fact that it even is a problem, because it's easy to see that there are plenty of other programming languages with which people can do lots of productive things without ever thinking of the term "monad".

deleted 11y ago

[deleted]

cristianpascu 11y ago

Reading this article I had the same feeling I had when I was a physics student in math classes: Why the haskel do I need this? Like every time some abstract math concepts were introduced with no connection to reality whatsoever.

bordercases 11y ago
For me, learning mathematics is a way of priming my imagination with patterns and tools that may or may not be relevant, but with the qualification that almost everything can find use if you look hard enough. I'm curious and like to think so having a library of abstractions is always satisfying. Just sitting down to figure out how math can apply to some simple object of meditation is usually fruitful. You can get away speaking English with a relatively compact vocabulary. But reading broadly to enrich your vocabulary with new words and idioms allows you to describe events more fluidly, and perhaps in a way which inspires you into better ways of describing the same thing you could have described less poetry in the compact vocab set. In that way words let you change your perspective by affecting how you frame your sense-data. Mathematics is the same way. If you want to work in a variety of domains, you're going to have to be agnostic ahead of time as to what tools might be useful, which is to say, have many tools.
- seanmcdirmid 11y ago
  You don't learn an English vocabulary by reading the dictionary, you read literature and see how those words are used in context. Learning in a vacuum is hard for all but the most abstract thinkers.
  - johncolanduoni 11y ago
    I don't think I've ever read a math book that just went "Here is a list of definitions and the statement of some theorems. Have fun!" The problem is that math is usually built on top of more math. So the motivating examples given are often examples in mathematics, just in a different area. For example, most category theory books talk a lot about the categories of abstract algebraic structures to get you an idea of what the things they're describing look like in "the wild." If you've never done any abstract algebra, it's like trying to use the Rosetta stone when you don't know Egyptian or Greek.

smadge 11y ago

> To the average person, a theory codifying a style into a pattern just isn't useful I think the average OO programmer recognizes the value of design patterns, eg the Gang of Four book.

danieldk 11y ago
Only after realising what 'problem' a pattern solves, perhaps by experiencing the problem over and over. I think this is why design patterns in OO are commonly abused (overused) - people learn about them without understanding the problem.
- smadge 11y ago
  Sure, I agree. Novice programmers are not going to instantly understand what a category is, or how to utilize compositional programming without a bunch of experience and examples. However, I think for programming to progress we need to develop theory.
  - Swizec 11y ago
    The proof is in the pudding. You know why we have JavaScript? Because someone went and built it. Once it was built, it existed and people used it. All the theories about what a scripting language for the web should look like fell out the window the moment someone went and put one in their browser. De facto standards beat de jure standards. Every time. Theory is great. It makes for amazing and stimulating conversation. But in the real world the only thing that counts is building shit. PS: this is also why English is the global language of trade and not Esperanto. Even though English is both harder to learn, has a terrible "API", and inconsistent semantics and grammar and syntax. Esperanto is clean and well designed and and learnable in 150 hours and not used by anyone.
    - smadge 11y ago
      Well, presumably an advance will eventually provide a competitive advantage. For example, before the Copernican revolution, we had a model for the cosmos that made decent predictions. The heliocentric model actually made worse predictions for a long time until it was evolutionary improved. However, to the early scientists who adopted it, the heliocentric model "felt right." Maybe right now programming in a shitty language like javascript with no regard to program structure is better at "getting shit done" than programming in a functional language using universal abstractions like composition. To people who study and think about it, though, it "feels right." Perhaps if they stick with it and perfect the art, it will eventually provide such a competitive advantage that it will be universally adopted.

fsloth 11y ago

I terms of usability this seems to me up there with the set theoretic formulation of relational model. I.e. not as something everybody needs to do but offering an efficient descriptive model for complex systems. When designing programs or datastructures I prefer to use pen and paper and some simple set theoretic ad hoc notation system. I write code for production daily and without this higher level design model my code would be uk terrible shape and very slow to modify. "As a philosopher, it pains me to know people don't think that way, but if you aren't changing people's lives then all the theory is just mental masturbation." Basically really good programmers seem to see the optimal structure for a specific problem out of practice. I need to have some sort of theoretic framework which to use to compose my program logic. I've not had the time to look into category theory but this post succeeded in convincing me it's a practical mental tool to help in program composition. So, based on my personal preferences, I disagree this would not have practical benefits.

T-R 11y ago

The theory is for getting consistent/composable APIs, and trust in the code - trust that you can optimize it, parallelize it, or just that it behaves the way it's supposed to, without having to read every line of it. You don't need to think in theory to benefit from that. While it's certainly cute that I can `gem install` a CMS, the Ruby ecosystem is infamous for its magical, non-composable, monolithic frameworks. The functional ecosystems are working toward fixing the all-too-familiar problem where you have to either start over, or hack apart some giant stateful mess anytime your exact usecase hasn't already been built as a library. It's easy to throw a nice looking house together with Lincoln Logs, but I'd take Lego instead any day. Edit: Also, just because someone hasn't built the tallest building in your neighborhood yet doesn't mean they're not building anything. JP Morgan, Kapersky, Facebook, and IMVU are hiring Haskell devs, just off the top of my head.

virtualwhys 11y ago
Agreed on popularity of language/framework not being an indicator of success (wrt to software evolution), quite the opposite seems to happen in the mainstream. Worth noting that finance industry heavyweights such as JP Morgan and Standard Chartered (largest Haskell shop in the world) are laying off more than they're hiring these days[0][1], though unlikely this trend would directly affect tech hires (current batch of layoffs seem to be a trimming of management tier). On a somewhat related note: were Standard Chartered to open source their fork of GHC many Haskellers not sold on lazy-by-default would rejoice; from Scala side of the fence my interest in Haskell would increase 10X were that to happen, line numbered stack traces alone, who woulda "thunk" it ;-) Moving forward Haskell's probably going to continue to be pilfered of its theoretical gems by other languages that leap frog it in terms of adoption. Not a bad thing if we take SPJ's "avoid success at all costs" at face value. [0] http://www.bloomberg.com/news/articles/2015-05-28/jpmorgan-said-to-plan-thousands-of-job-cuts-as-bank-pares-costs http://www.bloomberg.com/news/articles/2015-05-28/jpmorgan-s... [1] http://www.bloomberg.com/news/articles/2015-07-20/standard-chartered-s-ceo-boosts-direct-control-in-overhaul http://www.bloomberg.com/news/articles/2015-07-20/standard-c...
- tome 11y ago
  > Worth noting that finance industry heavyweights such as JP Morgan and Standard Chartered (largest Haskell shop in the world) are laying off more than they're hiring these days[0][1], though unlikely this trend would directly affect tech hires (current batch of layoffs seem to be a trimming of management tier). Indeed. Hiring of Haskellers continues apace at SC: https://twitter.com/donsbot/status/654630194519646208 https://twitter.com/donsbot/status/654630194519646208 > were Standard Chartered to open source their fork of GHC many Haskellers not sold on lazy-by-default would rejoice It's not a fork of GHC. It's an entirely new compiler, called Mu.

gaius 11y ago

Monads are a common joke to this effect. So much so that I wonder if the popular monad tutorial involving spacesuits and burritos wasn't actually made as a pisstake (but I am 99% sure the author was serious).

danidiaz 11y ago
You might be interested in the inverse burrito-monad tutorial: http://www.cs.cmu.edu/~edmo/silliness/burrito_monads.pdf http://www.cs.cmu.edu/~edmo/silliness/burrito_monads.pdf

mbrock 11y ago

Haskell isn't designed for "average people" or "most people" and why should it be? Real human beings use Haskell every day and love it. Real human beings are capable of learning about teh scary maths and abstract theories. You studied philosophy? Are you aware that most people don't understand anything about philosophical theories other than The Secret? Have you thought about how maybe those theories can change people's lives even though they're not aimed at a lowest common denominator? E.g. by being influential in the long run, and also by being intellectually stimulating to people who do bother to learn about it? Rails-style success is not the goal for Haskell. It is an explicit anti-goal: the motto is "avoid success at all costs." Terse and rude counterpoint to your thesis: Average people are lazy idiots and designing your language to appeal to them will result in a very popular incoherent mess, like Java and Ruby, and Dijkstra will make pointed remarks at you from his grave. http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html

Numberwang 11y ago
So the goal is for Haskell to be the Ithkuil of the programming world? That's a noble idea. Knowing this also makes it easier for me to chose to avoid reading articles about it.
- mbrock 11y ago
  No. The goal is to be useful in both research and industry by means of principled design based on mathematics and engineering. If that scares you, fine, you don't have to be interested in everything. If you think everything that's not designed to appeal to some notion of an "average programmer" is necessarily obfuscated and impossibly difficult, that's on you. Go ahead and avoid it.
  - Numberwang 11y ago
    That sure does sound like a yes, not a no.
    - stingraycharles 11y ago

david_ar 11y ago

Replace the word "theory" with "abstraction" or "interface" then. All the article is saying is that there's a bunch of common things (Unix pipes, function composition, procedure sequencing) that all follow a few simple rules (a "contract" if you like). This means you can reason about them together without having to think about the individual "implementation details".

porker 11y ago

> Sandy Metz doesn't get heard if DHH isn't building Basecamp. Eh? Are you saying Sandy Metz isn't good, and needs DHH to provide a platform? Disclosure: I have read POODR and am not sure what to make of it, as it's pragmatic but says the opposite of other OOP books I've read

avz 11y ago

> Why was Rails successful? I don't think Haskell aims for this kind of success. Abstractions can be useful and they can be beautiful. If your goal is to "easily build functional CRUD apps" you need the former. If you do research in computing science or would like to further your understanding or simply seek to appreciate the elegance and beauty in computation, you need the latter. Admittedly, the latter goals (except research) are self-directed (they may make you a better or at least a happier programmer) and they don't directly contribute value to your customers, so I understand why you just called them "mental masturbation". However, I strongly disagree with that label. There is a long-term value in learning and general self-improvement.

mbrock 11y ago
Unfortunately I don't know of much research in formalizing CRUD apps, but maybe it's out there. The long-term wish as I see it would be for us as an engineering discipline to develop a really clear understanding of the domain, enough to be able to build these CRUD apps in composable ways that can be reasoned about with clear language. Guiding vague questions might include: What is the essence of a CRUD app? How could you define a CRUD app in terms of sets, functions, and categories? What kinds of laws apply in the general CRUD domain? How can we statically verify correctness properties for real-world CRUD systems? That hope has nothing to do with mental masturbation and everything to do with wanting to concretely improve the state of civilization. And of course to reduce the amount of time spent making and debugging the same kind of thing over and over again.
- catnaroek 11y ago
  I am by no means a researcher, but, as a programmer who writes said CRUD apps for a living, I can guarantee that I derive most of my understanding of a complex business domain from the structure of the relational database backing it. And what is a relational database? A (time-evolving) subcategory of the category of finite sets! Primitive types (as sets of values) and tables (as sets of primary key values) are objects. Fields (as functions of primary keys) are morphisms. Chained foreign key traversal is morphism composition. I find this way of reasoning incredibly powerful, because it tells me quickly what kind of transactions make sense in a business domain. Of course, this is contingent on the database being well designed. It is exactly the same as with Haskell types - if you can leverage the (type system) schema to encode interesting logical properties of your (problem) business domain, then (type checking) checking a query against the schema in itself becomes a lightweight form of formal verification. One thing that must be remarked, however, is that, sadly, SQL lacks analogues of sum and product types, that is, tables whose cardinality (number of rows) is the sum or product of the cardinalities of other tables. This addition would make SQL even more powerful, but it would require a move to a more category-theory-based foundation for databases. (The relational model is based on first-order logic.)

throwawayignt 11y ago

>> Category theory codifies this compositional style into a design pattern, the category. >To the average person, a theory codifying a style into a pattern just isn't useful But you don't mean "the average person", you mean "the average competent programmer." For example I'm not an "average person" and I don't understand the sentence you linked (the one I quote at the top of this comment.) It's just gobbledegook to me, the way a bit mask is to someone who doesn't know what bits are exactly, they're just, like, 1's and 0's in the computer right? You have to explain a lot before they would even understand what you're talking about. They might not know what a power of 2 has to do with anything. This is an analogy. It's the same - average competent programmers don't have this mental infrastructure. I and most competent programmers have no idea what a category is.

omginternets 11y ago
>I and most competent programmers have no idea what a category is. By your own admission, you have no idea whether or not category theory is useful to you. Take pride in your ignorance if you like, but at least don't claim to know what you're talking about in the same breath.

ecthiender 11y ago

This is utterly wrong. Theory is not any mental masturbation. On the contrary, theory helps in understanding a problem with sparkling clarity and often offers a general approach or solution to the problem. The above is a problem with people who thinks everything in the world is black and white; or they themselves don't understand theories, maybe even being right in the circle which theorizes theories day and night (read academic circles). The key is to understand that all of us theorize all the time. Being programmers, whenever we see a problem, we do try to approach it scientifically. Basing parts of the problem on already established knowledge (read theory). See what we are doing here? We are theorizing a problem. It may not be any formal theory but informal theory is still theory. The point is theory is not just intellectual mumbo jumbo, sure it stimulates few of us to the point of orgasm, but theory is a very humble practice which helps us understand things better.