Hmm... May be I misunderstood something [LWN.net]

Hmm... May be I misunderstood something

Posted Jul 18, 2009 10:47 UTC (Sat) by bockman (guest, #3650)
In reply to: Hmm... May be I misunderstood something by khim
Parent article: Unladen Swallow 2009Q2 released

Sure, compiler checks are useful. But are not enough, and this is a point that sometime is forgotten in comparing static and dynamic typing. An API can mantain its formal interface but change its meaning (e.g. the parameter 'length' was inches and now is centimeters ) and no compiler will help you with that.

And I don't think that in a dynamic language one has to do explicit unit test for wrong parameter types : misusage of a function is bound to trigger some exception or make anyway fail the test. The resulting error message might not be the most informative, but usually lead you to the original problem. What you have to do is ensure full code coverage, which is a good practice also in statically-typed languages.

Not that I would dislike having more compiler-time checks in python: there are tools that help with that, and maybe they will help more in the future making clever usage of python3 annotations.

Ciao
------
FB

to post comments

Hmm... May be I misunderstood something

Posted Jul 18, 2009 19:34 UTC (Sat) by farnz (subscriber, #17727) [Link] (1 responses)

Actually, given an expressive type system, the formal interface would change for that change in meaning. For example, using a type system comparable to that of Haskell (but C-ish syntax), I could define a function Storeys buildingHeightInStoreys( Metres<Int> length );. When I change that function to work in inches, it becomes Storeys buildingHeightInStoreys( Inches<Int> length );.

Throw in type inference, and you get some of the benefits of dynamic languages like Python. Again, using C-ish syntax, I could declare a function USDollars estimatedRent( auto height );, and write suitable behaviour for each variation on height (perhaps by unifying on height in storeys, and estimating from there).

Having said all that, it's a tradeoff in terms of work - the question is not whether static types are enough to stop all bugs on their own, but whether the reduction in tests that they permit is outweighed by the cost of static types. I believe that in C, this isn't true. In Haskell, however, people claim that it is true; this is one that remains to be tested more formally.

Hmm... May be I misunderstood something

Posted Jul 18, 2009 19:45 UTC (Sat) by dw (subscriber, #12017) [Link]

In this particular case I think 'the pen is mightier than the sword'.. just have a paragraph in your style guide requiring the scale and unit be included in the variable name, or at least documented at the variable's declaration site.

I personally work on one project where units of time are stored in things like "lengthMs", "startDelayMs", etc. Seems to work well for me.

Compiler is not substitute for brain, sorry...

Posted Jul 19, 2009 6:32 UTC (Sun) by khim (subscriber, #9252) [Link]

Sure, compiler checks are useful. But are not enough, and this is a point that sometime is forgotten in comparing static and dynamic typing.

Sorry, but this is bull-shit.

An API can mantain its formal interface but change its meaning (e.g. the parameter 'length' was inches and now is centimeters ) and no compiler will help you with that.

Fire the person who commited such a change (or revoke his commit rights) - problem solved. It's resposibility of programmer to guarantee that formal interface changes if the semantic changes: new method should get some suffix prefix so it's impossible to mix old and new version, it's not a rocket science. Bad programmer can write awful unmaintable program in any language.

And I don't think that in a dynamic language one has to do explicit unit test for wrong parameter types : misusage of a function is bound to trigger some exception or make anyway fail the test.

Not at all. Take your own example: suppose you have an interface where you enter paraments of sattelite and it returns some stats. Suppose you have two implementations (different approximation methods or something). Unittest for interface will test that everything works for trivial case, unitests for implementations will check error margins and other such things. The exception will be triggered, alright: when orbiter will either try to orbit Mars below surface or "NoSuchMethod" exception will be thrown and the system will be shut down. By that time it's kinda too late...

What you have to do is ensure full code coverage, which is a good practice also in statically-typed languages.

Full code coverage is nice and all, but unfortunatelly it's not an option for a big system: you can only test one component a time, because the whole system is too big.