[erlang-questions] Spec is diabolical IMHO

[Loïc Hoguin]

On 09/28/2012 03:11 AM, Steve Davis wrote:
> Hi Michael,
>
> I suspect that if your code is beta quality then it would be fair to say that the contract is beta quality also, right?
>
> When you/the author get around to implementing it (if you/they ever do) then you/they may definitely find that the contract changes. I think it hubris to believe that you can predict that future without implementing it first. Meantime, this "api idea" in a spec is implicitly expected to be supported by all users - even though it is bogus. I'd say to that - just be honest about what _is_, not what you think things may be.
>
> WRT to dialyzer -> If dialyzer can see that, then what is the purpose of the spec (given that is it provably wrong). Should not dialyzer strive to look deeper rather than requesting/requiring that highly fault-prone specs should be written for every function?
>
> You'll perhaps also note that the comment on the example was also wrong. It stated "Currently unused", and that isn't true either - the function just doesn't do anything on a code change; But the function IS USED. *Everything* preceding the actual function is misleading.
>
> I'm saying we should all be aware of that, and dare to consider better solutions than spec.
>
> I would post-script the above with the following thought for those that have experienced it in other languages: The drive to clear definition of static typing leads to highly repetitive and confusing code that leads to high distraction and extremely suspect verbosity. => One of erlang's core syntax strengths is a low requirement on developer time to get an error tolerant, working system, and that aggressive approach is "saved" by coding to "let it crash".

Specs are insanely useful to me by ensuring that my code changes do not 
have an unexpected impact, like unknowingly changing an interface, or 
creating some dead code by not seeing a match can't happen. Having them 
allows Dialyzer to help you a lot more than if it has to guess everything.

Without them I'd probably introduce bugs all the time. They're an 
additional guarantee alongside tests. Specs ensure the intent is right, 
tests ensure the code is right.

Plus specs are also documentation that I'd have to write somewhere anyway.

-- 
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu