4 ms·

Dijkstra would agree that programming is hard, but not that those who program should suffer. Quite the contrary, I'd like to add, as he would often point out th

by edejong 11y ago

Dijkstra would agree that programming is hard, but not that those who program should suffer. Quite the contrary, I'd like to add, as he would often point out that programmers currently suffer because of their leaky abstractions and continuous bug fixing. He wanted to bring programming back to mathematical fundamentals, so it is simple to reason about. It is my personal opinion that this ethos is the drive behind the renaissance of functional programming. Programming is hard. I've been programming for 25 years now and if anything, it never gets easier. To find the right abstraction, so only the correct things become simple, is one of the hardest tasks.

klibertp 11y ago
FP is not "easier to reason about" (for humans; it is easier for machines). It's getting popular because it promises composability and reusability: the very thing OOP promised and failed to deliver. FP will fail, too - there's no silver bullet! - and then we'll move to something else.
- strmpnk 11y ago
  Yet composability is exactly what makes it easier for humans to reason about. It's the small surface of a composable part that fits into more immediate representations in our mind. Whether or not it's natural mapping functions to and from concepts people might already operate with isn't the same problem. I'd argue that one can be offset with practice, though it's certainly not something that is easy for everyone. In that sense, FP might be a bit more immune to bad intuition, if only that you have to give up on mapping structure to insufficient analogs. The late object oriented point of view makes this step trivial for our minds and is thus a significantly complicated trade-off to quantify.
- TeMPOraL 11y ago
  FP is also getting popular because we hit the ceiling on Moore's law. Functional code is by default parallelizable (it takes effort to make it not so), which means it's a good selling point for the world in which we add more and more processors instead of increasing their speed.
- marcosdumay 11y ago
  You know, in my one big project on Haskell I choose it for performance alone. I didn't even think I needed any other of its features at the beginning. Anyway, FP people are nailing composability and reusability to never seen level just in front of your eyes. You just have to keep them open to see. OOP did it at its time too, it just hit a ceiling; but there's one reason every imperative language is OOP nowadays.
- jimmaswell 11y ago
  >It's getting popular because it promises composability and reusability: the very thing OOP promised and failed to deliver. The unfounded anti-OOP statements on this site are so ridiculous. That is entirely untrue.
pjc50 11y ago
mathematical fundamentals Unfortunately, a lot of real-world programming doesn't have mathematical fundamentals and is instead what I call "information bureaucracy". Some data items go in one side of the system; we sort, collate, bend, fold, spindle, mutilate them and they come out the other. Also called "business logic", although it is often infuriatingly illogical and crammed full of exceptions to obtuse rules.
- tel 11y ago
  There's honestly nothing less mathematical about those domains. The structures of rules and exceptions are mathematical. Business Prolog ideas like Drools are one attempt to systematize this, but others could exist. Typically business rules systems are an exercise in DSL design since you need to construct interesting combinations and programs within a very novel domain. Doing this is rather mathematical!
TheOtherHobbes 11y ago
>He wanted to bring programming back to mathematical fundamentals, so it is simple to reason about. This is fine for academic CS, but can become a unicorn hunt - of the worst kind - for real world applications. >To find the right abstraction, so only the correct things become simple, is one of the hardest tasks. This is very true, and underappreciated in CS. The problem is that every language has its own set of ready-made abstractions, libraries offer further abstractions, and philosophies - OOP, design patterns, functional programming - offer a further set. For any given problem, all of these may be non-optimal. CS could maybe spend the next fifty years working on a useful theory of abstraction design, instead of trying to bake assumptions about how abstractions are supposed to work into the tools we use. I'd love to see a meta-language which could be used to reason about impedance matching between abstractions and problem sets. I'm not sure such a thing is possible - Haskell is some way along, kind of - but it would be an improvement on languages that make it hard to design new abstractions because they come with rigid assumptions about the kinds of operations that are possible with code and data. You could argue no restrictions exist in Turing complete languages. But for many problems the limit isn't Turing computability, it's how easy it is to find/invent expressive abstractions that help make hard problems more tractable.

by edejong 11y ago

klibertp 11y ago

FP is not "easier to reason about" (for humans; it is easier for machines). It's getting popular because it promises composability and reusability: the very thing OOP promised and failed to deliver. FP will fail, too - there's no silver bullet! - and then we'll move to something else.

strmpnk 11y ago
Yet composability is exactly what makes it easier for humans to reason about. It's the small surface of a composable part that fits into more immediate representations in our mind. Whether or not it's natural mapping functions to and from concepts people might already operate with isn't the same problem. I'd argue that one can be offset with practice, though it's certainly not something that is easy for everyone. In that sense, FP might be a bit more immune to bad intuition, if only that you have to give up on mapping structure to insufficient analogs. The late object oriented point of view makes this step trivial for our minds and is thus a significantly complicated trade-off to quantify.
TeMPOraL 11y ago
FP is also getting popular because we hit the ceiling on Moore's law. Functional code is by default parallelizable (it takes effort to make it not so), which means it's a good selling point for the world in which we add more and more processors instead of increasing their speed.
marcosdumay 11y ago
You know, in my one big project on Haskell I choose it for performance alone. I didn't even think I needed any other of its features at the beginning. Anyway, FP people are nailing composability and reusability to never seen level just in front of your eyes. You just have to keep them open to see. OOP did it at its time too, it just hit a ceiling; but there's one reason every imperative language is OOP nowadays.
jimmaswell 11y ago
>It's getting popular because it promises composability and reusability: the very thing OOP promised and failed to deliver. The unfounded anti-OOP statements on this site are so ridiculous. That is entirely untrue.

pjc50 11y ago

mathematical fundamentals Unfortunately, a lot of real-world programming doesn't have mathematical fundamentals and is instead what I call "information bureaucracy". Some data items go in one side of the system; we sort, collate, bend, fold, spindle, mutilate them and they come out the other. Also called "business logic", although it is often infuriatingly illogical and crammed full of exceptions to obtuse rules.

tel 11y ago
There's honestly nothing less mathematical about those domains. The structures of rules and exceptions are mathematical. Business Prolog ideas like Drools are one attempt to systematize this, but others could exist. Typically business rules systems are an exercise in DSL design since you need to construct interesting combinations and programs within a very novel domain. Doing this is rather mathematical!

TheOtherHobbes 11y ago

>He wanted to bring programming back to mathematical fundamentals, so it is simple to reason about. This is fine for academic CS, but can become a unicorn hunt - of the worst kind - for real world applications. >To find the right abstraction, so only the correct things become simple, is one of the hardest tasks. This is very true, and underappreciated in CS. The problem is that every language has its own set of ready-made abstractions, libraries offer further abstractions, and philosophies - OOP, design patterns, functional programming - offer a further set. For any given problem, all of these may be non-optimal. CS could maybe spend the next fifty years working on a useful theory of abstraction design, instead of trying to bake assumptions about how abstractions are supposed to work into the tools we use. I'd love to see a meta-language which could be used to reason about impedance matching between abstractions and problem sets. I'm not sure such a thing is possible - Haskell is some way along, kind of - but it would be an improvement on languages that make it hard to design new abstractions because they come with rigid assumptions about the kinds of operations that are possible with code and data. You could argue no restrictions exist in Turing complete languages. But for many problems the limit isn't Turing computability, it's how easy it is to find/invent expressive abstractions that help make hard problems more tractable.