3 ms·

I invite you to watch this talk. Dynamic typing is about a lot more than having an "Any" type. It's about widespread lack of extra code and cognitive overhead

I invite you to watch this talk. Dynamic typing is about a lot more than having an "Any" type. It's about widespread lack of extra code and cognitive overhead associated with the imposed structure of adding static types to a project, as well as the verbosity that static typing typically adds (including in type-inferred languages). You can't just turn off the static typing in a static-typed language; you can turn off the static type for a specific type, yes, but that doesn't give you the experience that dynamic languages offer.

amelius 9y ago
Yes. So how about a workflow where you write dynamically typed code, and then use a tool to convert that code (with user input) to statically typed code. You could do this incrementally. So once you have "frozen" your code into statically typed form, you could add dynamically typed code to it, and then "freeze" that. Or you could "thaw" the whole codebase, and add dynamically typed code, etc. > You can't just turn off the static typing in a static-typed language I suppose one could design a language where that is possible (although you wouldn't use the full power of static typing in that case).
- zimablue 9y ago
  I think the thing is that you write code in dynamic languages that you would never think to write in typed languages because it's just too against the culture/grain. Two common situations in my job of throwing data around: Dataframes and pivoting- here the type of a thing (its columns) is never going to be easily statically provable because operations modify it dynamically. Reactive/dataflow style programming- look at the python MDF library, you annotate functions and it dynamically infers a dataflow graph from your code. You can do dataflow in typed languages but nowhere near as elegantly normally. These two things are core to what I do and drive a train through a typesystem. I think that the best possible solution would be to have some way to embed proofs and individual typesystems in different parts of your program, like a dynamic language with plugged proofs and types not a single typesystem language that you sometimes go around or switch off.
  - sooheon 9y ago
    How much experience do you have with clojure.spec? I see it as a way to add dependent-type-like functionality to parts of Clojure, so my impression is that it addresses your final need very well. But if you know more about it than me and disagree, I'd like to know.
- _dps 9y ago
  > Yes. So how about a workflow where you write dynamically typed code, and then use a tool to convert that code (with user input) to statically typed code. This describes how I do a lot of my work. I prototype quickly in Python or Lua, and I have some in-house tools that let me migrate highly constrained subsets of those languages into C, with automated Quickcheck-style checking to make sure the translated code generates the same log messages as the source code. For me the experience of starting out with something extremely flexible, with a repl, easily mocked components, and tons of "kitchen sink" functionality makes me feel free to experiment quickly. Once I have something that looks like it's working I iteratively remove reliance on dynamic features or built-in libraries. At the end I have a Python function that looks a lot like a C function, but I got to that function a lot faster and more comfortable than I would have had I started in a pure C workflow. And from there, it's a quick build step to convert that function to a C function. I haven't found a good common name for this pattern, but I think of it as "plastics and metals", analogous to industrial design. Even though you know a component will end up being made of steel, lots of the design questions are more easily and cheaply solved by making a similar thing in plastic. The plastic of course won't stand up to "production" load, but it usually doesn't have to do so.
stewbrew 9y ago
(I haven't watched the talk because nothing you said makes me expect hearing something new.) WRT verbosity and cognitive overload: I honestly challenge this statement. In a modern statically typed language, you have to add a few type annotations here and there but in exchange you can skip most runtime checks (and sometimes nullity checks). You don't have to remember the type of a variable because the compiler can tell you. I admit dynamically typed languages are nice for interactive exploration in the REPL but that's about it. Too bad typed clojure didn't become the mainstream closure.
- hellofunk 9y ago
  The cognitive overhead is really not about type annotations. It's about program structure. If you watch the video, I think there are some good points made.
- gw 9y ago
  > I admit dynamically typed languages are nice for interactive exploration in the REPL but that's about it. For Clojure programmers, "interactive exploration in the REPL" is the primary way we write programs. So, if one admits that dynamic typing is ideal for this, then making Clojure dynamic was the right choice.
  - stewbrew 9y ago
    No, because you usually have to maintain programs, add features later on, rewrite/refactor parts of the program. Do you write only one-off scripts?
    - gw 9y ago
      I must emphasize that any time we "maintain programs, add features later on, rewrite/refactor parts of the program", we are doing so with a REPL. We don't just use the REPL for one-off scripts.
    - sbov 9y ago
      As someone who recently moved to Clojure, REPL based programming is a completely different experience. It isn't like using python's REPL.
lucozade 9y ago
> imposed structure of adding static types to a project I'm sure you didn't mean it this way but, for me, I think I reach for my pet dynamic or static typed language depending on whether or not I'm expecting to think about the structure of the program up front. Typing is not something I've thought of as an addition. If I'm doing something small or I'm expecting to iterate around some ideas/play with some data, then a dynamic language lets me try things out sooner. If I'm expecting to spend a fair amount of time on the project or I need to think hard about how I'm going to achieve stuff then thinking about the types up front is valuable. I'm likely to go for a statically typed language. I also have a bias towards statically typed if the project is going to get large. This is because I've tended to have more serious problems with large dynamically typed codebases. But I appreciate this is a bias; there are many factors that affect maintainability.
agumonkey 9y ago
I'd add one thing. The way we structure "logic" in subpart of systems is often one or nothing, while quite often we could check parameters by necessity. F a b c d can be valid if called in F a b c d e f g, because F gets what it needs (a b c d), the rest can be ignored. Like an implicit subclass relationship. A subclass B of A can have more features, but as long as it is an A, something depending on an A can enjoy it. Of course this can cause issues (stack use in function application with unnecessary information, albeit a non naive interpreter/compiler could prune this). In the end we spend a lot of time circling things around for safety, when we could have something more relaxed and thus more resilient.

amelius 9y ago

Yes. So how about a workflow where you write dynamically typed code, and then use a tool to convert that code (with user input) to statically typed code. You could do this incrementally. So once you have "frozen" your code into statically typed form, you could add dynamically typed code to it, and then "freeze" that. Or you could "thaw" the whole codebase, and add dynamically typed code, etc. > You can't just turn off the static typing in a static-typed language I suppose one could design a language where that is possible (although you wouldn't use the full power of static typing in that case).

zimablue 9y ago
I think the thing is that you write code in dynamic languages that you would never think to write in typed languages because it's just too against the culture/grain. Two common situations in my job of throwing data around: Dataframes and pivoting- here the type of a thing (its columns) is never going to be easily statically provable because operations modify it dynamically. Reactive/dataflow style programming- look at the python MDF library, you annotate functions and it dynamically infers a dataflow graph from your code. You can do dataflow in typed languages but nowhere near as elegantly normally. These two things are core to what I do and drive a train through a typesystem. I think that the best possible solution would be to have some way to embed proofs and individual typesystems in different parts of your program, like a dynamic language with plugged proofs and types not a single typesystem language that you sometimes go around or switch off.
- sooheon 9y ago
  How much experience do you have with clojure.spec? I see it as a way to add dependent-type-like functionality to parts of Clojure, so my impression is that it addresses your final need very well. But if you know more about it than me and disagree, I'd like to know.
_dps 9y ago
> Yes. So how about a workflow where you write dynamically typed code, and then use a tool to convert that code (with user input) to statically typed code. This describes how I do a lot of my work. I prototype quickly in Python or Lua, and I have some in-house tools that let me migrate highly constrained subsets of those languages into C, with automated Quickcheck-style checking to make sure the translated code generates the same log messages as the source code. For me the experience of starting out with something extremely flexible, with a repl, easily mocked components, and tons of "kitchen sink" functionality makes me feel free to experiment quickly. Once I have something that looks like it's working I iteratively remove reliance on dynamic features or built-in libraries. At the end I have a Python function that looks a lot like a C function, but I got to that function a lot faster and more comfortable than I would have had I started in a pure C workflow. And from there, it's a quick build step to convert that function to a C function. I haven't found a good common name for this pattern, but I think of it as "plastics and metals", analogous to industrial design. Even though you know a component will end up being made of steel, lots of the design questions are more easily and cheaply solved by making a similar thing in plastic. The plastic of course won't stand up to "production" load, but it usually doesn't have to do so.

stewbrew 9y ago

(I haven't watched the talk because nothing you said makes me expect hearing something new.) WRT verbosity and cognitive overload: I honestly challenge this statement. In a modern statically typed language, you have to add a few type annotations here and there but in exchange you can skip most runtime checks (and sometimes nullity checks). You don't have to remember the type of a variable because the compiler can tell you. I admit dynamically typed languages are nice for interactive exploration in the REPL but that's about it. Too bad typed clojure didn't become the mainstream closure.

hellofunk 9y ago
The cognitive overhead is really not about type annotations. It's about program structure. If you watch the video, I think there are some good points made.
gw 9y ago
> I admit dynamically typed languages are nice for interactive exploration in the REPL but that's about it. For Clojure programmers, "interactive exploration in the REPL" is the primary way we write programs. So, if one admits that dynamic typing is ideal for this, then making Clojure dynamic was the right choice.
- stewbrew 9y ago
  No, because you usually have to maintain programs, add features later on, rewrite/refactor parts of the program. Do you write only one-off scripts?
  - gw 9y ago
    I must emphasize that any time we "maintain programs, add features later on, rewrite/refactor parts of the program", we are doing so with a REPL. We don't just use the REPL for one-off scripts.
  - sbov 9y ago
    As someone who recently moved to Clojure, REPL based programming is a completely different experience. It isn't like using python's REPL.

lucozade 9y ago

> imposed structure of adding static types to a project I'm sure you didn't mean it this way but, for me, I think I reach for my pet dynamic or static typed language depending on whether or not I'm expecting to think about the structure of the program up front. Typing is not something I've thought of as an addition. If I'm doing something small or I'm expecting to iterate around some ideas/play with some data, then a dynamic language lets me try things out sooner. If I'm expecting to spend a fair amount of time on the project or I need to think hard about how I'm going to achieve stuff then thinking about the types up front is valuable. I'm likely to go for a statically typed language. I also have a bias towards statically typed if the project is going to get large. This is because I've tended to have more serious problems with large dynamically typed codebases. But I appreciate this is a bias; there are many factors that affect maintainability.

agumonkey 9y ago

I'd add one thing. The way we structure "logic" in subpart of systems is often one or nothing, while quite often we could check parameters by necessity. F a b c d can be valid if called in F a b c d e f g, because F gets what it needs (a b c d), the rest can be ignored. Like an implicit subclass relationship. A subclass B of A can have more features, but as long as it is an A, something depending on an A can enjoy it. Of course this can cause issues (stack use in function application with unnecessary information, albeit a non naive interpreter/compiler could prune this). In the end we spend a lot of time circling things around for safety, when we could have something more relaxed and thus more resilient.