4 ms·

I find the lack of discussion of type systems really surprising in these sorts of discussions and books. Effective use of type systems is a killer factor for me

I find the lack of discussion of type systems really surprising in these sorts of discussions and books. Effective use of type systems is a killer factor for me for creating clean, safe, readable and maintainable software designs. When used correctly, strong static type checking make certain kinds of bugs impossible, spare you from writing many kinds of tedious tests that often get in the way of refactoring, serve as documentation, and make refactoring/maintenance an order of magnitude faster and safer. Even when a type checker isn't available, avoiding dynamic behaviour is very often the safer way to go so learning how to think in that way is still beneficial. Most of these minor topics like how big a function should be, what to name your variables, or even if you write tests before/after coding... it's like trying to come up with general rules on how to write essays, creating graphic designs, or how to cook. "It depends" on the context and juggling different priorities each time. It's the kind of thing you only learn properly through practice (https://en.wikipedia.org/wiki/Tacit_knowledge https://en.wikipedia.org/wiki/Tacit_knowledge), so there's only so much to gain in reading about it or discussing it after you've defined the no-brainer things to always do and always avoid.

WillAdams 2y ago
That was exactly the approach taken by Prof. Ousterhout in setting up the class which lead to this book --- rather than just having students turn in working code for a grade, the code is reviewed with the student and the student then works to make it better --- in turn, the 2nd edition of the book was informed by the experience of teaching the class and the author actually changed his position based on the experience gained.
- deleted 2y ago
  [deleted]
- seanwilson 2y ago
  Why is that convincing though? Students aren't experienced coders, aren't working in large teams, and student assignments aren't like long-term large commercial projects. If you mean the additions here https://web.stanford.edu/~ouster/cgi-bin/book.php https://web.stanford.edu/~ouster/cgi-bin/book.php, I read these and it still sounds like general rules of thumb you'll only really learn and understand by practicing a lot e.g. "In my experience, the sweet spot is to implement new modules in a somewhat general-purpose fashion" "Having good taste is an important part of being a good software designer".
  - WillAdams 2y ago
    It's better credentials and experiential basis than most other programming books. Moreover, it is the students' inexperience which give this text credence --- since it results in their making errors and poor architectural/design choices it affords the chance of correction. I think it is remarkable that the author switched from "modules should be specialized" to "modules should be generalized" (rough paraphrasing, mailed my copy to Brazil and waiting to buy a replacement). If you know of other books which you merit recommendation and which have a similar or better context for their authorship and exposition, I would be glad to hear of them.
    - seanwilson 2y ago
      > It's better credentials and experiential basis than most other programming books. When considering coding advice, I just don't find credentials or the results of a coding experiment matter much, especially if it involves students. I run through the scenarios in my head and pick the option that makes sense given the context and competing priorities. > I think it is remarkable that the author switched from "modules should be specialized" to "modules should be generalized" (rough paraphrasing, mailed my copy to Brazil and waiting to buy a replacement). The link I posted has a PDF with the content I think. I guess I don't find the limited example involving a few function signatures compelling (a student assignment to write a basic text editor) or understand why I need to pick whether to trend towards modules being specialized or generalized... you treat it on a case-by-case basis, pick the one that has the most benefits given the context and be open to changing later when it makes sense? Outside of a few rules, it's boring but "it depends" really is the answer to most of these debates. Similar with how long functions should be, writing comments and how to name variables. > If you know of other books which you merit recommendation and which have a similar or better context for their authorship and exposition, I would be glad to hear of them. Software Engineering at Google is probably relevant for large projects: https://abseil.io/resources/swe-book https://abseil.io/resources/swe-book The rest probably best comes from practice, that's how I learned most of what I know here. I'm didn't for example become a fan of strong static types because of advice based on credentials or experiments, but from experience coding with and without types.
jghn 2y ago
Because the pendulum of typing hadn't swung back to static being in vogue when the Philosophy of Software Design came out. At the time you had mostly the Scala & Haskell people standing in a corner screaming until they (well, we as I was one of them) were blue in the face about reducing "certain types of bugs", and making impossible states impossible. Since then, everyone and their brother is on the static typing train. And from that lens you're right. It seems like an omission. Give it another 10 years and people will probably think the opposite.
- deleted 2y ago
  [deleted]
pclmulqdq 2y ago
Type systems and type-based coding patterns are very hip right now, but they weren't 6 years ago. That is partly because the type systems in the main languages in use 6 years ago were hack jobs (to put it politely). I do expect the pendulum to swing against type systems at some point soon for the same reasons it swung against OOP: Too much heavy lifting done by something that's hidden from the programmer, encouraging people to be "too clever," etc. Like OOP, algebraic types are a tool that have to be used well, and the current users are people who really like type systems and do use them well. It's only a matter of time before the tool gets into the hands of the average programmer, and then we will see how terribly a great type system can hurt you.

WillAdams 2y ago

That was exactly the approach taken by Prof. Ousterhout in setting up the class which lead to this book --- rather than just having students turn in working code for a grade, the code is reviewed with the student and the student then works to make it better --- in turn, the 2nd edition of the book was informed by the experience of teaching the class and the author actually changed his position based on the experience gained.

deleted 2y ago
[deleted]
seanwilson 2y ago
Why is that convincing though? Students aren't experienced coders, aren't working in large teams, and student assignments aren't like long-term large commercial projects. If you mean the additions here https://web.stanford.edu/~ouster/cgi-bin/book.php https://web.stanford.edu/~ouster/cgi-bin/book.php, I read these and it still sounds like general rules of thumb you'll only really learn and understand by practicing a lot e.g. "In my experience, the sweet spot is to implement new modules in a somewhat general-purpose fashion" "Having good taste is an important part of being a good software designer".
- WillAdams 2y ago
  It's better credentials and experiential basis than most other programming books. Moreover, it is the students' inexperience which give this text credence --- since it results in their making errors and poor architectural/design choices it affords the chance of correction. I think it is remarkable that the author switched from "modules should be specialized" to "modules should be generalized" (rough paraphrasing, mailed my copy to Brazil and waiting to buy a replacement). If you know of other books which you merit recommendation and which have a similar or better context for their authorship and exposition, I would be glad to hear of them.
  - seanwilson 2y ago
    > It's better credentials and experiential basis than most other programming books. When considering coding advice, I just don't find credentials or the results of a coding experiment matter much, especially if it involves students. I run through the scenarios in my head and pick the option that makes sense given the context and competing priorities. > I think it is remarkable that the author switched from "modules should be specialized" to "modules should be generalized" (rough paraphrasing, mailed my copy to Brazil and waiting to buy a replacement). The link I posted has a PDF with the content I think. I guess I don't find the limited example involving a few function signatures compelling (a student assignment to write a basic text editor) or understand why I need to pick whether to trend towards modules being specialized or generalized... you treat it on a case-by-case basis, pick the one that has the most benefits given the context and be open to changing later when it makes sense? Outside of a few rules, it's boring but "it depends" really is the answer to most of these debates. Similar with how long functions should be, writing comments and how to name variables. > If you know of other books which you merit recommendation and which have a similar or better context for their authorship and exposition, I would be glad to hear of them. Software Engineering at Google is probably relevant for large projects: https://abseil.io/resources/swe-book https://abseil.io/resources/swe-book The rest probably best comes from practice, that's how I learned most of what I know here. I'm didn't for example become a fan of strong static types because of advice based on credentials or experiments, but from experience coding with and without types.

jghn 2y ago

Because the pendulum of typing hadn't swung back to static being in vogue when the Philosophy of Software Design came out. At the time you had mostly the Scala & Haskell people standing in a corner screaming until they (well, we as I was one of them) were blue in the face about reducing "certain types of bugs", and making impossible states impossible. Since then, everyone and their brother is on the static typing train. And from that lens you're right. It seems like an omission. Give it another 10 years and people will probably think the opposite.

deleted 2y ago
[deleted]

pclmulqdq 2y ago

Type systems and type-based coding patterns are very hip right now, but they weren't 6 years ago. That is partly because the type systems in the main languages in use 6 years ago were hack jobs (to put it politely). I do expect the pendulum to swing against type systems at some point soon for the same reasons it swung against OOP: Too much heavy lifting done by something that's hidden from the programmer, encouraging people to be "too clever," etc. Like OOP, algebraic types are a tool that have to be used well, and the current users are people who really like type systems and do use them well. It's only a matter of time before the tool gets into the hands of the average programmer, and then we will see how terribly a great type system can hurt you.