5 ms·

YMMV. I've found precisely the opposite. Early in my career, dynamically typed languages allowed me to push hard and fast and learn a lot in a short space of t

YMMV. I've found precisely the opposite. Early in my career, dynamically typed languages allowed me to push hard and fast and learn a lot in a short space of time via rapid prototyping. If you don't care about error handling then you can wrangle hard with a dynamic language and it won't catch up with you for a long time. But eventually... Now? I generally write even Python scripts over a few tens of lines with mypy running, because otherwise it becomes necessary to adopt some form of Hungarian notation anyway, and then you're just doing typing badly. For the most part static typing prevents you from doing things you know you shouldn't anyway. Like tacking arbitrary attributes onto objects that get passed around. APIs change indeed; and you want to know whether a type has changed, not simply be surprised.

zaphirplane 7y ago
Do the lisp / Clojure people find the dynamic types a problem? I guess I’m curious if dynamic typed languages share the similar problem around refactoring or does Clojure have features that mitigate them
- simongray 7y ago
  The thing that makes dynamic types quite easy to work with in Clojure is the fact that there's really not a whole lot of them there. In Clojure, pure data is king and creating your own types is strongly discouraged. It's possible to create types, mainly to allow for interop with Java and JS, but Clojure programmers really don't do it if it can be avoided. The flip side here is that ALL of the core functions work on ALL of the core data types, so no matter what type of data you're working on (sets, maps, lists/stacks, vectors, even strings) you run in to the same handful of data manipulation functions. All of the persistent data structures are immutable, memory-efficient, and allow for easy value-to-value comparisons. The Clojure data structures can also be applied as functions themselves so e.g. a map is both a data structure and a mapping function from one set of values to another. Everything fits neatly together like Lego bricks, you NEVER write any adapter code in Clojure. You do sometimes miss type information, especially when working with devs that aren't consistent in function parameter naming, but the trade-off is that you get a remarkably succinct and flexible language that really seems purpose-built to avoid the Lisp curse.
- sbergot 7y ago
  I think refactoring is even worse with lisp/clojure because the effect of macros are even less easy to predict. I need an intimate knowledge of the macro library of the local codebase to be able to refactor it.
  - simongray 7y ago
    I can't speak for other Lisps, but Clojure code really doesn't feature a lot of macros (by convention) and I've honestly never had to use any macro knowledge to refactor Clojure code. I work full time on a 100% Clojure/ClojureScript stack with 60 other Clojure devs. Maybe you can give us an example where this is an issue?

zaphirplane 7y ago

Do the lisp / Clojure people find the dynamic types a problem? I guess I’m curious if dynamic typed languages share the similar problem around refactoring or does Clojure have features that mitigate them

simongray 7y ago
The thing that makes dynamic types quite easy to work with in Clojure is the fact that there's really not a whole lot of them there. In Clojure, pure data is king and creating your own types is strongly discouraged. It's possible to create types, mainly to allow for interop with Java and JS, but Clojure programmers really don't do it if it can be avoided. The flip side here is that ALL of the core functions work on ALL of the core data types, so no matter what type of data you're working on (sets, maps, lists/stacks, vectors, even strings) you run in to the same handful of data manipulation functions. All of the persistent data structures are immutable, memory-efficient, and allow for easy value-to-value comparisons. The Clojure data structures can also be applied as functions themselves so e.g. a map is both a data structure and a mapping function from one set of values to another. Everything fits neatly together like Lego bricks, you NEVER write any adapter code in Clojure. You do sometimes miss type information, especially when working with devs that aren't consistent in function parameter naming, but the trade-off is that you get a remarkably succinct and flexible language that really seems purpose-built to avoid the Lisp curse.
sbergot 7y ago
I think refactoring is even worse with lisp/clojure because the effect of macros are even less easy to predict. I need an intimate knowledge of the macro library of the local codebase to be able to refactor it.
- simongray 7y ago
  I can't speak for other Lisps, but Clojure code really doesn't feature a lot of macros (by convention) and I've honestly never had to use any macro knowledge to refactor Clojure code. I work full time on a 100% Clojure/ClojureScript stack with 60 other Clojure devs. Maybe you can give us an example where this is an issue?