7 ms·

> First, do no harm, then use like Light Table, Model Driven Engineering, and TLA+. Looking at some of Uncle Bob's other posts linked from this article, I don'

> First, do no harm, then use like Light Table, Model Driven Engineering, and TLA+. Looking at some of Uncle Bob's other posts linked from this article, I don't think that's what he's saying. He (Uncle Bob) goes on and on about discipline, but at the same time dismisses anything that might actually force programmers to be disciplined, like type systems that force you to check references for null before dereferencing them. For example, in http://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.html http://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.... he asks: "It is very risky to have nulls rampaging around the system out of control. The question is: Whose job is it to manage the nulls. The language? Or the programmer?" and goes on to answer: "Defects are the fault of programmers. It is programmers who create defects – not languages." Then he goes ranting about programmers who don't test their code, and if only they tested, such type systems would not be needed. Again: He dismisses the one thing that actually forces programmers to be disciplined and instead just wishes (against all evidence) that they were disciplined. To me, he seems to be saying "First, do no harm, then use tests, then nothing."

falcolas 9y ago
No tool will ever successfully enforce discipline. If anything, it makes people more lax. "I don't have to reason about whether this can be null, the type system takes care of that for me." "I don't have to worry about leaking memory, valgrind will let me know." "I don't have to pay attention to the road, Tesla's autopilot takes care of it for me." All the tools do is enforce a loop of compile -> make compiler happy -> compile.
- wasted_intel 9y ago
  So, you're advocating removing the "make compiler happy" step and you think that will lead to greater discipline? If the tool automatically fixed it, you'd have a point, but most if not all of the static analysis tools I've come across simply point to the error and leave it up to the developer to fix, which is the right thing to do, reinforcing good habits.
  - gregmac 9y ago
    Not OP, but I interpreted that as implying your goal should not be "make compiler happy" but "think about and write reasonable code that also of course compiles". If one's assumption is that because of a type system and other built-in protections a successful compile means no bugs, then that person is doomed to fail.
    - eradicatethots 9y ago
      I don’t see why we should make this a requirement of every programmer.
      - s73ver_ 9y ago
        I don't see why we shouldn't.
    - falcolas 9y ago
      Pretty much exactly this. You can't keep throwing tools at a job and expecting them to compensate for poor developers. You also need to keep with currently good developers to ensure that they don't become lazy, relying on the tooling instead of critical thinking.
      - Chris2048 9y ago
        > relying on the tooling instead of critical thinking If the tool is "type checking" a computerised logic/type-checking will be far more efficient that mentally checking such a thing. Computer type-check logic is a superior form of a subset of "critical thinking".
    - Chris2048 9y ago
      > a successful compile means no bugs Isn't that a strawman? Shouldn't we verify to what extent this mentality actually develops (I doubt it) rather than rebuild our methodologies around it - or at least begin by simply educating developers directly about the pitfalls of this assumption. Sometimes it feels like treating developer flaws as unfixable constants that can only be handled by process change, as opposed to developer improvement. Perhaps a symptom of hiring the cheapest devs en-masse?..
- cloverich 9y ago
  This overgeneralizes. When I started using strict null checking (in Typescript) I found it had an unexpected impact: I started writing code differently. Slowly, I also began _thinking_ about it differently. Ultimately you can't _make_ someone care if they don't want to. But if they already do care, some of these tools will make them better.
- adamlett 9y ago
  No tool will ever successfully enforce discipline. If anything, it makes people more lax. But the end goal is not disciplined programmers! It is better, safer and more timely software. Your argument applies just as well to safety equipment in cars and on heavy equipment, and you may be right that the reduced risk of being killed or maimed makes people more lax. But you can’t argue with the results: Far fewer people do in fact get killed or maimed!
  - mrleinad 9y ago
    Fewer errors get deployed to production code because tools help us catch them more often? Yes. Fewer errors get deployed to production code because programmers have a more rigorous discipline when creating software? Also yes. Which part should a teacher like Uncle Bob (I consider him as such) should care more about? People using tools or processes, or having them care about the discipline enough? I'll go with the latter. And if he seems dismissive about the former, is because he's trying to teach about discipline, which is far more difficult to teach, than to use a tool or follow some process.
    - erik_seaberg 9y ago
      I complain about quality a lot. I might almost have this superhuman level of discipline on my best days, and only then if business allows me to indulge it. But think about the worst programmer you've ever worked with. In his hands the tool is a much bigger win.
      - mrleinad 9y ago
        A tool is short term, shallow, and goal-oriented. Building discipline and good practices permeates a person's life far more deeply than tools.
        Illotus 9y ago
        Banking on discipline in any human endeavour seems to be fool's errand. You will get more reliable results by improving the environment, systems and tools. This can be seen in how much checklists have improved the quality and reliability in fields like medicine. We are in a field where we can literally codify the checklists to enforce them.
- lomnakkus 9y ago
  > All the tools do is enforce a loop of compile -> make compiler happy -> compile. Sorry, this is nonsense. Tools can eliminate whole classes of bugs from ever happening. I will never have a null pointer exception in a Haskell program, for example[1]. I'm not so sure what's so difficult to understand about this. [1] Alright, if we're being extremely nitpicky, it's possible to do really weird things with various language extensions which could conceivably cause similar things, but a) those are opt-in, and b) very rarely necessary, if ever except in the implementation of the runtime/language itself. They can also be localized per-module such that you know what code to be extra careful about.
- a-saleh 9y ago
  There are nuances. With this reasoning taken to extreme, would you in the end got rid of the compiler just force yourself to be more careful? And I kinda get your point, because I got in to the past to a point where I had passed through all of the checks for my PR with code that didn't actually work. I still think that checks I put in place for myself help me more than they make me more lax.
  - eradicatethots 9y ago
    I don’t get why being lax is a bad thing lol. You’re not being lax randomly, you’re being lax because you learned that empirically you can afford it. Instead of wasting that energy on whatever discipline you used to have to apply, you can spend it on something of value. I don’t think it’s smart to get upset about life getting easier.
    - s73ver_ 9y ago
      Because being lax leads to bugs.
- mannykannot 9y ago
  Some people may have those attitudes, but if so, then they are demonstrating a lack of discipline. The intended purpose of tools is not to enforce discipline, but to enable disciplined people to do a better job.
- sanderjd 9y ago
  I can attest: I wrote Ruby for many years, recently I've only been writing in languages with much stronger static analysis capabilities. I had to be much more disciplined when writing and reviewing Ruby code. Inevitably, I slipped up frequently in both disciplines, resulting in lots of bugs in the software and a chronic nagging worry in my psyche. I don't need to be as disciplined now, but I'm creating fewer bugs and sleeping better. I feel that these are good things and much more important than a theoretical concern about it making me "more lax". This is just my experience, your mileage may vary, etc...
  - Jtsummers 9y ago
    The benefit of building checks into our languages (like static typing, design by contracts, etc.) is that they let you focus on higher level concerns. If I have a language that will let me say that a Foo is one of {1,2,3} and will never allow any other integer variable's value to be put into a Foo variable (without explicit casting), I can now focus on my use of Foos and not have to add a type invariant test to every function that consumes or produces a Foo. This doesn't make me less disciplined. It shifts the discipline. The disciplined programmer can spend all day putting in type invariant checks on their code. Or the disciplined programmer can spend 5 minutes determining what types they need to use, and spend the rest of the day writing out the actual business logic instead of a shit ton of boiler plate code and/or unit tests (which are hopefully comprehensive enough to catch these errors).
aidenn0 9y ago
Indeed, for any reliability tool not named "unit tests" he comes off as saying "Just write better code!" It really feels like someone peddling their pet diet, and when confronted with other ways of managing weight they just say "You don't need to do that, just eat less food!"
mrleinad 9y ago
That's quite a common issue when you're trying to emphasize a specific point. Uncle Bob's trying to make software developers care about their craft. He seems dismissive of any other techniques, but I think that's because he really wants people who read his posts and watch his videos to understand that specific point. If you already understand that point, then you're not the audience he's trying to talk to, and you're free to enhance your craft with any tools you see fit, because you've got the foundations right. Unless you understand that he's trying to teach people something that's really difficult to fully understand and implement on a daily basis, I don't think you'll be able to understand why he's so dismissive about anything else.
- elihu 9y ago
  From "The Dark Path": > Now, ask yourself why these defects happen too often. If your answer is that our languages don’t prevent them, then I strongly suggest that you quit your job and never think about being a programmer again; because defects are never the fault of our languages. Defects are the fault of programmers. It is programmers who create defects – not languages. http://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.html http://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.... I think that software defects happen too often because the most widely used programming languages don't do enough to prevent them. That makes me the audience of this statement. And he says that I should abandon programming. I think that's rather presumptuous of him. (I also think that on average programmers aren't careful enough and don't spend enough time making sure their stuff doesn't break, but I see that as primarily an economic problem. Most software companies are rewarded more for delivering features than closing the security holes. We can attack that problem either by finding some way to convince software vendors to pay for the tremendously expensive effort of testing software, or we can reduce the effort required by using stronger type systems and formal methods. The latter seems more realistic and attainable.)
- tom_mellior 9y ago
  I don't agree with your interpretation, and neither does the user "unclebobmartin" here on HN: https://news.ycombinator.com/item?id=15420618 https://news.ycombinator.com/item?id=15420618 This is not about emphasizing a point about caring for your craft. It's about open hostility to certain things that are not his particular preferred thing.
unclebobmartin 9y ago
Type systems do not force programmers to be disciplined. Type systems tempt programmers to cheat.
- empthought 9y ago
  What do you mean by "cheat" here? Is it "cheating" to no longer write the kind of tests that type systems render obsolete? Because that's the main difference between programming in a language with a strong static type system and one without.
- Jtsummers 9y ago
  I cannot conceive of how type systems enable "cheating". Mostly, I see people cheating by reducing everything to a handful of types and not exercising the system as much as it might be. An expressive type system allows me to formally specify parts of my system, and have the language itself enforce those constraints. It's much better for me to be able to say: type Byte is mod 256; And now any instance of Byte cannot end up larger than 256. In this example, most languages can achieve the same thing as they have an 8-bit unsigned int type. But in Ada I can do this for any arbitrary (positive, I assume, never tried negative) integer after the mod (up the the system's Integer'Last). I don't have to test every time I assign into a variable of this type. I don't have to test after every computation to make sure it's still within the range. It just happens for me. This isn't cheating, this is using my tools to enable me to focus on the overall design and not the menial boilerplate of range checking everything.
  - gnaritas 9y ago
    I don't think he means they enable cheating, I think he means they frustrate developers who then try and find ways around the type system. Types pissing you off, just declare everything object and cast when you need to. You're talking about leveraging the type system to help you, but that requires fully liking and understanding the type system, many devs don't understand the type systems they're forced to work with, don't understand how to leverage it, and don't like creating new types. Most devs have a primitive obsession and don't much create their own data types.

falcolas 9y ago

No tool will ever successfully enforce discipline. If anything, it makes people more lax. "I don't have to reason about whether this can be null, the type system takes care of that for me." "I don't have to worry about leaking memory, valgrind will let me know." "I don't have to pay attention to the road, Tesla's autopilot takes care of it for me." All the tools do is enforce a loop of compile -> make compiler happy -> compile.

wasted_intel 9y ago
So, you're advocating removing the "make compiler happy" step and you think that will lead to greater discipline? If the tool automatically fixed it, you'd have a point, but most if not all of the static analysis tools I've come across simply point to the error and leave it up to the developer to fix, which is the right thing to do, reinforcing good habits.
- gregmac 9y ago
  Not OP, but I interpreted that as implying your goal should not be "make compiler happy" but "think about and write reasonable code that also of course compiles". If one's assumption is that because of a type system and other built-in protections a successful compile means no bugs, then that person is doomed to fail.
  - eradicatethots 9y ago
    I don’t see why we should make this a requirement of every programmer.
    - s73ver_ 9y ago
      I don't see why we shouldn't.
  - falcolas 9y ago
    Pretty much exactly this. You can't keep throwing tools at a job and expecting them to compensate for poor developers. You also need to keep with currently good developers to ensure that they don't become lazy, relying on the tooling instead of critical thinking.
    - Chris2048 9y ago
      > relying on the tooling instead of critical thinking If the tool is "type checking" a computerised logic/type-checking will be far more efficient that mentally checking such a thing. Computer type-check logic is a superior form of a subset of "critical thinking".
  - Chris2048 9y ago
    > a successful compile means no bugs Isn't that a strawman? Shouldn't we verify to what extent this mentality actually develops (I doubt it) rather than rebuild our methodologies around it - or at least begin by simply educating developers directly about the pitfalls of this assumption. Sometimes it feels like treating developer flaws as unfixable constants that can only be handled by process change, as opposed to developer improvement. Perhaps a symptom of hiring the cheapest devs en-masse?..
cloverich 9y ago
This overgeneralizes. When I started using strict null checking (in Typescript) I found it had an unexpected impact: I started writing code differently. Slowly, I also began _thinking_ about it differently. Ultimately you can't _make_ someone care if they don't want to. But if they already do care, some of these tools will make them better.
adamlett 9y ago
No tool will ever successfully enforce discipline. If anything, it makes people more lax. But the end goal is not disciplined programmers! It is better, safer and more timely software. Your argument applies just as well to safety equipment in cars and on heavy equipment, and you may be right that the reduced risk of being killed or maimed makes people more lax. But you can’t argue with the results: Far fewer people do in fact get killed or maimed!
- mrleinad 9y ago
  Fewer errors get deployed to production code because tools help us catch them more often? Yes. Fewer errors get deployed to production code because programmers have a more rigorous discipline when creating software? Also yes. Which part should a teacher like Uncle Bob (I consider him as such) should care more about? People using tools or processes, or having them care about the discipline enough? I'll go with the latter. And if he seems dismissive about the former, is because he's trying to teach about discipline, which is far more difficult to teach, than to use a tool or follow some process.
  - erik_seaberg 9y ago
    I complain about quality a lot. I might almost have this superhuman level of discipline on my best days, and only then if business allows me to indulge it. But think about the worst programmer you've ever worked with. In his hands the tool is a much bigger win.
    - mrleinad 9y ago
      A tool is short term, shallow, and goal-oriented. Building discipline and good practices permeates a person's life far more deeply than tools.
      - Illotus 9y ago
        Banking on discipline in any human endeavour seems to be fool's errand. You will get more reliable results by improving the environment, systems and tools. This can be seen in how much checklists have improved the quality and reliability in fields like medicine. We are in a field where we can literally codify the checklists to enforce them.
lomnakkus 9y ago
> All the tools do is enforce a loop of compile -> make compiler happy -> compile. Sorry, this is nonsense. Tools can eliminate whole classes of bugs from ever happening. I will never have a null pointer exception in a Haskell program, for example[1]. I'm not so sure what's so difficult to understand about this. [1] Alright, if we're being extremely nitpicky, it's possible to do really weird things with various language extensions which could conceivably cause similar things, but a) those are opt-in, and b) very rarely necessary, if ever except in the implementation of the runtime/language itself. They can also be localized per-module such that you know what code to be extra careful about.
a-saleh 9y ago
There are nuances. With this reasoning taken to extreme, would you in the end got rid of the compiler just force yourself to be more careful? And I kinda get your point, because I got in to the past to a point where I had passed through all of the checks for my PR with code that didn't actually work. I still think that checks I put in place for myself help me more than they make me more lax.
- eradicatethots 9y ago
  I don’t get why being lax is a bad thing lol. You’re not being lax randomly, you’re being lax because you learned that empirically you can afford it. Instead of wasting that energy on whatever discipline you used to have to apply, you can spend it on something of value. I don’t think it’s smart to get upset about life getting easier.
  - s73ver_ 9y ago
    Because being lax leads to bugs.
mannykannot 9y ago
Some people may have those attitudes, but if so, then they are demonstrating a lack of discipline. The intended purpose of tools is not to enforce discipline, but to enable disciplined people to do a better job.
sanderjd 9y ago
I can attest: I wrote Ruby for many years, recently I've only been writing in languages with much stronger static analysis capabilities. I had to be much more disciplined when writing and reviewing Ruby code. Inevitably, I slipped up frequently in both disciplines, resulting in lots of bugs in the software and a chronic nagging worry in my psyche. I don't need to be as disciplined now, but I'm creating fewer bugs and sleeping better. I feel that these are good things and much more important than a theoretical concern about it making me "more lax". This is just my experience, your mileage may vary, etc...
- Jtsummers 9y ago
  The benefit of building checks into our languages (like static typing, design by contracts, etc.) is that they let you focus on higher level concerns. If I have a language that will let me say that a Foo is one of {1,2,3} and will never allow any other integer variable's value to be put into a Foo variable (without explicit casting), I can now focus on my use of Foos and not have to add a type invariant test to every function that consumes or produces a Foo. This doesn't make me less disciplined. It shifts the discipline. The disciplined programmer can spend all day putting in type invariant checks on their code. Or the disciplined programmer can spend 5 minutes determining what types they need to use, and spend the rest of the day writing out the actual business logic instead of a shit ton of boiler plate code and/or unit tests (which are hopefully comprehensive enough to catch these errors).

aidenn0 9y ago

Indeed, for any reliability tool not named "unit tests" he comes off as saying "Just write better code!" It really feels like someone peddling their pet diet, and when confronted with other ways of managing weight they just say "You don't need to do that, just eat less food!"

mrleinad 9y ago

That's quite a common issue when you're trying to emphasize a specific point. Uncle Bob's trying to make software developers care about their craft. He seems dismissive of any other techniques, but I think that's because he really wants people who read his posts and watch his videos to understand that specific point. If you already understand that point, then you're not the audience he's trying to talk to, and you're free to enhance your craft with any tools you see fit, because you've got the foundations right. Unless you understand that he's trying to teach people something that's really difficult to fully understand and implement on a daily basis, I don't think you'll be able to understand why he's so dismissive about anything else.

elihu 9y ago
From "The Dark Path": > Now, ask yourself why these defects happen too often. If your answer is that our languages don’t prevent them, then I strongly suggest that you quit your job and never think about being a programmer again; because defects are never the fault of our languages. Defects are the fault of programmers. It is programmers who create defects – not languages. http://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.html http://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.... I think that software defects happen too often because the most widely used programming languages don't do enough to prevent them. That makes me the audience of this statement. And he says that I should abandon programming. I think that's rather presumptuous of him. (I also think that on average programmers aren't careful enough and don't spend enough time making sure their stuff doesn't break, but I see that as primarily an economic problem. Most software companies are rewarded more for delivering features than closing the security holes. We can attack that problem either by finding some way to convince software vendors to pay for the tremendously expensive effort of testing software, or we can reduce the effort required by using stronger type systems and formal methods. The latter seems more realistic and attainable.)
tom_mellior 9y ago
I don't agree with your interpretation, and neither does the user "unclebobmartin" here on HN: https://news.ycombinator.com/item?id=15420618 https://news.ycombinator.com/item?id=15420618 This is not about emphasizing a point about caring for your craft. It's about open hostility to certain things that are not his particular preferred thing.

unclebobmartin 9y ago

Type systems do not force programmers to be disciplined. Type systems tempt programmers to cheat.

empthought 9y ago
What do you mean by "cheat" here? Is it "cheating" to no longer write the kind of tests that type systems render obsolete? Because that's the main difference between programming in a language with a strong static type system and one without.
Jtsummers 9y ago
I cannot conceive of how type systems enable "cheating". Mostly, I see people cheating by reducing everything to a handful of types and not exercising the system as much as it might be. An expressive type system allows me to formally specify parts of my system, and have the language itself enforce those constraints. It's much better for me to be able to say: type Byte is mod 256; And now any instance of Byte cannot end up larger than 256. In this example, most languages can achieve the same thing as they have an 8-bit unsigned int type. But in Ada I can do this for any arbitrary (positive, I assume, never tried negative) integer after the mod (up the the system's Integer'Last). I don't have to test every time I assign into a variable of this type. I don't have to test after every computation to make sure it's still within the range. It just happens for me. This isn't cheating, this is using my tools to enable me to focus on the overall design and not the menial boilerplate of range checking everything.
- gnaritas 9y ago
  I don't think he means they enable cheating, I think he means they frustrate developers who then try and find ways around the type system. Types pissing you off, just declare everything object and cast when you need to. You're talking about leveraging the type system to help you, but that requires fully liking and understanding the type system, many devs don't understand the type systems they're forced to work with, don't understand how to leverage it, and don't like creating new types. Most devs have a primitive obsession and don't much create their own data types.