10 ms·

I wrote Clojure for 4 years. I understand your pain points. Dynamic types are an impediment beyond a certain code size.

praptak 5y ago
My experience with dynamic types comes from developing in Python. The projects I've seen were pretty healthy until a large enough part of the original team went away. Once enough people had to figure out their way by experimenting, the projects got messy. I'm not saying this doesn't happen in Java or Go but the static typing enables easier code exploration. That makes code bases more readable to newcomers.
- kaliszad 5y ago
  That might be true but good variable names and some terse but to the point comments are much more helpful in my experience.
- neutronicus 5y ago
  I always really missed header files when working on Python. A sort of enforced distinction between (typed) interface and implementation. In practice I always wound up needing to read code of functions to see what types (or keyword argument!) they expected.
yogthos 5y ago
My team structures projects by breaking things up into small isolated components that can be reasoned about independently. We'll often do it at the level of namespaces, where a namespace will describe a particular workflow or data transformation, and namespaces tend to be 500 lines or less. It's a similar idea to microservice architecture without the overhead of having to actually split the application up into separate processes. We'll also often pull out code into libraries when we notice it being generally useful outside the original use case. I find that there are a lot of benefits to structuring your code using small components instead of monolithically as tt's easier to reason about and reuse. Any large application can, and in my opinion, should be broken down into small parts that are then composed.
- draklor40 5y ago
``` breaking things up into small isolated components that can be reasoned about independently ``` - This is insufficient for the same reasons unit tests are not enough and you also need integration tests. The moment you cross namespace boundaries, you will end up not setting keys /entries in maps , missing logic etc and end up needing something like Spec/Schema....
- mumblemumble 5y ago
  > you will end up not setting keys /entries in maps This is what I run into. But that's not exactly a dynamic language problem. It's more of a data-oriented programming (in the Clojure sense) problem. I'm coming to the opinion that data-oriented programming techniques only make sense inside a fairly tightly bounded context. One that's small enough that you can see and understand the whole thing at once. As soon as you've got ad-hoc data structures crossing logical boundaries, you lose the ability to keep track of it all, and it becomes very difficult to ensure everyone's interacting with these ad-hoc types in a compatible manner. Incidentally, this is also exactly why I dislike JSON for APIs. I'd much rather share data across boundaries using data structures with explicit, nominal, static types. Like what you get in gRPC. Anyway, my Clojure experience is limited, but I think this is why I have an easier time letting Python code get big than I did Clojure. With Python, I've got myself into some problems with data oriented programming, too. But with Python, it was easy (and idiomatic) to walk that back and switch to using dataclasses.
  - draklor40 5y ago
    > This is what I run into. But that's not exactly a dynamic language problem. It's more of a data-oriented programming (in the Clojure sense) problem. Yes, all dynamic languages have this problem. I have transitioned to statically typed languages and it has been very peaceful so far :)
    - mumblemumble 5y ago
      To go at it from another angle: I'm working in a relatively large Java codebase that also likes to pass around generic ad-hoc data-structures such as maps. And I'm having exactly the same problem problems there. Static typing does nothing to help the situation. I realize that data-oriented programming is more likely to happen in dynamic languages. But correlation is not causation.

My experience with dynamic types comes from developing in Python. The projects I've seen were pretty healthy until a large enough part of the original team went away. Once enough people had to figure out their way by experimenting, the projects got messy. I'm not saying this doesn't happen in Java or Go but the static typing enables easier code exploration. That makes code bases more readable to newcomers.

kaliszad 5y ago
That might be true but good variable names and some terse but to the point comments are much more helpful in my experience.
neutronicus 5y ago
I always really missed header files when working on Python. A sort of enforced distinction between (typed) interface and implementation. In practice I always wound up needing to read code of functions to see what types (or keyword argument!) they expected.

yogthos 5y ago

My team structures projects by breaking things up into small isolated components that can be reasoned about independently. We'll often do it at the level of namespaces, where a namespace will describe a particular workflow or data transformation, and namespaces tend to be 500 lines or less. It's a similar idea to microservice architecture without the overhead of having to actually split the application up into separate processes. We'll also often pull out code into libraries when we notice it being generally useful outside the original use case. I find that there are a lot of benefits to structuring your code using small components instead of monolithically as tt's easier to reason about and reuse. Any large application can, and in my opinion, should be broken down into small parts that are then composed.

draklor40 5y ago
``` breaking things up into small isolated components that can be reasoned about independently ``` - This is insufficient for the same reasons unit tests are not enough and you also need integration tests. The moment you cross namespace boundaries, you will end up not setting keys /entries in maps , missing logic etc and end up needing something like Spec/Schema....
- mumblemumble 5y ago
  > you will end up not setting keys /entries in maps This is what I run into. But that's not exactly a dynamic language problem. It's more of a data-oriented programming (in the Clojure sense) problem. I'm coming to the opinion that data-oriented programming techniques only make sense inside a fairly tightly bounded context. One that's small enough that you can see and understand the whole thing at once. As soon as you've got ad-hoc data structures crossing logical boundaries, you lose the ability to keep track of it all, and it becomes very difficult to ensure everyone's interacting with these ad-hoc types in a compatible manner. Incidentally, this is also exactly why I dislike JSON for APIs. I'd much rather share data across boundaries using data structures with explicit, nominal, static types. Like what you get in gRPC. Anyway, my Clojure experience is limited, but I think this is why I have an easier time letting Python code get big than I did Clojure. With Python, I've got myself into some problems with data oriented programming, too. But with Python, it was easy (and idiomatic) to walk that back and switch to using dataclasses.
  - draklor40 5y ago
    > This is what I run into. But that's not exactly a dynamic language problem. It's more of a data-oriented programming (in the Clojure sense) problem. Yes, all dynamic languages have this problem. I have transitioned to statically typed languages and it has been very peaceful so far :)
    - mumblemumble 5y ago
      To go at it from another angle: I'm working in a relatively large Java codebase that also likes to pass around generic ad-hoc data-structures such as maps. And I'm having exactly the same problem problems there. Static typing does nothing to help the situation. I realize that data-oriented programming is more likely to happen in dynamic languages. But correlation is not causation.