6 ms·

I don’t get the cost claims. The time it takes to note which type I intend something to be is mostly either so low that I recover it via improved hints and such

I don’t get the cost claims. The time it takes to note which type I intend something to be is mostly either so low that I recover it via improved hints and such very quickly, or larger but only because I’m documenting something complex enough that I should have documented it anyway, whether or not I was using static types, because it’ll be hell for other people or future-me to figure out otherwise. It seems like a large time savings to me—throw in faster and more confident refactoring and stuff like that, and it’s not even close. I just don’t get how people are working that it represents a time cost rather than a large time savings. I don’t mean that as a dig, I just mean I genuinely don’t know what that must look like. And I’ve written a lot more code in dynamic languages, and got my start there, so it’s not like I “grew up” writing Java or something like that.

GlennS 6y ago
I would like to be able to explain the cost part better. It may just be personal bias of course. 1. There's no guarantee the correct theoretical model of your program fits the type system of your programming language. 2. Sometimes there are multiple correct models for different purposes in the same program, similar to how sometimes you need multiple views onto the same database tables. 3. Sometimes you just need the ability to bodge things.
- wtetzner 6y ago
  > 2. Sometimes there are multiple correct models for different purposes in the same program, similar to how sometimes you need multiple views onto the same database tables. Just wanted to point out that even though you can have multiple views or your database tables, they all still adhere to the same type system.
  - GlennS 6y ago
    I guess it's a problem that can be overcome with type inference then? (I don't have to declare types on queries, updates, or views, just on the base tables.)
simiones 6y ago
I think the general feeling is that there are some code patterns that are safe and easy to do with dynamic typing, but impossible with simple type systems or more complex with more advanced type system. An example would be Common Lisp's `map` function [0] (it takes a number of sequences and a function that has as many parameters as there are sequences). It would be hard to come up with a type for this in Java, and it would be a pretty complicated type in Haskell. Another example of many people's experience with static typing is the Go style of language, where you can't write any code that works for both a list of strings and a list of numbers. This is no longer common, but it used to be very common ~10-15 years ago and many may have not looked back. [0] http://www.lispworks.com/documentation/HyperSpec/Body/f_map.htm#map http://www.lispworks.com/documentation/HyperSpec/Body/f_map....
- anonymoushn 6y ago
  As an example of this, I've been working through Crafting Interpreters off and on. Chapter 5 consists mostly of discussion of the visitor pattern (is this the same thing as double dispatch?). The author notices that the amount of code that must be written to implement the design is so large that it's best to write a program to generate all of that code. I followed along as best I could, and at the end I wrote the equivalent code in my preferred language, which I've included in this comment: self[expr.type](self, expr)
- the_af 6y ago
  In my opinion, with few exceptions, the kind of programs advocates of dynamic typing want to write that static typing would have trouble dealing with, are artificial and not the common case. (Not "map" though, I need to review that case, but "map" is definitely a common and useful function!) > Another example of many people's experience with static typing is the Go style of language Remember that a lot of backlash against Go's type system comes from static typing advocates used to more expressive static type systems :) It'd be a shame if, after all we complained about Go's limitations, newcomers held Go as an example of why static typing is a roadblock...
  - simiones 6y ago
the_af 6y ago
I agree with you. There is a related joke (?) that goes like this: "I don't like to waste time writing tests, because I need that time to fix bugs on production that happened because I don't write tests". The relation to static typing is that static types are a kind of test the computer automatically writes for you.
anonymoushn 6y ago
How many hundreds of LOC would you like to write to support serializing and deserializing JSON for an endpoint that has a schema with around 20 fields, some of which are nested? If you are using Spring and Jackson, you will get to write around 300 LOC across 8 files before you get your hands on a single deserialized object. In any sane language you would use a library that enforces an arbitrary JSON schema to get the same validation guarantees provided by Jackson while writing maybe 25 LOC across maybe 2 files (if we generously count the JSON schema as code for this language but not for Java). Is this an unusual use case?
- dahauns 6y ago
  Why would you write any of this yourself? This is the classic use case for code generation. (And IMO one of the few justified ones.)
  - anonymoushn 6y ago
    It seems like the more common approach among people who use Java is to write the 300 LOC across the 8 files then use the library to generate JSON schema, rather than the other way around. I wrote it myself because I did not want to tell my team that they had been doing things wrong for years before trying their approach once.

GlennS 6y ago

I would like to be able to explain the cost part better. It may just be personal bias of course. 1. There's no guarantee the correct theoretical model of your program fits the type system of your programming language. 2. Sometimes there are multiple correct models for different purposes in the same program, similar to how sometimes you need multiple views onto the same database tables. 3. Sometimes you just need the ability to bodge things.

wtetzner 6y ago
> 2. Sometimes there are multiple correct models for different purposes in the same program, similar to how sometimes you need multiple views onto the same database tables. Just wanted to point out that even though you can have multiple views or your database tables, they all still adhere to the same type system.
- GlennS 6y ago
  I guess it's a problem that can be overcome with type inference then? (I don't have to declare types on queries, updates, or views, just on the base tables.)

simiones 6y ago

I think the general feeling is that there are some code patterns that are safe and easy to do with dynamic typing, but impossible with simple type systems or more complex with more advanced type system. An example would be Common Lisp's `map` function [0] (it takes a number of sequences and a function that has as many parameters as there are sequences). It would be hard to come up with a type for this in Java, and it would be a pretty complicated type in Haskell. Another example of many people's experience with static typing is the Go style of language, where you can't write any code that works for both a list of strings and a list of numbers. This is no longer common, but it used to be very common ~10-15 years ago and many may have not looked back. [0] http://www.lispworks.com/documentation/HyperSpec/Body/f_map.htm#map http://www.lispworks.com/documentation/HyperSpec/Body/f_map....

anonymoushn 6y ago
As an example of this, I've been working through Crafting Interpreters off and on. Chapter 5 consists mostly of discussion of the visitor pattern (is this the same thing as double dispatch?). The author notices that the amount of code that must be written to implement the design is so large that it's best to write a program to generate all of that code. I followed along as best I could, and at the end I wrote the equivalent code in my preferred language, which I've included in this comment: self[expr.type](self, expr)
the_af 6y ago
In my opinion, with few exceptions, the kind of programs advocates of dynamic typing want to write that static typing would have trouble dealing with, are artificial and not the common case. (Not "map" though, I need to review that case, but "map" is definitely a common and useful function!) > Another example of many people's experience with static typing is the Go style of language Remember that a lot of backlash against Go's type system comes from static typing advocates used to more expressive static type systems :) It'd be a shame if, after all we complained about Go's limitations, newcomers held Go as an example of why static typing is a roadblock...
- simiones 6y ago

the_af 6y ago

I agree with you. There is a related joke (?) that goes like this: "I don't like to waste time writing tests, because I need that time to fix bugs on production that happened because I don't write tests". The relation to static typing is that static types are a kind of test the computer automatically writes for you.

anonymoushn 6y ago

How many hundreds of LOC would you like to write to support serializing and deserializing JSON for an endpoint that has a schema with around 20 fields, some of which are nested? If you are using Spring and Jackson, you will get to write around 300 LOC across 8 files before you get your hands on a single deserialized object. In any sane language you would use a library that enforces an arbitrary JSON schema to get the same validation guarantees provided by Jackson while writing maybe 25 LOC across maybe 2 files (if we generously count the JSON schema as code for this language but not for Java). Is this an unusual use case?

dahauns 6y ago
Why would you write any of this yourself? This is the classic use case for code generation. (And IMO one of the few justified ones.)
- anonymoushn 6y ago
  It seems like the more common approach among people who use Java is to write the 300 LOC across the 8 files then use the library to generate JSON schema, rather than the other way around. I wrote it myself because I did not want to tell my team that they had been doing things wrong for years before trying their approach once.