6 ms·

Completely agree with this. The post where Martin derides modern, type-safe languages (Kotlin and Swift) [0] was just unbelievable to me. "Ask yourself why we

by _wc0m 9y ago

Completely agree with this. The post where Martin derides modern, type-safe languages (Kotlin and Swift) [0] was just unbelievable to me. "Ask yourself why we are trying to plug defects with language features. The answer ought to be obvious. We are trying to plug these defects because these defects happen too often. 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." Arrgh! Until we get out of this ridiculous, macho, victim-blaming mindset, software development will be stuck in the relative dark ages. More, better, safer languages, please! [0] http://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.html http://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath....

oblio 9y ago
Somebody should show Uncle Bob this: https://youtu.be/fPF4fBGNK0U https://youtu.be/fPF4fBGNK0U My point being: yes, if we'd be perfect drivers at all times and in all weather conditions there would be no more accidents. Luckily for us auto designers haven't adopted this perspective :)
- msla 9y ago
  You just reminded me of my old driving instructor. "All accidents are your fault. Got rear-ended? Shouldn't have been driving so slowly, or shouldn't have stopped. Got t-boned? Should have looked more closely at the intersection. Skidded on ice? Shouldn't have been driving so quickly, or turned so sharply. Yes, you avoided the pedestrian, but that isn't an excuse. In extremis, you shouldn't have been driving that day at all, and you do always have that option, so it's your fault regardless." The line between empowerment and victim blaming is surprisingly thin. ;)
- blktiger 9y ago
  This is a video of a crash _test_. Personally, I'm not sure TDD is necessarily the answer but even with typed code you should still have tests. You just don't need tests for things covered by the type system. Of course, it also depends on what the software is being used for. If I create a script for automating something just for me, I don't see any reason to add repeatable tests.
- GuiA 9y ago
  The top comment on that video, in light of the points being made in this thread, is quite ironic: "And because of this 'improved safety' we have millions of drivers out there who drive even faster and take even more risks, because they think the new cars are so much safer. " (of course this comment is silly, the number of motor vehicle deaths per capita is about a third of what it was 50 years ago: https://en.wikipedia.org/wiki/List_of_motor_vehicle_deaths_in_U.S._by_year#/media/File:U.S._traffic_deaths_as_fraction_of_total_population_1900-2010.png https://en.wikipedia.org/wiki/List_of_motor_vehicle_deaths_i...)
- unclebobmartin 9y ago
  That was cool!
eradicatethots 9y ago
Personally I’d prefer my language to let me fuck up.
- Devagamster 9y ago
  y tho. you can have safety and expressivity...
  - milesvp 9y ago
    it's often not about expressivity, it's about conciseness. It's much easier to say a correct statement than it is to prove the statement correct. This seems to be the main cost to stongly typed static languages, all the time spent proving to the compiler that this thing is actually compatible with that thing.
    - bad_user 9y ago
      What strongly typed static languages are you talking about? > proving to the compiler that this thing is actually compatible with that thing I used to have this opinion, but nowadays I think that time is actually spent proving to myself that I'm right, which is always a good thing. Having a compiler to do the hand holding is not such a bad thing, because the alternative is println-development. What happens in a dynamic language is that you have to load in your head the shape of the data your working with, the API and everything really. Your head can't hold that much for anything that is bigger than a simple script, so you have to constantly execute and verify (in the REPL, in the browser, with a unit test, etc) each line of code that you write, before writing the next line of code. This is why people complain about compilation speed in Scala, Haskell, etc, even if they miss they point, because even a slow, static compiler will improve efficiency, since you no longer have to compile and execute each line of code before you write the next one. And yes, in my experience this is exactly what happens in big code bases built in dynamic languages, short of being really sloppy and introducing lots of bugs.
    - kibwen 9y ago
      As opposed to the main cost to dynamically-typed languages, all the time spent proving to the test suite and proving to your teammates that this thing is actually compatible with that thing. And I say this as someone who adores Python! Dynamic typing does not magically make problems go away, it just makes them easier to ignore (whether deliberately or accidentally).
deleted 9y ago
[deleted]
s73ver_ 9y ago
I agree with both, really. Those defects are our fault, and they are there because we aren't careful enough with the code we write. We know about these things, and yet, we don't work to prevent them. We either handwave them away, or we give into management pressures to just get the thing out the door. Now, that said, one of the ways you can work to prevent these things is to use better tools. Like languages that don't let you make those kinds of mistakes as easily.
jwdunne 9y ago
I can see how that would be popular but it's wrong. You can take that same reasoning and say we should build web projects in C or assembly because any defects are our own fault. Let's be honest. That's bollocks. It's just the same old "real programmers use X" line. I'm sure there's an XKCD that parodies it. Sure we need more discipline. Who doesn't? Yet that discipline is far better spent on doing what the compiler can't. It makes no sense doing what a computer can do unless it's really necessary. That's why we're programmers after all, right?
- ncds42 9y ago
  Using C as an example is a straw man. There's been A LOT of progress since C. Can you say the same for Java or Python? Not as much.
  - jwdunne 9y ago
    No it's not. It's the same argument we've had about any kind of progress in programming languages since we started using higher level languages (I.e Fortran and up).
AlexCoventry 9y ago
His argument mostly makes sense up to the point where he says tests are the only solution... Why not default to overriding the safeties, then use them where your reasoning says they ought to hold? Cheaper than writing a bunch of tests just to guard against null pointers.
ncds42 9y ago
He didn't condemn Kotlin and swift. He is saying that they aren't necessary and don't solve the original problem. That the constant search for a new framework or of language that will fix everything is a futile attempt to avoid learning how to more effectively code with the tools you already have.
- piaste 9y ago
  In one of the linked posts he says that 100% test coverage might not be truly achievable, but it's nonetheless a valid asymptote to aspire to. I think that exact argument applies to designing ever-safer, ever-better languages. You might never have the perfect tools that ensure 100% program correctness, but it's sure as hell what a tool-maker should aspire to.

by _wc0m 9y ago

oblio 9y ago

Somebody should show Uncle Bob this: https://youtu.be/fPF4fBGNK0U https://youtu.be/fPF4fBGNK0U My point being: yes, if we'd be perfect drivers at all times and in all weather conditions there would be no more accidents. Luckily for us auto designers haven't adopted this perspective :)

msla 9y ago
You just reminded me of my old driving instructor. "All accidents are your fault. Got rear-ended? Shouldn't have been driving so slowly, or shouldn't have stopped. Got t-boned? Should have looked more closely at the intersection. Skidded on ice? Shouldn't have been driving so quickly, or turned so sharply. Yes, you avoided the pedestrian, but that isn't an excuse. In extremis, you shouldn't have been driving that day at all, and you do always have that option, so it's your fault regardless." The line between empowerment and victim blaming is surprisingly thin. ;)
blktiger 9y ago
This is a video of a crash _test_. Personally, I'm not sure TDD is necessarily the answer but even with typed code you should still have tests. You just don't need tests for things covered by the type system. Of course, it also depends on what the software is being used for. If I create a script for automating something just for me, I don't see any reason to add repeatable tests.
GuiA 9y ago
The top comment on that video, in light of the points being made in this thread, is quite ironic: "And because of this 'improved safety' we have millions of drivers out there who drive even faster and take even more risks, because they think the new cars are so much safer. " (of course this comment is silly, the number of motor vehicle deaths per capita is about a third of what it was 50 years ago: https://en.wikipedia.org/wiki/List_of_motor_vehicle_deaths_in_U.S._by_year#/media/File:U.S._traffic_deaths_as_fraction_of_total_population_1900-2010.png https://en.wikipedia.org/wiki/List_of_motor_vehicle_deaths_i...)
unclebobmartin 9y ago
That was cool!

eradicatethots 9y ago

Personally I’d prefer my language to let me fuck up.

Devagamster 9y ago
y tho. you can have safety and expressivity...
- milesvp 9y ago
  it's often not about expressivity, it's about conciseness. It's much easier to say a correct statement than it is to prove the statement correct. This seems to be the main cost to stongly typed static languages, all the time spent proving to the compiler that this thing is actually compatible with that thing.
  - bad_user 9y ago
    What strongly typed static languages are you talking about? > proving to the compiler that this thing is actually compatible with that thing I used to have this opinion, but nowadays I think that time is actually spent proving to myself that I'm right, which is always a good thing. Having a compiler to do the hand holding is not such a bad thing, because the alternative is println-development. What happens in a dynamic language is that you have to load in your head the shape of the data your working with, the API and everything really. Your head can't hold that much for anything that is bigger than a simple script, so you have to constantly execute and verify (in the REPL, in the browser, with a unit test, etc) each line of code that you write, before writing the next line of code. This is why people complain about compilation speed in Scala, Haskell, etc, even if they miss they point, because even a slow, static compiler will improve efficiency, since you no longer have to compile and execute each line of code before you write the next one. And yes, in my experience this is exactly what happens in big code bases built in dynamic languages, short of being really sloppy and introducing lots of bugs.
  - kibwen 9y ago
    As opposed to the main cost to dynamically-typed languages, all the time spent proving to the test suite and proving to your teammates that this thing is actually compatible with that thing. And I say this as someone who adores Python! Dynamic typing does not magically make problems go away, it just makes them easier to ignore (whether deliberately or accidentally).

deleted 9y ago

[deleted]

s73ver_ 9y ago

I agree with both, really. Those defects are our fault, and they are there because we aren't careful enough with the code we write. We know about these things, and yet, we don't work to prevent them. We either handwave them away, or we give into management pressures to just get the thing out the door. Now, that said, one of the ways you can work to prevent these things is to use better tools. Like languages that don't let you make those kinds of mistakes as easily.

jwdunne 9y ago

I can see how that would be popular but it's wrong. You can take that same reasoning and say we should build web projects in C or assembly because any defects are our own fault. Let's be honest. That's bollocks. It's just the same old "real programmers use X" line. I'm sure there's an XKCD that parodies it. Sure we need more discipline. Who doesn't? Yet that discipline is far better spent on doing what the compiler can't. It makes no sense doing what a computer can do unless it's really necessary. That's why we're programmers after all, right?

ncds42 9y ago
Using C as an example is a straw man. There's been A LOT of progress since C. Can you say the same for Java or Python? Not as much.
- jwdunne 9y ago
  No it's not. It's the same argument we've had about any kind of progress in programming languages since we started using higher level languages (I.e Fortran and up).

AlexCoventry 9y ago

His argument mostly makes sense up to the point where he says tests are the only solution... Why not default to overriding the safeties, then use them where your reasoning says they ought to hold? Cheaper than writing a bunch of tests just to guard against null pointers.

ncds42 9y ago

He didn't condemn Kotlin and swift. He is saying that they aren't necessary and don't solve the original problem. That the constant search for a new framework or of language that will fix everything is a futile attempt to avoid learning how to more effectively code with the tools you already have.

piaste 9y ago
In one of the linked posts he says that 100% test coverage might not be truly achievable, but it's nonetheless a valid asymptote to aspire to. I think that exact argument applies to designing ever-safer, ever-better languages. You might never have the perfect tools that ensure 100% program correctness, but it's sure as hell what a tool-maker should aspire to.