4 ms·

I find one's point of view on the matter is largely colored by one's experience. For example, I personally love static types. In your example I would prefer mo

I find one's point of view on the matter is largely colored by one's experience. For example, I personally love static types. In your example I would prefer modelling people as a list of structs, each one with a required "name" (string), an optional "nickname" (string option), and required boolean flags for mod and admin. Why would I prefer it to be that way? Because a huge number of typos I might introduce in my project are caught before I even try to run something. I've been bitten once too many times by a typo somewhere (like looking up the "nick" property instead of "nickname") and having the program raise an error after it's already ran for a while. I can't stand that.

bjconlan 7y ago
This can all be covered by more abstractions though via some schema/spec/type validation process. Ide integration is the interesting problem here (and typescript does this beautifully) but I agree horses for courses (and experience). I think the idea for using the keyword to hold the nullability of a field interesting, I thought this was more of a meta attribute in clj? In saying that I actually find this style of keywording way easier to read.
wellpast 7y ago
It is probably true that a majority today favors static types, but I don't think this a subjective issue if the problem is maximizing developer throughput over time. Working on statically typed code bases that model things the way you are describing substantially increases the effort and time it takes to iterate. So while you may prefer them (per your experience or what else), there is still the fact that this way of development is suboptimal with respect to delivery throughput over time. Of course this is arguable (and is a very heavily argued topic) and the common retort is "to each is own" that isn't sufficient to me. One might prefer to work in assembly language (per experience or predisposition) but there is still a general statement that can be made that this is intrinsically a suboptimal way to work if delivery throughput is your goal. I believe that a similar claim can be made to differentiate working in static ADT v. dynamic Map types when modeling business domains. More food for thought. The typo problems you mentioned are solved by static types but at what cost? And is the CBA there? Especially considering that there are other ways to "solve" the typo problem that do not come with the heavy tax burden of statically typed ADTs.
- jjnoakes 7y ago
  In my experience static types increase my development velocity. I can make changes and find many bugs at compile time without writing tests. I still write tests of course but I have to write fewer, and I rarely waste time fixing trivial things that raise errors at runtime. It is also much quicker for me to navigate the code. I can find definitions for identifiers instantly and get my mental model refreshed easily every time I switch contexts. I use dynamic languages too, and I find myself spending more time on things that static languages do for me.

bjconlan 7y ago

This can all be covered by more abstractions though via some schema/spec/type validation process. Ide integration is the interesting problem here (and typescript does this beautifully) but I agree horses for courses (and experience). I think the idea for using the keyword to hold the nullability of a field interesting, I thought this was more of a meta attribute in clj? In saying that I actually find this style of keywording way easier to read.

wellpast 7y ago

It is probably true that a majority today favors static types, but I don't think this a subjective issue if the problem is maximizing developer throughput over time. Working on statically typed code bases that model things the way you are describing substantially increases the effort and time it takes to iterate. So while you may prefer them (per your experience or what else), there is still the fact that this way of development is suboptimal with respect to delivery throughput over time. Of course this is arguable (and is a very heavily argued topic) and the common retort is "to each is own" that isn't sufficient to me. One might prefer to work in assembly language (per experience or predisposition) but there is still a general statement that can be made that this is intrinsically a suboptimal way to work if delivery throughput is your goal. I believe that a similar claim can be made to differentiate working in static ADT v. dynamic Map types when modeling business domains. More food for thought. The typo problems you mentioned are solved by static types but at what cost? And is the CBA there? Especially considering that there are other ways to "solve" the typo problem that do not come with the heavy tax burden of statically typed ADTs.

jjnoakes 7y ago
In my experience static types increase my development velocity. I can make changes and find many bugs at compile time without writing tests. I still write tests of course but I have to write fewer, and I rarely waste time fixing trivial things that raise errors at runtime. It is also much quicker for me to navigate the code. I can find definitions for identifiers instantly and get my mental model refreshed easily every time I switch contexts. I use dynamic languages too, and I find myself spending more time on things that static languages do for me.