3 ms·

To me, the author is like someone who will never really learn to swim well because he can't let go of swimming aids. Dependence on crutches like compile time ch

To me, the author is like someone who will never really learn to swim well because he can't let go of swimming aids. Dependence on crutches like compile time checking and programming assertions might let you fake it, but there are more productive ways (and languages) to write working code. 1. Compile time checking can't catch most non-trivial bugs. Even if you swear by it, given the advances in Java IDEs, I would have to be quite lazy (or careless) to write Java code that doesn't compile. 2. Programming assertions - really? That's what unit testing is for. I like his point about being a testing masochist, but it doesn't sound like he's going about it the right way. 3. Having other programmers inspect your code can be helpful, but to me it's a luxury that you often can't afford. "If I could bring this kind of a system to fruition, meeting all its requirements and budget and schedule constraints, just by conscientiously applying a slew of techniques for uncovering my programming failings before they got into the final product, then I knew that I would be able to fake it for the rest of my career." The author claims his techniques have allowed him to create a good end-product, but at what cost? I could 'fake it' for the rest of my career, or I could invest more effort in learning how to write better code faster in the first place.

nostrademons 18y ago
"I could 'fake it' for the rest of my career, or I could invest more effort in learning how to write better code faster in the first place." Uh, the techniques he describes are how you write better code faster in the first place. There's no magic "better code" fairy that comes along and instantly makes you a master programmer. You get better by deliberately seeking out ways in which you're failing, and then correcting them. And you use the techniques the article describes - code reviews, assertion, unit tests, and static typing - to do that. Eventually, those techniques become internalized, so that you still do them even when you take away the crutch of language and programming environment. Notice how studies of master Smalltalk and Erlang programmers found that they just don't make type errors, and that when you add a static type checker to those languages, existing programs pass unmodified? A lot of people have taken this as evidence that static typing isn't necessary. But there's another interpretation: master programmers write their programs as if they were statically-typed, even if the language itself does not require or enforce this. The reason they can get away with fast-and-loose programming languages is because they've already disciplined themselves into automatically doing what the strict programming languages enforce. And anecdotally, the vast body of crappy PHP and JavaScript code seems to support this interpretation.
ellyagg 18y ago
That's what unit testing is for? True, and do you understand the trade-offs? Unit testing is far more time consuming than assertions. Moreover, you're forced to write artificially short routines, routines of a length that research has shown to have a higher defect ratio. For myself, I've not yet been convinced that the costs/benefits of unit testing surpass the costs/benefits of assertions, at least when you're a small team working on end user software.
- rimantas 18y ago
  "Moreover, you're forced to write artificially short routines, routines of a length that research has shown to have a higher defect ratio" [citation needed] So far I've only seen advice to write shorter routines.
  - ramchip 18y ago
    Indeed, I don't see how smaller, more manageable pieces would be more likely to be defective.
    - jibiki 18y ago
      Somebody posted a study which showed, IIRC, that ~150 lines was the optimum length for subroutines. I really should bookmark these things... EDIT: Hooray for searchyc: http://news.ycombinator.com/item?id=509978 http://news.ycombinator.com/item?id=509978
      - scott_s 18y ago
        If you upmodded it, it's bookmarked under the "saved" section of your profile.
ankhmoop 18y ago
"Compile time checking can't catch most non-trivial bugs. Even if you swear by it, given the advances in Java IDEs, I would have to be quite lazy (or careless) to write Java code that doesn't compile." You should not underestimate the power of leveraging the type system to prevent programmer error. Do not think of the type system as a nanny. Instead, think of it as an integral language tool designed for your use. Use this tool -- the type system -- to convince the compiler enforce code correctness. Using the type system in this way will allow you to spend less time writing tests, as compilation can validate correctness. If this seems unlikely, spend time with a language with a powerful type system -- such as OCaml, Haskell, Scala or F#. You will find that it is possible to implement equally succinct and considerably more correct code through leveraging language features -- including the type system. Additionally, this exercise is fundamentally applicable with the real world. Should you use F# or Scala, you will find a vast trove of existing libraries, and high-quality, high-performance VM implementations at your fingertips. Your correct code, written faster, will run faster.
scott_s 18y ago
I don't care how much coverage your unit tests have, basic sanity-check assertions are the foundation of defensive coding.

nostrademons 18y ago

"I could 'fake it' for the rest of my career, or I could invest more effort in learning how to write better code faster in the first place." Uh, the techniques he describes are how you write better code faster in the first place. There's no magic "better code" fairy that comes along and instantly makes you a master programmer. You get better by deliberately seeking out ways in which you're failing, and then correcting them. And you use the techniques the article describes - code reviews, assertion, unit tests, and static typing - to do that. Eventually, those techniques become internalized, so that you still do them even when you take away the crutch of language and programming environment. Notice how studies of master Smalltalk and Erlang programmers found that they just don't make type errors, and that when you add a static type checker to those languages, existing programs pass unmodified? A lot of people have taken this as evidence that static typing isn't necessary. But there's another interpretation: master programmers write their programs as if they were statically-typed, even if the language itself does not require or enforce this. The reason they can get away with fast-and-loose programming languages is because they've already disciplined themselves into automatically doing what the strict programming languages enforce. And anecdotally, the vast body of crappy PHP and JavaScript code seems to support this interpretation.

ellyagg 18y ago

That's what unit testing is for? True, and do you understand the trade-offs? Unit testing is far more time consuming than assertions. Moreover, you're forced to write artificially short routines, routines of a length that research has shown to have a higher defect ratio. For myself, I've not yet been convinced that the costs/benefits of unit testing surpass the costs/benefits of assertions, at least when you're a small team working on end user software.

rimantas 18y ago
"Moreover, you're forced to write artificially short routines, routines of a length that research has shown to have a higher defect ratio" [citation needed] So far I've only seen advice to write shorter routines.
- ramchip 18y ago
  Indeed, I don't see how smaller, more manageable pieces would be more likely to be defective.
  - jibiki 18y ago
    Somebody posted a study which showed, IIRC, that ~150 lines was the optimum length for subroutines. I really should bookmark these things... EDIT: Hooray for searchyc: http://news.ycombinator.com/item?id=509978 http://news.ycombinator.com/item?id=509978
    - scott_s 18y ago
      If you upmodded it, it's bookmarked under the "saved" section of your profile.

ankhmoop 18y ago

"Compile time checking can't catch most non-trivial bugs. Even if you swear by it, given the advances in Java IDEs, I would have to be quite lazy (or careless) to write Java code that doesn't compile." You should not underestimate the power of leveraging the type system to prevent programmer error. Do not think of the type system as a nanny. Instead, think of it as an integral language tool designed for your use. Use this tool -- the type system -- to convince the compiler enforce code correctness. Using the type system in this way will allow you to spend less time writing tests, as compilation can validate correctness. If this seems unlikely, spend time with a language with a powerful type system -- such as OCaml, Haskell, Scala or F#. You will find that it is possible to implement equally succinct and considerably more correct code through leveraging language features -- including the type system. Additionally, this exercise is fundamentally applicable with the real world. Should you use F# or Scala, you will find a vast trove of existing libraries, and high-quality, high-performance VM implementations at your fingertips. Your correct code, written faster, will run faster.

scott_s 18y ago

I don't care how much coverage your unit tests have, basic sanity-check assertions are the foundation of defensive coding.