Learning to program, again

I’m frustrated that, in industry, “unit tests” are about the state of the art as far as widely adopted practises go. But I don’t want to just check one or two cases for my functions – I want to check them all!

This is my frustration with TDD when touted as a guarantor of code quality. I think there's a lot of hype because in dynamic languages like Ruby a good test suite combines most of the benefits of compilation error reports in a language like Java with some reasonable validations of code correctness.

However the claims start to get sort of outrageous, like writing tests first makes you design better architectures, which I think is at best incidentally true--making code testable is a valuable property, but there are dozens of abstract properties that make code "good".

The more production code I write, the greater my fascination with functional programming and mathematical proofs because it seems to me that pure functional code is the most powerful single tool in the quest to write flawless software.

Re: Learning to program, again

#5

Post by chipsy » Fri, Nov 20, 2009, 10:20 AM UTC

dasil003 wrote: post #4

I’m frustrated that, in industry, “unit tests” are about the state of the art as far as widely adopted practises go. But I don’t want to just check one or two cases for my functions – I want to check them all! This is my frustration with TDD when touted as a guarantor of code quality. I think there's a lot of hype because in dynamic languages like Ruby a good test suite combines most of the benefits of compilation er…

I think that declarative style is actually above functional style in terms of getting flawless results; declarative is the "ultimate abstraction" everyone seeks, since it lets you jump from problem definition to problem solution immediately. But it is found within language features as varied as named variables, type systems, classes, constraint primitives, functional algorithms, macro systems, and domain-specific languages. You can't actually be "declarative" from just one of those things; it's using them in combination, in incremental layers, that gets you to a truly beautiful result.

I also think that the majority of programmer zealotry originates from programmers who stumble upon a paradigm that allows them to be more declarative than before; being so stricken by this new power, they become blinded to the limitations.

Re: Learning to program, again

#6

Post by dasil003 » Fri, Nov 20, 2009, 4:19 PM UTC

chipsy wrote: post #5

dasil003 wrote: post #4

I’m frustrated that, in industry, “unit tests” are about the state of the art as far as widely adopted practises go. But I don’t want to just check one or two cases for my functions – I want to check them all! This is my frustration with TDD when touted as a guarantor of code quality. I think there's a lot of hype because in dynamic languages like Ruby a good test suite combines most of the benefits of compilation er…

I think that declarative style is actually above functional style in terms of getting flawless results; declarative is the "ultimate abstraction" everyone seeks, since it lets you jump from problem definition to problem solution immediately. But it is found within language features as varied as named variables, type systems, classes, constraint primitives, functional algorithms, macro systems, and domain-specific lan…

I'm not talking about functional style, I'm talking about pure functions. Declarative style is an orthogonal concept.

I can buy the argument that a declarative style makes intent clearer, but it's not the "ultimate abstraction" because all abstractions are leaky and also even if one happens not to be, it's still open to misinterpretation due to human assumptions (ie. the whole reason laymen programming tools have never worked out).

Clarity and intent are beside the point though. I'm not talking about making life easier for the programmer. I'm talking about getting guaranteed correct results. I'm talking about bugs, and bugs live deep inside code. The easy bugs are ones where there has been a wrong declaration in the DSL-veneer. The only way to guarantee there is no deep bug is through a mathematical proof, and you can't prove anything without enforced purity. I don't particularly enjoy math, but it delivers by far the strongest guarantees you can get in software.