5 ms·

The top comment on yesterday's post on the Keli language (https://news.ycombinator.com/item?id=24331635 https://news.ycombinator.com/item?id=24331635) sums up F

The top comment on yesterday's post on the Keli language (https://news.ycombinator.com/item?id=24331635 https://news.ycombinator.com/item?id=24331635) sums up FP's failure to become mainstream pretty clearly IMO: > The other reason is that many FP users are too enthusiastic about creating abstractions. This is of course something that FP is exceptionally well suited for. An api that was written to simply process a list of Orders into a Report might be abstracted into a fold on some monad, which at first seems a great idea. But if you're not careful, readability suffers a lot. It's much easier to get to know an application when its code deals with business objects that you already understand well, than to read hundreds of lines of code that deal only with abstractions. Industry programmers didn't sign up to learn about category theory. They do what they do because they like building things. There is a subset of those Industry Programmers that does indeed like learning about category theory and all of these other concepts necessary to grok languages such as Haskell - but it isn't a critical mass by any means. That's why I think languages like Elm are a good example of "the sweet spot" of FP languages. Yes, Elm lacks the horsepower that other pure FP languages have, but at least it doesn't lead a developer to think "hey, I didn't sign up to learn about Arrows and Monads. I just want to write a TODO list".

random3 6y ago
I think this is a long term investment that goes beyond engineer / language /etc. preferences. It's a matter of abstraction 'stability'. There's a cost for each abstraction, so modeling without fully understanding what you try to model or something that changes wrt the abstraction model will yield incomplete abstractions, be hard to read, etc. Many things are being remodeled over an over (incomplete, with bugs, etc.) when in fact they don't change much. These are good candidates for good abstractions. I don't think you'd want to do 3d graphics without a system that understand the algebraic aspects (e.g. orthogonality) behind rotations, translations, etc. Categories generalize this all the way so optimizations would be possible at a whole different level (makes me think about what Tensorflow enables). I also think you only need one category (just like you only need one group / semigroup concept) for a model and it could be language agnostic.
- codygman 6y ago
  > 95% of Go programs could be replaced with a single traverse This is a rather abrasive way of putting it that tries to communicate this point. I would have found it difficult to even entertain when my Gopher squishee on my desk and I came across it as someone very in love with Go at the time. The point though is that for loops in Go are unstructured, but very flexible. That lack of structure lets you have any organization you have, probably influenced by previous languages you've used. Structured recursion like folds and maps enforce a certain pattern to this, the same goes for traverse. That idea isn't specific to traverse though, it generalizes to all of the Haskell abstractions. The reason people talk about composability so much is because composable code means re-usable, concise as in KISS , and elegant code.
mikorym 6y ago
The more I do stats in the workplace setting (esp. PCA on the one hand, and time series models on the other) the more I think that statistics are just a way for you to zoom in on areas of interest in your data. The closer I could get category theory in the workplace, the happier I would be. Or have been. My 2 cents on the matter is that when you work with data, rather than with sets that are placeholders for containing data, the more your questions or answers would be concrete and eventually have very straightforward solutions, or at least straightforward deliverables. In terms of the programming view I would say that this means that any abstract solution would have a counterpart concrete version or versions. The reason for abstraction should be to decrease the time involved with solving something. Abstractions are meant to reason about things that you want to be broad enough to include suppositions. The whole of mathematics is studying which statements follow from which axiom statements. Once you settle on the data, it becomes less of a mathematics exercise and instead is a coding exercise to find the peculiarities of the concrete example, and then the need for abstraction becomes less. Abstraction gives me a lot of joy; but, you could instead do mathematics by enumerating all combinations of symbols and checking whether some are valid proofs of theorems. Programming will always have some context, often the context means peculiar data and hence you can solve the problem without any abstractions at all. However, the larger the data, the more difficult, and eventually concrete approaches become unfeasible. Again, one can think about this as enumerating solutions. If you had all the time in the world, you could just enumerate all programs, especially more concrete ones, and just pick the one with the right output for the input domain. If you build a wooden table, you can get by with a small, ordinary toolbox. If you want to build a skyscraper, I think you could get by with a small toolbox, but it may take you an interminable amount of time. And moreover, without the abstraction of a large crane-like device of sorts, the design of building a skyscraper with a ordinary workman's toolbox becomes much more difficult, if not impossible. The design of a crane to me is an example of the right depth of abstraction. I am not sure whether my analogy is clear, but my point is simply that abstraction is increasing the plausible data space and concretisation is selecting from possibilities. Another way to think about it: {{car, bike, plane},{spoon, knife, fork}, ...} abstract to, but specialise from {{vehicles}, {cutlery}, ...}. You want some kind of balance in this thought process that fits the code base you are building or maintaining, or the problems or questions that you are solving.
centimeter 6y ago
You don’t have to know category theory to use Haskell. You have to learn some basic concepts like monads, but complaining about that is like complaining “I don’t want to use Java because then I’d have to learn what an object is”.
- g_delgado14 6y ago
  I disagree that objects and monads are the same level of building block in the respective paradigms. Objects <> Java and functions <> Haskell might be a better comparison. Not to mention that there's already a person's intuition about what an "object" might be before they even learn programming. But there's no real-world analog to what a Monad is. So, yes, you do get into the situation where a programmer will say, "what? I didn't sign up for this" when being told to learn Monads to use Haskell.
  - centimeter 6y ago
    There’s also no real-world analog for a For-loop, but it’s still not a credible complaint to avoid learning C. Also, just because java objects are called “objects” and not some other word with less colloquial meaning doesn’t mean that they actually map well to real-world objects. Fully understanding the true semantics of Java objects is at least 100x as complicated as fully understanding the true semantics of monads. The only thing it’s easier to do with Java objects is to delude yourself into thinking you might understand them, because they have a familiar name.
    - jheriko 6y ago
      thats not true at all, repetition is natural. map is also quite natural, but isn't it telling that the way a human will do this on paper is by reptition of the same task in sequence... i.e. a for loop. > The only thing it’s easier to do with Java objects is to delude yourself into thinking you might understand them, because they have a familiar name. i'm not sure why you consider this 'delusion'? that familiarity of name and concept is precisely why its so easy to learn.
codygman 6y ago
> The other reason is that many FP users are too enthusiastic about creating abstractions. Are they? I'd argue most real-world Haskell code doesn't abstract enough, perhaps out of over-reaction to this untrue assertion that seems prevalent these days. > This is of course something that FP is exceptionally well suited for. An api that was written to simply process a list of Orders into a Report might be abstracted into a fold on some monad, which at first seems a great idea. But if you're not careful, readability suffers a lot. It's much easier to get to know an application when its code deals with business objects that you already understand well, than to read hundreds of lines of code that deal only with abstractions. A lack of that isn't the fault of re-using powerful abstractions at the base, it's a failure of not making the concrete implementations more obvious. It would be most constructive if we could work with examples, but I don't know what the origional commenter had in mind since that hasn't been my experience with industrial Haskell. > Industry programmers didn't sign up to learn about category theory. They do what they do because they like building things. There is a subset of those Industry Programmers that does indeed like learning about category theory and all of these other concepts necessary to grok languages such as Haskell - but it isn't a critical mass by any means. Why all the conversation about category theory? I've read most of Algebra Drive Design and I think you've mentioned it more times than the book! > Yes, Elm lacks the horsepower that other pure FP languages have, but at least it doesn't lead a developer to think "hey, I didn't sign up to learn about Arrows and Monads. I just want to write a TODO list". You can write your TODO list in Haskell without thinking about Arrows for sure, and very likely without thinking about Monads.
amw-zero 6y ago
For me the best analogy is carpentry vs. architecture. I’m not saying anything about FP In particular. But there’s a cohort of people that just want to “build stuff” like you said. And then there’s people who want to architect a solution because they feel that what they’re building needs to last, or can’t fail. I don’t think either mentality is wrong. You wouldn’t hire an architect to build you a closet, and you wouldn’t hire a carpenter to build you an office building. It’s about context. I think each type of person bothers each other when they try and apply their thinking as dogma to all contexts. I can name a million times where a global variable was fine, or a long function was fine, or some duplication was absolutely fine. I can also name a million more where I really wanted exactly one location for a piece of knowledge, and a million more where I wanted to separate database queries from in-memory logic. I think the problem is when you use the term “Industry Programmer.” Not all programmers want to work on the same thing. This theoretical “average” person who just wants to “get work done” doesn’t exist in my experience. It’s just one type of programmer who likes one type of context. That’s ok, but no one should hate on people for working on what they’re interested in. It’s the same thing with math. Many people feel that math is not practical or relevant. Until you want to do something like build a skyscraper, or a house, or design a power grid. Then all of a sudden math isn’t an option. If we only listened to the “average” person, we probably wouldn’t have that many useful things.
xfer 6y ago
Which industry are you talking about(maybe fang)? The kind of factories making factories and so on in the industry Java code is mind-boggling . And none of it has to do with business logic. Asking OOP factory makers to learn about category theory is going to be a difficult task. There are a lot of FP languages that don't require learning category theory. Ocaml has been around for ages and even Microsoft has its own ML flavour mainstream language called F#. Abstraction doesn't seem like the reason to me, it might be inertia.
- matt-noonan 6y ago
  Just to be totally explicit here, there are no FP languages that require learning category theory. There is no reason to conflate [a small subset of] research on programming languages with the practice of using those languages day-to-day to Actually Get Shit Done.

random3 6y ago

I think this is a long term investment that goes beyond engineer / language /etc. preferences. It's a matter of abstraction 'stability'. There's a cost for each abstraction, so modeling without fully understanding what you try to model or something that changes wrt the abstraction model will yield incomplete abstractions, be hard to read, etc. Many things are being remodeled over an over (incomplete, with bugs, etc.) when in fact they don't change much. These are good candidates for good abstractions. I don't think you'd want to do 3d graphics without a system that understand the algebraic aspects (e.g. orthogonality) behind rotations, translations, etc. Categories generalize this all the way so optimizations would be possible at a whole different level (makes me think about what Tensorflow enables). I also think you only need one category (just like you only need one group / semigroup concept) for a model and it could be language agnostic.

codygman 6y ago
> 95% of Go programs could be replaced with a single traverse This is a rather abrasive way of putting it that tries to communicate this point. I would have found it difficult to even entertain when my Gopher squishee on my desk and I came across it as someone very in love with Go at the time. The point though is that for loops in Go are unstructured, but very flexible. That lack of structure lets you have any organization you have, probably influenced by previous languages you've used. Structured recursion like folds and maps enforce a certain pattern to this, the same goes for traverse. That idea isn't specific to traverse though, it generalizes to all of the Haskell abstractions. The reason people talk about composability so much is because composable code means re-usable, concise as in KISS , and elegant code.

mikorym 6y ago

The more I do stats in the workplace setting (esp. PCA on the one hand, and time series models on the other) the more I think that statistics are just a way for you to zoom in on areas of interest in your data. The closer I could get category theory in the workplace, the happier I would be. Or have been. My 2 cents on the matter is that when you work with data, rather than with sets that are placeholders for containing data, the more your questions or answers would be concrete and eventually have very straightforward solutions, or at least straightforward deliverables. In terms of the programming view I would say that this means that any abstract solution would have a counterpart concrete version or versions. The reason for abstraction should be to decrease the time involved with solving something. Abstractions are meant to reason about things that you want to be broad enough to include suppositions. The whole of mathematics is studying which statements follow from which axiom statements. Once you settle on the data, it becomes less of a mathematics exercise and instead is a coding exercise to find the peculiarities of the concrete example, and then the need for abstraction becomes less. Abstraction gives me a lot of joy; but, you could instead do mathematics by enumerating all combinations of symbols and checking whether some are valid proofs of theorems. Programming will always have some context, often the context means peculiar data and hence you can solve the problem without any abstractions at all. However, the larger the data, the more difficult, and eventually concrete approaches become unfeasible. Again, one can think about this as enumerating solutions. If you had all the time in the world, you could just enumerate all programs, especially more concrete ones, and just pick the one with the right output for the input domain. If you build a wooden table, you can get by with a small, ordinary toolbox. If you want to build a skyscraper, I think you could get by with a small toolbox, but it may take you an interminable amount of time. And moreover, without the abstraction of a large crane-like device of sorts, the design of building a skyscraper with a ordinary workman's toolbox becomes much more difficult, if not impossible. The design of a crane to me is an example of the right depth of abstraction. I am not sure whether my analogy is clear, but my point is simply that abstraction is increasing the plausible data space and concretisation is selecting from possibilities. Another way to think about it: {{car, bike, plane},{spoon, knife, fork}, ...} abstract to, but specialise from {{vehicles}, {cutlery}, ...}. You want some kind of balance in this thought process that fits the code base you are building or maintaining, or the problems or questions that you are solving.

centimeter 6y ago

You don’t have to know category theory to use Haskell. You have to learn some basic concepts like monads, but complaining about that is like complaining “I don’t want to use Java because then I’d have to learn what an object is”.

g_delgado14 6y ago
I disagree that objects and monads are the same level of building block in the respective paradigms. Objects <> Java and functions <> Haskell might be a better comparison. Not to mention that there's already a person's intuition about what an "object" might be before they even learn programming. But there's no real-world analog to what a Monad is. So, yes, you do get into the situation where a programmer will say, "what? I didn't sign up for this" when being told to learn Monads to use Haskell.
- centimeter 6y ago
  There’s also no real-world analog for a For-loop, but it’s still not a credible complaint to avoid learning C. Also, just because java objects are called “objects” and not some other word with less colloquial meaning doesn’t mean that they actually map well to real-world objects. Fully understanding the true semantics of Java objects is at least 100x as complicated as fully understanding the true semantics of monads. The only thing it’s easier to do with Java objects is to delude yourself into thinking you might understand them, because they have a familiar name.
  - jheriko 6y ago
    thats not true at all, repetition is natural. map is also quite natural, but isn't it telling that the way a human will do this on paper is by reptition of the same task in sequence... i.e. a for loop. > The only thing it’s easier to do with Java objects is to delude yourself into thinking you might understand them, because they have a familiar name. i'm not sure why you consider this 'delusion'? that familiarity of name and concept is precisely why its so easy to learn.

codygman 6y ago

> The other reason is that many FP users are too enthusiastic about creating abstractions. Are they? I'd argue most real-world Haskell code doesn't abstract enough, perhaps out of over-reaction to this untrue assertion that seems prevalent these days. > This is of course something that FP is exceptionally well suited for. An api that was written to simply process a list of Orders into a Report might be abstracted into a fold on some monad, which at first seems a great idea. But if you're not careful, readability suffers a lot. It's much easier to get to know an application when its code deals with business objects that you already understand well, than to read hundreds of lines of code that deal only with abstractions. A lack of that isn't the fault of re-using powerful abstractions at the base, it's a failure of not making the concrete implementations more obvious. It would be most constructive if we could work with examples, but I don't know what the origional commenter had in mind since that hasn't been my experience with industrial Haskell. > Industry programmers didn't sign up to learn about category theory. They do what they do because they like building things. There is a subset of those Industry Programmers that does indeed like learning about category theory and all of these other concepts necessary to grok languages such as Haskell - but it isn't a critical mass by any means. Why all the conversation about category theory? I've read most of Algebra Drive Design and I think you've mentioned it more times than the book! > Yes, Elm lacks the horsepower that other pure FP languages have, but at least it doesn't lead a developer to think "hey, I didn't sign up to learn about Arrows and Monads. I just want to write a TODO list". You can write your TODO list in Haskell without thinking about Arrows for sure, and very likely without thinking about Monads.

amw-zero 6y ago

For me the best analogy is carpentry vs. architecture. I’m not saying anything about FP In particular. But there’s a cohort of people that just want to “build stuff” like you said. And then there’s people who want to architect a solution because they feel that what they’re building needs to last, or can’t fail. I don’t think either mentality is wrong. You wouldn’t hire an architect to build you a closet, and you wouldn’t hire a carpenter to build you an office building. It’s about context. I think each type of person bothers each other when they try and apply their thinking as dogma to all contexts. I can name a million times where a global variable was fine, or a long function was fine, or some duplication was absolutely fine. I can also name a million more where I really wanted exactly one location for a piece of knowledge, and a million more where I wanted to separate database queries from in-memory logic. I think the problem is when you use the term “Industry Programmer.” Not all programmers want to work on the same thing. This theoretical “average” person who just wants to “get work done” doesn’t exist in my experience. It’s just one type of programmer who likes one type of context. That’s ok, but no one should hate on people for working on what they’re interested in. It’s the same thing with math. Many people feel that math is not practical or relevant. Until you want to do something like build a skyscraper, or a house, or design a power grid. Then all of a sudden math isn’t an option. If we only listened to the “average” person, we probably wouldn’t have that many useful things.

xfer 6y ago

Which industry are you talking about(maybe fang)? The kind of factories making factories and so on in the industry Java code is mind-boggling . And none of it has to do with business logic. Asking OOP factory makers to learn about category theory is going to be a difficult task. There are a lot of FP languages that don't require learning category theory. Ocaml has been around for ages and even Microsoft has its own ML flavour mainstream language called F#. Abstraction doesn't seem like the reason to me, it might be inertia.

matt-noonan 6y ago
Just to be totally explicit here, there are no FP languages that require learning category theory. There is no reason to conflate [a small subset of] research on programming languages with the practice of using those languages day-to-day to Actually Get Shit Done.