9 ms·

Book Review: A Philosophy of Software Design (2020)

241 points by fagnerbrack 5y ago

_wp_ 5y ago
I bought this book off the back of the referenced discussion trashing Clean Code. Whilst Clean Code has its problems, well articulated in that previous discussion, I am loathe to recommend this book. A large part of it is dedicated to commenting practices and seems a bit out of touch with the way software is developed today. There were some rather dubious claims on TDD as well, suggesting that it aims to 'get features working, rather than finding the best design' which seems to completely ignore the refactoring phase practised in a TDD cycle. A choice quote about comments that I strongly disagreed with: "without comments, you cannot hide complexity". The book also strongly advocates for large classes and considers small ones an anti-pattern called 'classitis'. I'd say half the book contained good advice, the other half was mediocre or dubious at best. I'm curious to hear what others think who've read both books.
- verinus 5y ago
  I am just in the middle of the book but so far I also have mixed feelings: + thoughts on complexity and how constant addition of new features adds to complexity + deep vs. shallow modules but at the same time... - "..classitis": author criticizes the use of many small classes and functions/methods while I think form my experience SOLID principles are there for a reason- every method/class should have one purpose only. - which leads me straight to my second point of critique so far: nomenclature. for several ideas exist established names already that are not used in the book.
  - civilized 5y ago
    >-"..classitis": author criticizes the use of many small classes and functions/methods while I think form my experience SOLID principles are there for a reason- every method/class should have one purpose only. I don't understand how you can be so confident that SOLID means you should have many small classes and functions/methods. The question of when we should carve off a piece of reality (natural or artificial) and call it one thing, or say that it does one thing, is an ancient philosophical question with no single right or easy answer.
- bvrmn 5y ago
  The book's design approach suites TDD perfectly. Narrow deep modules allow to freely refactor internals and keep tests green.
  - _wp_ 5y ago
    I didn't say that the book's approach contradicted TDD, I'm merely quoting from the book and refuting one its claims (that TDD doesn't lead to good design). I agree that narrow and deep modules support refactoring internals if their unit tests are written to treat them as black boxes.
    - bvrmn 5y ago
      TDD in classical form (understood by most devs) aka "one test per function/method" leads to poor design indeed. There is a little training about why this approach couples code with tests and what to do instead.
      - rileymat2 5y ago
        Yes, that would make for both terrible design and terrible tests. I think sometimes people refuse to go past the words naming a practice or past the tldr; and it causes problems.
- Chris_Newton 5y ago
  I’ve read both books. I consider Ousterhout’s to be one of the better recent books on software development, though as mentioned in my other comment, this is more because of the earlier content than the later chapters. I have been critical of Clean Code since before it was cool and I actively recommend against junior developers reading it. I would have liked to see Ousterhout make a more thorough argument if he was going to criticise TDD. His central criticism — that TDD results in what he calls tactical programming, prioritising the implementation of specific features over good design — is certainly defensible. However, I think he was too superficial in what he actually wrote on the TDD section, and consequently I don’t think he made a particularly convincing connection with the ideas developed earlier in the book. I think you’re slightly unfairly misrepresenting his position on large or small classes. He makes a solid case that what he calls deep modules are better for managing complexity than shallow ones. He also identifies a correlation with size because small modules tend to be shallow. That’s not the same as arguing for large classes or against small classes just because of their size, though.
- shakezula 5y ago
  I think you're referring to the part in the book where Ousterhout says he doesn't like to start with a test harness when writing a new abstraction or feature like some advocates of TDD would. I think that was some of the best advice in the book in my opinion. Instead, Ousterhout recommends designing the interface for the abstraction you're building before you start writing a test harness for it, and I can't agree enough with that statement. If you write a good interface, testing it will be easy. If testing the interface isn't easy, then you have a bad interface. (This is relative to the complexity of the code invovled, obviously)
tablet 5y ago
Book with a promising name, but very mixed content. Two good thoughts: 1. Modules should be deep. It is better to have fewer deep modules than more shallow modules 2. The increments of development should be abstractions, not features. When you need an abstraction, invest time and design it clearly There are many good advices, but on my opinion the book is not deep enough to have this promising title. Also, it's a crime to spend 30 pages of 170 on how to write comments. 3/5
- verinus 5y ago
  I am still in the middle of reading the book and have not read the part about comments, but so far I have yet so see good comments in source code up to a point where I have a rather biased opinion on comments: * good software needs hardly any comments: small methods with good naming facilitate readability * unit tests are superb documentary as every dev can see how it is used and how it works at runtime. * meaningful documentation is hardly ever provided in source code: purpose of abstraction layers and modules, how one class/module relates to another and so on (design and architecture).
  - _wp_ 5y ago
    I strongly agree with your first two points. Good naming supplants the need for commenting. I find diagrams a far terser communication tool of architecture than comments.
    - matthiaswh 5y ago
      The book has an entire chapter called "Choosing Names" and another titled "Comments Should Describe Things That Aren't Obvious from the Code". Yes, good naming supplants the need for many comments, but the author goes into much greater detail about when and why comments are helpful even when you have given deep consideration into naming things.
      - smichel17 5y ago
        I wish we had better tooling for showing the git blame inline like comments. I'd rather put a one line comment "read the commit log for this line" which some editor could inline or pull up quickly than litter the source with prose (but either is better than nothing).
ChrisMarshallNY 5y ago
Nothing at all to do with the book review, but I enjoyed the OP's Medium blog: https://fagnerbrack.com https://fagnerbrack.com
bvrmn 5y ago
Love this book. Yep, it has some strange thoughts. But the main idea about deep/shallow modules and their interfaces is a good one.
- shakezula 5y ago
  I've found a lot of value in defining away errors, too. I think it's one of the underrated principles from that book.
iandinwoodie 5y ago
For anyone who would like to hear him speak on the topic, a talk he gave at Google was recorded: https://youtu.be/bmSAYlu0NcY https://youtu.be/bmSAYlu0NcY
brainwipe 5y ago
It's a great review, I'll check out the book. Being academic, he's going to go on about commenting, which I don't do at work but in my academic prior life they were obsessed with. Mostly because academia tends to deal in the abstract, not a single business domain. I think saying a book is "for enterprise" is a way to write them off. "I'm not working for big corp, I don't have to do that!" All coding principles are tools in your arsenal, not always appropriate but good to know. I'll grab this book on that principal.
Chris_Newton 5y ago
This is one of my favourite recent books on software development and I’m happy to recommend it. I do think the earlier chapters are better overall than the later ones. The discussions about complexity, modularity and abstraction, and trying to integrate special cases are particularly good reading for any intermediate developer looking to improve their understanding. I didn’t have big problems with the later chapters about comments and naming either, but I didn’t feel they offered the same level of insight or much unique perspective that you wouldn’t find in many other decent programming books.
danparsonson 5y ago
I'm partway through reading this book now and finding a lot to agree with and some new ideas to think about. Sorry to hijack the discussion slightly but while we're on the subject of software design books, I wondered if anyone had any thoughts about 'Righting Software' (Juval Lowy)? Particularly the first few chapters about software architecture.
AdamCraven 5y ago
Much of software engineering is based on our habitual learned behaviors through years of experience, and what are habits but behaviours that have been detached from the logic that created them? John re-attaches those habits into principles and gives you the opportunity to see and integrate his mental models. Depending on your background you're either going to love it or hate it. It's not to say what he's done is wrong or right, just your particular experience is going to colour if you agree with it or not. For those that love it, if you integrate these principles and get your team to buy in, you're going to have a better software engineering experience and a good source of information to point to back to back up the way you think. For me, these sort of books represent a maturing of the industry and recognising that software engineering is an abstract team activity that having the right shared principles and shared mental models is the difference between a joyful experience on a team or not. Shameless plug: I'm also working on community project that captures the best principles in software engineering on https://principles.dev https://principles.dev - It's a labour of love, but if you like what I've written above, please contact me. I'd love to get some feedback.
- ethangk 5y ago
  Ah it's funny to see your name pop up here! We worked together briefly at HSBC. I was interning on your team.
  - AdamCraven 5y ago
    Hello Ethan, yes I remember. What are the chances :) You made me a sample app in node and mongodb IIRC. I'll drop you a message and say hi.
- the_arun 5y ago
  Here is "Talks at Google" session on this topic from author - https://www.youtube.com/watch?v=bmSAYlu0NcY https://www.youtube.com/watch?v=bmSAYlu0NcY
ayoisaiah 5y ago
I summarised this book[1] earlier this month. One of my favourite insights was the bit about in-code documentation. I think Ousterhout made it very clear what good documentation should be all about, and I was able to apply those insights immediately. [1]: https://freshman.tech/philosophy-of-software-design-summary/ https://freshman.tech/philosophy-of-software-design-summary/
animanoir 5y ago
>philosphy >No mention of Plato It is an overused word.
- shakezula 5y ago
  And Most Pointless Comment of the Day Award goes to.... Animanoir! Come on down and collect your prize!
epage 5y ago
One of the things I appreciated about the book was the humility. Notice the "A" in the title, implying there is more than one. He takes the same approach in the book, outlying how he developed his perspective and gives room for other people to have a different perspective, and even invites them to discuss it with him! It made me more open to reading the book, knowing I wasn't being sold dogma, and gave me room to critically analyze the author's perspective, compared to my own background.
- ramblerman 5y ago
  Ironically as a review, I'm not sure if this strengthens the case for reading it. If the best thing you can say is, the author was humble...
arximboldi 5y ago
I was very disappointed with this book. To be fair, I haven't even finish it. I was expecting something philosophical, this is, something that actually connect the philosophy and software design disciplines. Outside of the title however, there is no philosophy in this book. Just general typical practical "good practice" tips of the kind you find in blog posts, without much empirical nor philosophical discussion for them.
- masterphilo 5y ago
  It seems strange to assume anything truly "philosophical" when the main topic of the book is something as practical as software engineering/design. Even if he did try to shoehorn a few bits of metaphysics in, most of the book would've had to lean more on the practical side of the domain.
jackofalltrades 5y ago
So, in your opinion are Clean Code and Clean Architecture still relevant/updated? I've come more interested in the way I think about/produce code in the last couple of months and am searching for something that might be a good read on it - considering I'm mainly a JavaScript developer. I find that most of the concepts of SOLID, for example, are really hard to figure out in most of the code base of the projects I've worked/see online implemented in Node for example. It might be related to my lack of knowledge and understanding of said principles though, but I've seen a youtube video (https://www.youtube.com/watch?v=CnailTcJV_U https://www.youtube.com/watch?v=CnailTcJV_U) some months ago that showed me a "clean architecture" implementation that I've never really seen in any project I've fiddled with.
- ratww 5y ago
  In my opinion, the caveat on the article is very apt: Clean Code teaches rules, not principles. If you read it with a critical mind you'll get a lot of it, if you follow it blindly you'll get a lot of bad habits. Unfortunately programmers need some experience to be able to do it. IMO the same caveat applies to Clean Architecture: it is study material to architects, rather than something you can copy-paste into a new project. The reason it's dauting, IMO, is because there are some unnecessary concepts there that are unrelated to the "grand idea", and those small things might make sense for Bob Martin but might not make sense to you. If you want to understand it, I really like this article. I think it explains very well the "grand idea" of architectural templates like Clean/Hexagonal/Onion... and links it to Gary Berhnardt's Imperative-shell-functional-core: https://danuker.go.ro/the-grand-unified-theory-of-software-architecture.html https://danuker.go.ro/the-grand-unified-theory-of-software-a... Of course I also recommend Imperative-shell-functional-core itself: https://www.destroyallsoftware.com/talks/boundaries https://www.destroyallsoftware.com/talks/boundaries
  - jackofalltrades 5y ago
    Thank you for your recommendations, I'll take a look on them.
dang 5y ago
Past threads related to the book: Book Review: A Philosophy of Software Design (2018) - https://news.ycombinator.com/item?id=26624057 https://news.ycombinator.com/item?id=26624057 - March 2021 (1 comment) Book Review: A Philosophy of Software Design - https://news.ycombinator.com/item?id=18331219 https://news.ycombinator.com/item?id=18331219 - Oct 2018 (51 comments) Notes on “A Philosophy of Software Design” - https://news.ycombinator.com/item?id=17906662 https://news.ycombinator.com/item?id=17906662 - Sept 2018 (32 comments)
neves 5y ago
This book is excellent. If I've had read it when I were a junior developer, I'd have advanced years of my understanding of software. Ousterhout is the inventor of one the most important unsung principle of software development: the Ousterhout's Dichotomy. "Ousterhout's Dichotomy, proposed by John Ousterhout as a software development paradigm, asserts that the world of application development is divided into two languages: a compiled language focusing on disk access and efficiency such as C, and a higher-level, typeless or loosely-typed scripting language with a simple, basic syntax." https://wiki.tcl-lang.org/page/Ousterhout%27s+Dichotomy https://wiki.tcl-lang.org/page/Ousterhout%27s+Dichotomy All your pandas, numpy, R belong to his
neves 5y ago
I'd really appreciate a a MOOC for this book.

241 points by fagnerbrack 5y ago

_wp_ 5y ago

I bought this book off the back of the referenced discussion trashing Clean Code. Whilst Clean Code has its problems, well articulated in that previous discussion, I am loathe to recommend this book. A large part of it is dedicated to commenting practices and seems a bit out of touch with the way software is developed today. There were some rather dubious claims on TDD as well, suggesting that it aims to 'get features working, rather than finding the best design' which seems to completely ignore the refactoring phase practised in a TDD cycle. A choice quote about comments that I strongly disagreed with: "without comments, you cannot hide complexity". The book also strongly advocates for large classes and considers small ones an anti-pattern called 'classitis'. I'd say half the book contained good advice, the other half was mediocre or dubious at best. I'm curious to hear what others think who've read both books.

verinus 5y ago
I am just in the middle of the book but so far I also have mixed feelings: + thoughts on complexity and how constant addition of new features adds to complexity + deep vs. shallow modules but at the same time... - "..classitis": author criticizes the use of many small classes and functions/methods while I think form my experience SOLID principles are there for a reason- every method/class should have one purpose only. - which leads me straight to my second point of critique so far: nomenclature. for several ideas exist established names already that are not used in the book.
- civilized 5y ago
  >-"..classitis": author criticizes the use of many small classes and functions/methods while I think form my experience SOLID principles are there for a reason- every method/class should have one purpose only. I don't understand how you can be so confident that SOLID means you should have many small classes and functions/methods. The question of when we should carve off a piece of reality (natural or artificial) and call it one thing, or say that it does one thing, is an ancient philosophical question with no single right or easy answer.
bvrmn 5y ago
The book's design approach suites TDD perfectly. Narrow deep modules allow to freely refactor internals and keep tests green.
- _wp_ 5y ago
  I didn't say that the book's approach contradicted TDD, I'm merely quoting from the book and refuting one its claims (that TDD doesn't lead to good design). I agree that narrow and deep modules support refactoring internals if their unit tests are written to treat them as black boxes.
  - bvrmn 5y ago
    TDD in classical form (understood by most devs) aka "one test per function/method" leads to poor design indeed. There is a little training about why this approach couples code with tests and what to do instead.
    - rileymat2 5y ago
      Yes, that would make for both terrible design and terrible tests. I think sometimes people refuse to go past the words naming a practice or past the tldr; and it causes problems.
Chris_Newton 5y ago
I’ve read both books. I consider Ousterhout’s to be one of the better recent books on software development, though as mentioned in my other comment, this is more because of the earlier content than the later chapters. I have been critical of Clean Code since before it was cool and I actively recommend against junior developers reading it. I would have liked to see Ousterhout make a more thorough argument if he was going to criticise TDD. His central criticism — that TDD results in what he calls tactical programming, prioritising the implementation of specific features over good design — is certainly defensible. However, I think he was too superficial in what he actually wrote on the TDD section, and consequently I don’t think he made a particularly convincing connection with the ideas developed earlier in the book. I think you’re slightly unfairly misrepresenting his position on large or small classes. He makes a solid case that what he calls deep modules are better for managing complexity than shallow ones. He also identifies a correlation with size because small modules tend to be shallow. That’s not the same as arguing for large classes or against small classes just because of their size, though.
shakezula 5y ago
I think you're referring to the part in the book where Ousterhout says he doesn't like to start with a test harness when writing a new abstraction or feature like some advocates of TDD would. I think that was some of the best advice in the book in my opinion. Instead, Ousterhout recommends designing the interface for the abstraction you're building before you start writing a test harness for it, and I can't agree enough with that statement. If you write a good interface, testing it will be easy. If testing the interface isn't easy, then you have a bad interface. (This is relative to the complexity of the code invovled, obviously)

tablet 5y ago

Book with a promising name, but very mixed content. Two good thoughts: 1. Modules should be deep. It is better to have fewer deep modules than more shallow modules 2. The increments of development should be abstractions, not features. When you need an abstraction, invest time and design it clearly There are many good advices, but on my opinion the book is not deep enough to have this promising title. Also, it's a crime to spend 30 pages of 170 on how to write comments. 3/5

verinus 5y ago
I am still in the middle of reading the book and have not read the part about comments, but so far I have yet so see good comments in source code up to a point where I have a rather biased opinion on comments: * good software needs hardly any comments: small methods with good naming facilitate readability * unit tests are superb documentary as every dev can see how it is used and how it works at runtime. * meaningful documentation is hardly ever provided in source code: purpose of abstraction layers and modules, how one class/module relates to another and so on (design and architecture).
- _wp_ 5y ago
  I strongly agree with your first two points. Good naming supplants the need for commenting. I find diagrams a far terser communication tool of architecture than comments.
  - matthiaswh 5y ago
    The book has an entire chapter called "Choosing Names" and another titled "Comments Should Describe Things That Aren't Obvious from the Code". Yes, good naming supplants the need for many comments, but the author goes into much greater detail about when and why comments are helpful even when you have given deep consideration into naming things.
    - smichel17 5y ago
      I wish we had better tooling for showing the git blame inline like comments. I'd rather put a one line comment "read the commit log for this line" which some editor could inline or pull up quickly than litter the source with prose (but either is better than nothing).

ChrisMarshallNY 5y ago

Nothing at all to do with the book review, but I enjoyed the OP's Medium blog: https://fagnerbrack.com https://fagnerbrack.com

bvrmn 5y ago

Love this book. Yep, it has some strange thoughts. But the main idea about deep/shallow modules and their interfaces is a good one.

shakezula 5y ago
I've found a lot of value in defining away errors, too. I think it's one of the underrated principles from that book.

iandinwoodie 5y ago

For anyone who would like to hear him speak on the topic, a talk he gave at Google was recorded: https://youtu.be/bmSAYlu0NcY https://youtu.be/bmSAYlu0NcY

brainwipe 5y ago

It's a great review, I'll check out the book. Being academic, he's going to go on about commenting, which I don't do at work but in my academic prior life they were obsessed with. Mostly because academia tends to deal in the abstract, not a single business domain. I think saying a book is "for enterprise" is a way to write them off. "I'm not working for big corp, I don't have to do that!" All coding principles are tools in your arsenal, not always appropriate but good to know. I'll grab this book on that principal.

Chris_Newton 5y ago

This is one of my favourite recent books on software development and I’m happy to recommend it. I do think the earlier chapters are better overall than the later ones. The discussions about complexity, modularity and abstraction, and trying to integrate special cases are particularly good reading for any intermediate developer looking to improve their understanding. I didn’t have big problems with the later chapters about comments and naming either, but I didn’t feel they offered the same level of insight or much unique perspective that you wouldn’t find in many other decent programming books.

danparsonson 5y ago

I'm partway through reading this book now and finding a lot to agree with and some new ideas to think about. Sorry to hijack the discussion slightly but while we're on the subject of software design books, I wondered if anyone had any thoughts about 'Righting Software' (Juval Lowy)? Particularly the first few chapters about software architecture.

AdamCraven 5y ago

Much of software engineering is based on our habitual learned behaviors through years of experience, and what are habits but behaviours that have been detached from the logic that created them? John re-attaches those habits into principles and gives you the opportunity to see and integrate his mental models. Depending on your background you're either going to love it or hate it. It's not to say what he's done is wrong or right, just your particular experience is going to colour if you agree with it or not. For those that love it, if you integrate these principles and get your team to buy in, you're going to have a better software engineering experience and a good source of information to point to back to back up the way you think. For me, these sort of books represent a maturing of the industry and recognising that software engineering is an abstract team activity that having the right shared principles and shared mental models is the difference between a joyful experience on a team or not. Shameless plug: I'm also working on community project that captures the best principles in software engineering on https://principles.dev https://principles.dev - It's a labour of love, but if you like what I've written above, please contact me. I'd love to get some feedback.

ethangk 5y ago
Ah it's funny to see your name pop up here! We worked together briefly at HSBC. I was interning on your team.
- AdamCraven 5y ago
  Hello Ethan, yes I remember. What are the chances :) You made me a sample app in node and mongodb IIRC. I'll drop you a message and say hi.
the_arun 5y ago
Here is "Talks at Google" session on this topic from author - https://www.youtube.com/watch?v=bmSAYlu0NcY https://www.youtube.com/watch?v=bmSAYlu0NcY

ayoisaiah 5y ago

I summarised this book[1] earlier this month. One of my favourite insights was the bit about in-code documentation. I think Ousterhout made it very clear what good documentation should be all about, and I was able to apply those insights immediately. [1]: https://freshman.tech/philosophy-of-software-design-summary/ https://freshman.tech/philosophy-of-software-design-summary/

animanoir 5y ago

>philosphy >No mention of Plato It is an overused word.

shakezula 5y ago
And Most Pointless Comment of the Day Award goes to.... Animanoir! Come on down and collect your prize!

epage 5y ago

One of the things I appreciated about the book was the humility. Notice the "A" in the title, implying there is more than one. He takes the same approach in the book, outlying how he developed his perspective and gives room for other people to have a different perspective, and even invites them to discuss it with him! It made me more open to reading the book, knowing I wasn't being sold dogma, and gave me room to critically analyze the author's perspective, compared to my own background.

ramblerman 5y ago
Ironically as a review, I'm not sure if this strengthens the case for reading it. If the best thing you can say is, the author was humble...

arximboldi 5y ago

I was very disappointed with this book. To be fair, I haven't even finish it. I was expecting something philosophical, this is, something that actually connect the philosophy and software design disciplines. Outside of the title however, there is no philosophy in this book. Just general typical practical "good practice" tips of the kind you find in blog posts, without much empirical nor philosophical discussion for them.

masterphilo 5y ago
It seems strange to assume anything truly "philosophical" when the main topic of the book is something as practical as software engineering/design. Even if he did try to shoehorn a few bits of metaphysics in, most of the book would've had to lean more on the practical side of the domain.

jackofalltrades 5y ago

So, in your opinion are Clean Code and Clean Architecture still relevant/updated? I've come more interested in the way I think about/produce code in the last couple of months and am searching for something that might be a good read on it - considering I'm mainly a JavaScript developer. I find that most of the concepts of SOLID, for example, are really hard to figure out in most of the code base of the projects I've worked/see online implemented in Node for example. It might be related to my lack of knowledge and understanding of said principles though, but I've seen a youtube video (https://www.youtube.com/watch?v=CnailTcJV_U https://www.youtube.com/watch?v=CnailTcJV_U) some months ago that showed me a "clean architecture" implementation that I've never really seen in any project I've fiddled with.

ratww 5y ago
In my opinion, the caveat on the article is very apt: Clean Code teaches rules, not principles. If you read it with a critical mind you'll get a lot of it, if you follow it blindly you'll get a lot of bad habits. Unfortunately programmers need some experience to be able to do it. IMO the same caveat applies to Clean Architecture: it is study material to architects, rather than something you can copy-paste into a new project. The reason it's dauting, IMO, is because there are some unnecessary concepts there that are unrelated to the "grand idea", and those small things might make sense for Bob Martin but might not make sense to you. If you want to understand it, I really like this article. I think it explains very well the "grand idea" of architectural templates like Clean/Hexagonal/Onion... and links it to Gary Berhnardt's Imperative-shell-functional-core: https://danuker.go.ro/the-grand-unified-theory-of-software-architecture.html https://danuker.go.ro/the-grand-unified-theory-of-software-a... Of course I also recommend Imperative-shell-functional-core itself: https://www.destroyallsoftware.com/talks/boundaries https://www.destroyallsoftware.com/talks/boundaries
- jackofalltrades 5y ago
  Thank you for your recommendations, I'll take a look on them.

dang 5y ago

Past threads related to the book: Book Review: A Philosophy of Software Design (2018) - https://news.ycombinator.com/item?id=26624057 https://news.ycombinator.com/item?id=26624057 - March 2021 (1 comment) Book Review: A Philosophy of Software Design - https://news.ycombinator.com/item?id=18331219 https://news.ycombinator.com/item?id=18331219 - Oct 2018 (51 comments) Notes on “A Philosophy of Software Design” - https://news.ycombinator.com/item?id=17906662 https://news.ycombinator.com/item?id=17906662 - Sept 2018 (32 comments)

neves 5y ago

This book is excellent. If I've had read it when I were a junior developer, I'd have advanced years of my understanding of software. Ousterhout is the inventor of one the most important unsung principle of software development: the Ousterhout's Dichotomy. "Ousterhout's Dichotomy, proposed by John Ousterhout as a software development paradigm, asserts that the world of application development is divided into two languages: a compiled language focusing on disk access and efficiency such as C, and a higher-level, typeless or loosely-typed scripting language with a simple, basic syntax." https://wiki.tcl-lang.org/page/Ousterhout%27s+Dichotomy https://wiki.tcl-lang.org/page/Ousterhout%27s+Dichotomy All your pandas, numpy, R belong to his

neves 5y ago

I'd really appreciate a a MOOC for this book.