6 ms·

I thought the book was stupid. Rehashed a bunch of obvious ideas. It’s a bit harsh, I know, but that’s my honest opinion and I respect other people who like his

I thought the book was stupid. Rehashed a bunch of obvious ideas. It’s a bit harsh, I know, but that’s my honest opinion and I respect other people who like his book. I too have a fp background and I felt the author is unqualified to talk about complexity without knowing fp. Elimination of procedures and mutations is a formal and concrete reduction of complexity while the authors definition of complexity is hand wavy. Someone should know about what fp is before writing a book like this. Why? Because fp is a basically like a formal structure for software design and the author tried to talk about philosophy without knowing some hard formal rules that are well known in the industry. Not saying these rules are absolute but you can’t talk about design without talking about this. The book talks about modularity and things of that nature too and totally skips out on understanding the separation between statefulness and logic. The author completely misses this design concept of how how IO and mutation should be separated from declarative operations. Imperative shell/functional core is a central design philosophy that he doesn’t touch upon. The book is woefully incomplete without talking about this. Whether the authors philosophy aligns with it is open for debate but you can’t talk about what he talks about without mentioning this in a big way.

shinycode 2y ago
Interested if you can give other books/resources on the subject (not fp though)
- ninetyninenine 2y ago
  Can’t because fp is in itself basically a design philosophy that can be explained in 3 axioms. Segregate mutation from logic Segregate IO from logic Eliminate procedures from logic. The third axiom is sort of for free as it falls out automatically when someone enforces the first two. That’s basically imperative shell/functional core design philosophy which is basically identical to the rules of pure functional programming. https://medium.com/ssense-tech/a-look-at-the-functional-core-and-imperative-shell-pattern-be2498da153a https://medium.com/ssense-tech/a-look-at-the-functional-core... With fp you can think of these rules enforced as a language. Outside of fp we call it functional core / imperative shell and these rules can be enforced in an imperative language as a core design philosophy.
  - kfreds 2y ago
    Thank you. I found this comment illuminating. I too am very interested to hear any book recommendations you have on the topic. What are your favorite books on software design, functional programming, and/or computing generally? What are your favorite papers on the topic of complexity (as FP defines it)?
    - BoiledCabbage 2y ago
      "Domain Modeling Made Functional" is a great read and sits next to a lot of these topics. Very easy to follow and learn from even if you don't know (and never intend to use) the language.
  - rramadass 2y ago
    I would like to echo the user kfreds sibling comment. I don't have a FP background either and hence would very much like to hear your recommendations on books/videos/articles to understand FP and design the "FP way".
  - analog31 2y ago
    I also found this useful. I'm not a software developer, but use programming for problem solving and prototyping. Still, things that "look like software" sometimes leak out of my lab. FP always set off my BS alarm, because in my simplistic view, the whole world has state. But even for my crude work, a sort of "separation of powers" helps clean up my programs a lot, and code that doesn't need to have side effects can be a lot cleaner if it's not mixed with code that does.
    - skydhash 2y ago
      FP does not deny state, it merely segregate it between the before and the after, and everything that is in between is transient. Then you combine all the individual functions, piping them into each other and the whole reflect the same structure. Then, it becomes easier to reason about your logic as you only have two worry about 2 states: the input and the result. No need to care about individual transformations and ordering like you do in imperative.
- vendiddy 2y ago
  I disagree with the op and found the book to be very good. If you haven't read it, I would recommend reading it and judging for yourself.
_yb2s 2y ago
If this is so stupid and obvious, why does apparently 99.99% of software designed by professional engineers seem to be designed by people completely oblivious to these ideas and considerations? Following these philosophical principles themselves- it seems like a simpler and more accessible treatment of these ideas would be vastly more effective then a more rigorous and complete one- because the ideas are indeed simple.
- ninetyninenine 2y ago
  > If this is so stupid and obvious, why does apparently 99.99% of software designed by professional engineers seem to be designed by people completely oblivious to these ideas and considerations? It’s similar to why a big portion of the world believes in Christianity and another portion believes in Buddhism. Basically only one or none of these religions is correct rendering at least one population of people believing in a completely made up fantasy concept. Much of what is preached in software is religion and what is preached by the majority can be completely ludicrous. The majority believing or not knowing something doesn’t mean anything.
  - _yb2s 2y ago
    Religious “truths” are not factual truths- they are better thought of as psychological technology or techniques, and are “true” if they work for the intended purpose. Many conflicting religious “truths” are all “true.” Even calling them truths is only done to make the religions accessible to people that can’t mentally process nuance, and the techniques only work for them if labeled as truth. Intelligent religious scholars understand this well- for example Mahayana and Vajrayana Buddhism both teach nearly opposite and factually incompatible perspectives on almost everything, yet are often both used by the same religious teachers for different pupils as appropriate. The same is true for software design- an approach is not literally true or false, but either works for its intended purpose or does not. Conflicting philosophies can both be “true” just with different underlying goals or values. To circle back here, my point is that this information is presented in a simple way that will let people reading it design better software. Saying they have no right to present it without a much less accessible and more complex framework that would likely make it less useful to the intended audience does not make sense to me. FWIW, I am also a functional programmer, but would love to see people that are not follow some of these ideas.
musicale 2y ago
> Someone should know about what fp is before writing a book like this. 1. Are you quite sure John Ousterhout (who invented Tcl[1], comparing it to Lisp in section 7 of the original paper) doesn't "know about what fp is" as you say? 2. Do you think that the main reason functional programming hasn't taken off in systems programming is that practitioners are ignorant, or do you think there might be issues with fp systems that prevent its adoption? [1] https://web.stanford.edu/~ouster/cgi-bin/papers/tcl-usenix.pdf https://web.stanford.edu/~ouster/cgi-bin/papers/tcl-usenix.p...
- ninetyninenine 2y ago
  The book needs to talk about those issues and trade offs. Fp with lisp is only a fraction of fp. I of course am talking more along the lines of pure fp which lisp is not.
  - musicale 2y ago
    Sure, fp in Lisp might not always be true (scotsman) fp. ;-) But omitting fp in the book is not evidence that Ousterhout is ignorant of fp, and there is certainly evidence to the contrary. The likely explanation, given that he's developed a number of systems from Sprite to Tcl/Tk to RAMCloud to HOMA, is that he is addressing the current practice of systems programming, which remains primarily imperative.
vendiddy 2y ago
I too write FP code but I found this book very valuable in how he treats complexity and his concept of "deep modules". I acknowledge that he does not cover purity and mutations as a source of complexity (and they are big sources of complexity) but I don't think that merits dismissing the entire book on those grounds.
- ninetyninenine 2y ago
  I’m not dismissing the entire book. It has merit in what it mentions but it’s missing core foundational concepts. Because it misses these concepts the book isn’t good in my opinion.
  - WillAdams 2y ago
    In what ways could these concepts be discussed in the structure of the book in terms of currently prevalent programming practices?
kfreds 2y ago
The book plainly states that it is a philosophy for software design. Philosophy in this context is closely related to strategy, which is the art of reducing reality to heuristics, so that we might easier figure out how to reach our goals in a complex environment. If the book had been titled "Formal methods for software design" the lack of algorithms for reducing complexity would have been surprising. As it is about philosophy it should not be surprising that it focuses on heuristics.
- ninetyninenine 2y ago
  Applying formal methods derived from functional programming is a design heuristic. It’s a core heuristic and philosophy that is foundational in my opinion. The author failing to mention this makes the book missing a fundamental issue central to software design.
  - kfreds 2y ago
    Well put. This comment makes your criticism of the book much more clear to me at least. I agree with you that the separation of Church and state is a foundational idea of software design and even computing generally. I find it quite beautiful how it manifests in hardware as the two categories of digital logic - combinatorial and sequential. And if we zoom in on the logical expression of memory we see it again - a latch is simply two feedback loops and some combinational logic. For what it's worth I thought the book was brilliant. Its ideas weren't all obvious to me before I read it. It also inspired me to read Parnas, Wirth, Hoare, and study the Go runtime and compiler. What should be obvious is this: the fact that the ideas were obvious to you doesn't mean they are obvious to everyone. Secondly, complexity has many meanings. Managing complexity is incredibly important in the realm of security. I've been dabbling in security for 25 years, but I would certainly not claim to have a deep understanding of functional programming. Nevertheless I understand complexity quite well. I think that's what bothered me the most about your original comment - the idea that people without a background in FP are unqualified to talk about complexity.
    - mrkeen 2y ago
rubiquity 2y ago
FP weenies gone wild 2024. You design web apps with monads. Ousterhout has made systems of actual consequence where mutation is a reality not a fantasy you try to pretend doesn’t exist.

shinycode 2y ago

Interested if you can give other books/resources on the subject (not fp though)

ninetyninenine 2y ago
Can’t because fp is in itself basically a design philosophy that can be explained in 3 axioms. Segregate mutation from logic Segregate IO from logic Eliminate procedures from logic. The third axiom is sort of for free as it falls out automatically when someone enforces the first two. That’s basically imperative shell/functional core design philosophy which is basically identical to the rules of pure functional programming. https://medium.com/ssense-tech/a-look-at-the-functional-core-and-imperative-shell-pattern-be2498da153a https://medium.com/ssense-tech/a-look-at-the-functional-core... With fp you can think of these rules enforced as a language. Outside of fp we call it functional core / imperative shell and these rules can be enforced in an imperative language as a core design philosophy.
- kfreds 2y ago
  Thank you. I found this comment illuminating. I too am very interested to hear any book recommendations you have on the topic. What are your favorite books on software design, functional programming, and/or computing generally? What are your favorite papers on the topic of complexity (as FP defines it)?
  - BoiledCabbage 2y ago
    "Domain Modeling Made Functional" is a great read and sits next to a lot of these topics. Very easy to follow and learn from even if you don't know (and never intend to use) the language.
- rramadass 2y ago
  I would like to echo the user kfreds sibling comment. I don't have a FP background either and hence would very much like to hear your recommendations on books/videos/articles to understand FP and design the "FP way".
- analog31 2y ago
  I also found this useful. I'm not a software developer, but use programming for problem solving and prototyping. Still, things that "look like software" sometimes leak out of my lab. FP always set off my BS alarm, because in my simplistic view, the whole world has state. But even for my crude work, a sort of "separation of powers" helps clean up my programs a lot, and code that doesn't need to have side effects can be a lot cleaner if it's not mixed with code that does.
  - skydhash 2y ago
    FP does not deny state, it merely segregate it between the before and the after, and everything that is in between is transient. Then you combine all the individual functions, piping them into each other and the whole reflect the same structure. Then, it becomes easier to reason about your logic as you only have two worry about 2 states: the input and the result. No need to care about individual transformations and ordering like you do in imperative.
vendiddy 2y ago
I disagree with the op and found the book to be very good. If you haven't read it, I would recommend reading it and judging for yourself.

_yb2s 2y ago

If this is so stupid and obvious, why does apparently 99.99% of software designed by professional engineers seem to be designed by people completely oblivious to these ideas and considerations? Following these philosophical principles themselves- it seems like a simpler and more accessible treatment of these ideas would be vastly more effective then a more rigorous and complete one- because the ideas are indeed simple.

ninetyninenine 2y ago
> If this is so stupid and obvious, why does apparently 99.99% of software designed by professional engineers seem to be designed by people completely oblivious to these ideas and considerations? It’s similar to why a big portion of the world believes in Christianity and another portion believes in Buddhism. Basically only one or none of these religions is correct rendering at least one population of people believing in a completely made up fantasy concept. Much of what is preached in software is religion and what is preached by the majority can be completely ludicrous. The majority believing or not knowing something doesn’t mean anything.
- _yb2s 2y ago
  Religious “truths” are not factual truths- they are better thought of as psychological technology or techniques, and are “true” if they work for the intended purpose. Many conflicting religious “truths” are all “true.” Even calling them truths is only done to make the religions accessible to people that can’t mentally process nuance, and the techniques only work for them if labeled as truth. Intelligent religious scholars understand this well- for example Mahayana and Vajrayana Buddhism both teach nearly opposite and factually incompatible perspectives on almost everything, yet are often both used by the same religious teachers for different pupils as appropriate. The same is true for software design- an approach is not literally true or false, but either works for its intended purpose or does not. Conflicting philosophies can both be “true” just with different underlying goals or values. To circle back here, my point is that this information is presented in a simple way that will let people reading it design better software. Saying they have no right to present it without a much less accessible and more complex framework that would likely make it less useful to the intended audience does not make sense to me. FWIW, I am also a functional programmer, but would love to see people that are not follow some of these ideas.

musicale 2y ago

> Someone should know about what fp is before writing a book like this. 1. Are you quite sure John Ousterhout (who invented Tcl[1], comparing it to Lisp in section 7 of the original paper) doesn't "know about what fp is" as you say? 2. Do you think that the main reason functional programming hasn't taken off in systems programming is that practitioners are ignorant, or do you think there might be issues with fp systems that prevent its adoption? [1] https://web.stanford.edu/~ouster/cgi-bin/papers/tcl-usenix.pdf https://web.stanford.edu/~ouster/cgi-bin/papers/tcl-usenix.p...

ninetyninenine 2y ago
The book needs to talk about those issues and trade offs. Fp with lisp is only a fraction of fp. I of course am talking more along the lines of pure fp which lisp is not.
- musicale 2y ago
  Sure, fp in Lisp might not always be true (scotsman) fp. ;-) But omitting fp in the book is not evidence that Ousterhout is ignorant of fp, and there is certainly evidence to the contrary. The likely explanation, given that he's developed a number of systems from Sprite to Tcl/Tk to RAMCloud to HOMA, is that he is addressing the current practice of systems programming, which remains primarily imperative.

vendiddy 2y ago

I too write FP code but I found this book very valuable in how he treats complexity and his concept of "deep modules". I acknowledge that he does not cover purity and mutations as a source of complexity (and they are big sources of complexity) but I don't think that merits dismissing the entire book on those grounds.

ninetyninenine 2y ago
I’m not dismissing the entire book. It has merit in what it mentions but it’s missing core foundational concepts. Because it misses these concepts the book isn’t good in my opinion.
- WillAdams 2y ago
  In what ways could these concepts be discussed in the structure of the book in terms of currently prevalent programming practices?

kfreds 2y ago

The book plainly states that it is a philosophy for software design. Philosophy in this context is closely related to strategy, which is the art of reducing reality to heuristics, so that we might easier figure out how to reach our goals in a complex environment. If the book had been titled "Formal methods for software design" the lack of algorithms for reducing complexity would have been surprising. As it is about philosophy it should not be surprising that it focuses on heuristics.

ninetyninenine 2y ago
Applying formal methods derived from functional programming is a design heuristic. It’s a core heuristic and philosophy that is foundational in my opinion. The author failing to mention this makes the book missing a fundamental issue central to software design.
- kfreds 2y ago
  Well put. This comment makes your criticism of the book much more clear to me at least. I agree with you that the separation of Church and state is a foundational idea of software design and even computing generally. I find it quite beautiful how it manifests in hardware as the two categories of digital logic - combinatorial and sequential. And if we zoom in on the logical expression of memory we see it again - a latch is simply two feedback loops and some combinational logic. For what it's worth I thought the book was brilliant. Its ideas weren't all obvious to me before I read it. It also inspired me to read Parnas, Wirth, Hoare, and study the Go runtime and compiler. What should be obvious is this: the fact that the ideas were obvious to you doesn't mean they are obvious to everyone. Secondly, complexity has many meanings. Managing complexity is incredibly important in the realm of security. I've been dabbling in security for 25 years, but I would certainly not claim to have a deep understanding of functional programming. Nevertheless I understand complexity quite well. I think that's what bothered me the most about your original comment - the idea that people without a background in FP are unqualified to talk about complexity.
  - mrkeen 2y ago

rubiquity 2y ago

FP weenies gone wild 2024. You design web apps with monads. Ousterhout has made systems of actual consequence where mutation is a reality not a fantasy you try to pretend doesn’t exist.