Hacker News Reader

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!

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.

You’re creating a false dilemma. It’s entirely possible to be a disciplined programmer and use good tools.

And, yes, a teacher should care more about the skills than the tools, but Uncle Bob is actively against the tools, claiming that they impede learning the skills. Which is no more true than claiming that automatic transmissions or anti-spin in modern race cars impedes learning how to race.

There's no dilemma. I never said it wasn't possible. I'm saying that it's far more difficult to be disciplined oneself, than it is to learn some tools. Thus, it's far more interesting for a teacher to try and instill discipline in the students, than to teach the latest set of tools. The former is far more stable and will affect a person's behavior much more deeply, the latter will keep changing and can be added to a skillset within a week by reading some tutorials.

I don't think he's actively against those tools. I think he's actively against claims that those tools actually solve the problems developers deal with, instead of uncovering the true behavior that lies beneath those problems.

No, he really is against the tools. He is on the record as being opposed to static typing, optionals etc.

And by the way, noone is making the argument that tools solve all the problems developers deal with. But to say that actually, they solve none of them, is foolish. Optionals, to take one example of something Uncle Bob is against, prevents a large proportion of what is probably the most common runtime error, namely dereferencing a null pointer. And yes, Uncle Bob is right that it comes at the small expense, which is having to think more carefully up front about your data and your abstractions, and there is no doubt he is right that some programmers will feel constrained and will find and use whatever mechanisms exist to bypass the safety that this feature offers. But in much the same way, there are also some people who feel constrained by seat belts, hard hats, helmets, dust masks etc. and choose not to wear them, yet you don’t find many people who would argue that this makes them pointless and generally a bad idea.

No, he is not against the tools.

"I have nothing against tools like this. I’ve even contributed money to the Light Table project. I think that good software tools make it easier to write good software. However, tools are not the answer to the “Apocalypse”."

http://blog.cleancoder.com/uncle-bob/2017/10/04/CodeIsNotThe...

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.

A tool is short term, shallow, and goal-oriented. Building discipline and good practices permeates a person's life far more deeply than tools.

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.

I want both: Better tools and more disciplined programmers. The tools will catch errors, and that's great. But they won't catch all the errors, whereas disciplined programmers will work to minimize the potential of them.

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.

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.

> 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?..

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.

> 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".

I don’t see why we should make this a requirement of every programmer.

I don't see why we shouldn't.

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.

> 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.

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...

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).

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.

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.

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.

Because being lax leads to bugs.