4 ms·

There is plenty of evidence showing that the trend is toward static typing, not dynamic typing. Starting with the fact that most dynamically typed languages to

There is plenty of evidence showing that the trend is toward static typing, not dynamic typing. Starting with the fact that most dynamically typed languages today are progressively adding type checking (spec in Clojure, gradual typing in Groovy, etc...) while no statically typed languages are going the opposite way.

vorg 8y ago
When statically typed language C# added a dynamic keyword, that's a language going the other way. Of course, no-one actually thinks of C# as being a dynamically typed language despite its dynamic keyword, nor does anyone think of Apache Groovy as being a statically typed language despite its @CompileStatic annotation. In the everyday world, C# is used for building performant systems and Groovy is used for glue code and build scripts. Languages tend to go both ways nowadays. Go first shipped with both static typing (though without generics except for builtin datatypes) and dynamic typing (though using the wordy interface{} marker).
sheepmullet 8y ago
> while no statically typed languages are going the opposite way. Static languages added dynamic capabilities with reflection and run time code generation a long time ago.
dragonwriter 8y ago
> Starting with the fact that most dynamically typed languages today are progressively adding type checking At the same time, industrially-popular static languages have added dynamic escape hatches. The trend is really toward optional static type checking, with dynamic languages moving to opt-in typechecking and static languages moving to opt-out.
zmmmmm 8y ago
I agree, and interestingly I see it in my own Groovy code evolving over time. I look back at old code and it is full of needlessly dynamic types. Then I look at what I write now and I have just gravitated towards typing everything more and more. It's still great to be able to fall back to dynamic typing within local context where there is no loss of clarity from doing so. But putting a "hard shell" around the outside - function definitions, variable declarations, data types etc. makes me feel so much better about the maintainability and interpretability of the code. Sometimes I think I should just use Kotlin, but then I would miss the ability to drop seamlessly into dynamic mode when that makes sense. Especially in the REPL it is super nice.
- vorg 8y ago
  > Sometimes I think I should just use Kotlin, but then I would miss the ability to drop seamlessly into dynamic mode You can use Apache Groovy for just the glue code and Gradle build scripts, and use a statically-typed language like Java, Kotlin, or Scala for the actual system you're building -- that's what most programmers do.

vorg 8y ago

When statically typed language C# added a dynamic keyword, that's a language going the other way. Of course, no-one actually thinks of C# as being a dynamically typed language despite its dynamic keyword, nor does anyone think of Apache Groovy as being a statically typed language despite its @CompileStatic annotation. In the everyday world, C# is used for building performant systems and Groovy is used for glue code and build scripts. Languages tend to go both ways nowadays. Go first shipped with both static typing (though without generics except for builtin datatypes) and dynamic typing (though using the wordy interface{} marker).

sheepmullet 8y ago

> while no statically typed languages are going the opposite way. Static languages added dynamic capabilities with reflection and run time code generation a long time ago.

dragonwriter 8y ago

> Starting with the fact that most dynamically typed languages today are progressively adding type checking At the same time, industrially-popular static languages have added dynamic escape hatches. The trend is really toward optional static type checking, with dynamic languages moving to opt-in typechecking and static languages moving to opt-out.

zmmmmm 8y ago

I agree, and interestingly I see it in my own Groovy code evolving over time. I look back at old code and it is full of needlessly dynamic types. Then I look at what I write now and I have just gravitated towards typing everything more and more. It's still great to be able to fall back to dynamic typing within local context where there is no loss of clarity from doing so. But putting a "hard shell" around the outside - function definitions, variable declarations, data types etc. makes me feel so much better about the maintainability and interpretability of the code. Sometimes I think I should just use Kotlin, but then I would miss the ability to drop seamlessly into dynamic mode when that makes sense. Especially in the REPL it is super nice.

vorg 8y ago
> Sometimes I think I should just use Kotlin, but then I would miss the ability to drop seamlessly into dynamic mode You can use Apache Groovy for just the glue code and Gradle build scripts, and use a statically-typed language like Java, Kotlin, or Scala for the actual system you're building -- that's what most programmers do.