
When is it not preferable to specify your types first? - raphaelss
http://pchiusano.github.io/2015-10-28/top-down.html
======
molyss
I can't help it but disagree with the author.

His example shouldn't make someone think "god, I wish I didn't have to specify
the type here", but rather "wait, there's a problem here. There's way too many
concepts in a single line of code, I should probably refactor that to make it
clearer". Having to specify the type is what should help the developer come to
the realization that something needs to be more modular, so the people reading
the code in the future (including him/herself in a week from now) will have a
easier time understanding what's going on.

Overall, I feel like there's a common thinking these days that most of
software cost is in the time spent to write it and thus we should use any
means necessary to reduce that time. type inference everywhere makes it so
that just reading a source code prevents you from knowing the type of anything
without learning first the whole API by heart. And it's reaching the top when
you define a function using "fn" in rust (there might be another explanation
than saving keystrokes, but I can 't think of any), or "go fmt" instead of "go
format".

IMO, the truth is that while a code has been written exactly once in its
current form, it's being read hundreds or thousands of times. For learning,
debugging, fixing, improving or adding performances. It doesn't matter. And
when you have to read the code to understand the concepts behind it, you're
just wasting brain cycles.

Yes, typing types everywhere is a complete pain in the neck. But reading and
modifying code without anything has always felt 100 times worse to me

------
avmich
The first example reminds me specifications of some types in typed Clojure.
Part of the reason it gets complaints is those tricky types.

At least they look like that, comparing to Haskell.

