9 ms·

Dynamic Languages Strike Back (2008)

47 points by curling_grad 3y ago

bluefishinit 3y ago
The 2023 version should have "Tools: Dependency Management" and "Tools: Distribution", two areas where dynamic languages have fallen far behind more modern statically typed, compiled languages like Rust and Go.
- frou_dh 3y ago
  I dunno, I think NPM is rather good. Sure there's a lot of dangerous, sloppy and unnecessary code on NPM, but the actual workflow of using NPM the tool is better than many languages have.
- pjmlp 3y ago
  They were never better than Maven and NuGET, regarding the use cases, and corner cases.
  - Tainnor 3y ago
    Maven is trash, sorry. It can't even perform incremental compilation reliably, plugins download dependencies at execution time (making caching dependencies on CI a pain), the dependency resolution mechanism in the case of conflicting dependencies seems... random? [0], and so on. Gradle seems marginally better (and more modern), but it's also somehow overcomplex and easy to create a mess. I can fault Ruby for many things, but Bundler is easy to use and just works (except in the case of C bindings, but I don't think that's in the scope of Bundler to fix), and from what I hear, cargo should be similar. [0] Although this is also an ecosystem problem; in e.g. Ruby, libraries specify version ranges for subdependencies, and then Bundler will try to resolve all version ranges, and report an error if there's no way to resolve it. Usually, this works quite well. A Java library A will just specify a particular version of library B, you have no guarantee that the version of B that you get when you add A to your build is the same one. There are various solutions to this, such as BOMs, but if the library you use isn't in a BOM, you're out of luck. In any case, this is not a theoretical problem, I've spent countless hours trying to debug problems with conflicting dependency versions causing errors at runtime because certain classes or methods didn't exist.
    - pjmlp 3y ago
      It is still better than many alternatives, and the lengthy description about Ruby kind of proves my point.
      - Tainnor 3y ago
        How does it prove your point? I feel like you should be more specific instead of replying with a one-liner to a list of very specific complaints.
llogiq 3y ago
Yeah, that one hasn't aged too well. We've all seen the backswing to statically typed languages. Yes, some of them (e.g. typescript) run on top of dynamic langs, or allow for VMs (hi, WASM!). Why? Because ironically the same famed flexibility that makes it oh so easy to whip up a prototype is biting us in the ass when it comes to make a production-grade piece of software while staying on top of the ever changing requirements. So while we have a lot of python in ML (where most things haven't left prototyping stage), a lot of code nowadays is written in languages like Rust, TypeScript, Swift and others. Not (only) because that's faster to run, but because it's faster to change while still remaining somewhat working correctly. And the current crop of compilers not only can produce stunningly fast code, but also awe-inspiringly great error messages that put the 90's and oughties' cryptic error messages to shame. Try that with a dynamic language!
- jmull 3y ago
  IMO, it hardly seems useful to consider a dynamic language with statically checkable type annotations to be a static language. I think it’s interesting how static and dynamic languages have grown closer together since this was done. I’m not sure there’s really all that much to argue about anymore. Your static languages tend to have many of the features people like about dynamic languages and vice-versa, though of course that depends on the specific language.
  - frou_dh 3y ago
    The situation with CPython where you can type-annotate and statically type-check your code to the hilt and that confers no runtime performance benefit is so tragic.
    - zerodensity 3y ago
      Well the idea is orthogonal to performance really. Static types makes it simpler to automatically spot issues in the "static" portion of the code. It's also very useful for metaprogramming since types are included at runtime. Additionally it gives better documentation for free. Gradual typing wont be able to make interpretors faster though. A jit compiler could in theory take advantage of it but since CPython is not a JIT it will not.
kentonv 3y ago
I remember this post from the time and I'm glad we've come so far since then. It turns out the reason static typing seemed like a pain at the time is because we didn't have good tools. You'd write code for a while, then you'd run the compiler, and UGH there's all these errors to go back through and fix. Now that my IDE highlights the errors as I go, not to mention has good auto-complete and jump-to-definition, I am much more productive in a statically-typed language than a dynamic one. Interestingly there are still areas where most people seem to prefer dynamic typing: service APIs. JSON everywhere. Is it because JSON is actually better, or is it because we don't yet have good enough tools for schema-driven APIs (e.g. Protobuf, Cap'n Proto, etc.)? If we had those tools, would schema-driven APIs be widely seen as being more productive? (I suspect so but I am perhaps biased.)
- make3 3y ago
  Python is everywhere for ML, Javascript & it's dialects are everywhere for web etc., so dynamic languages are definitely everywhere now
- shellac 3y ago
  > It turns out the reason static typing seemed like a pain at the time is because we didn't have good tools. Java IDEs were certainly highlighting errors, auto-completing, refactoring etc in 2008. Admittedly IntelliJ (the most impressive one) didn't have a free version then.
  - deleted 3y ago
    [deleted]
  - maccard 3y ago
    Eclipse was available and free long before 2008. C++ had had visual studio, as has c# for longer than that too.
  - howinteresting 3y ago
    The problem with Java is that it is the most OOP language to ever exist, and OOP is an incoherent way to write production systems. Oh you've overridden a method in a subclass, ok. Who is responsible for calling whom? Which methods get to enforce invariants and which methods get to assume them? Documentation is an insufficient answer.
raphlinus 3y ago
I think the suitable followup to this is the Richard Feldman talk, "Why Static Typing Came Back."[1] It gives the major reasons why one would prefer one over the other, and makes the case that static types can provide most of the actual benefits of dynamic languages, but the reverse is not true. [1]: https://www.youtube.com/watch?v=Tml94je2edk https://www.youtube.com/watch?v=Tml94je2edk
agnosticmantis 3y ago
Recording of the lecture: https://youtu.be/tz-Bb-D6teE https://youtu.be/tz-Bb-D6teE
dehrmann 3y ago
There's a joke that dynamically typed languages are just statically typed languages with one type: hashtable.
- deleted 3y ago
  [deleted]
- Tainnor 3y ago
  I don't even think that's just a joke, that's what dynamically typed languages are from a type theory point of view (well, I guess the type theory doesn't care if you call that type "hashtable" or "any" or "foobar").
chucke 3y ago
Let's meet again in 20 years, when developers discover dynamic languages again.
snailtrail 3y ago
Can’t believe I had to live through this BS. Thank god folks embraced low entropy code

47 points by curling_grad 3y ago

The 2023 version should have "Tools: Dependency Management" and "Tools: Distribution", two areas where dynamic languages have fallen far behind more modern statically typed, compiled languages like Rust and Go.

frou_dh 3y ago
I dunno, I think NPM is rather good. Sure there's a lot of dangerous, sloppy and unnecessary code on NPM, but the actual workflow of using NPM the tool is better than many languages have.
pjmlp 3y ago
They were never better than Maven and NuGET, regarding the use cases, and corner cases.
- Tainnor 3y ago
  Maven is trash, sorry. It can't even perform incremental compilation reliably, plugins download dependencies at execution time (making caching dependencies on CI a pain), the dependency resolution mechanism in the case of conflicting dependencies seems... random? [0], and so on. Gradle seems marginally better (and more modern), but it's also somehow overcomplex and easy to create a mess. I can fault Ruby for many things, but Bundler is easy to use and just works (except in the case of C bindings, but I don't think that's in the scope of Bundler to fix), and from what I hear, cargo should be similar. [0] Although this is also an ecosystem problem; in e.g. Ruby, libraries specify version ranges for subdependencies, and then Bundler will try to resolve all version ranges, and report an error if there's no way to resolve it. Usually, this works quite well. A Java library A will just specify a particular version of library B, you have no guarantee that the version of B that you get when you add A to your build is the same one. There are various solutions to this, such as BOMs, but if the library you use isn't in a BOM, you're out of luck. In any case, this is not a theoretical problem, I've spent countless hours trying to debug problems with conflicting dependency versions causing errors at runtime because certain classes or methods didn't exist.
  - pjmlp 3y ago
    It is still better than many alternatives, and the lengthy description about Ruby kind of proves my point.
    - Tainnor 3y ago
      How does it prove your point? I feel like you should be more specific instead of replying with a one-liner to a list of very specific complaints.

llogiq 3y ago

Yeah, that one hasn't aged too well. We've all seen the backswing to statically typed languages. Yes, some of them (e.g. typescript) run on top of dynamic langs, or allow for VMs (hi, WASM!). Why? Because ironically the same famed flexibility that makes it oh so easy to whip up a prototype is biting us in the ass when it comes to make a production-grade piece of software while staying on top of the ever changing requirements. So while we have a lot of python in ML (where most things haven't left prototyping stage), a lot of code nowadays is written in languages like Rust, TypeScript, Swift and others. Not (only) because that's faster to run, but because it's faster to change while still remaining somewhat working correctly. And the current crop of compilers not only can produce stunningly fast code, but also awe-inspiringly great error messages that put the 90's and oughties' cryptic error messages to shame. Try that with a dynamic language!

jmull 3y ago
IMO, it hardly seems useful to consider a dynamic language with statically checkable type annotations to be a static language. I think it’s interesting how static and dynamic languages have grown closer together since this was done. I’m not sure there’s really all that much to argue about anymore. Your static languages tend to have many of the features people like about dynamic languages and vice-versa, though of course that depends on the specific language.
- frou_dh 3y ago
  The situation with CPython where you can type-annotate and statically type-check your code to the hilt and that confers no runtime performance benefit is so tragic.
  - zerodensity 3y ago
    Well the idea is orthogonal to performance really. Static types makes it simpler to automatically spot issues in the "static" portion of the code. It's also very useful for metaprogramming since types are included at runtime. Additionally it gives better documentation for free. Gradual typing wont be able to make interpretors faster though. A jit compiler could in theory take advantage of it but since CPython is not a JIT it will not.

kentonv 3y ago

I remember this post from the time and I'm glad we've come so far since then. It turns out the reason static typing seemed like a pain at the time is because we didn't have good tools. You'd write code for a while, then you'd run the compiler, and UGH there's all these errors to go back through and fix. Now that my IDE highlights the errors as I go, not to mention has good auto-complete and jump-to-definition, I am much more productive in a statically-typed language than a dynamic one. Interestingly there are still areas where most people seem to prefer dynamic typing: service APIs. JSON everywhere. Is it because JSON is actually better, or is it because we don't yet have good enough tools for schema-driven APIs (e.g. Protobuf, Cap'n Proto, etc.)? If we had those tools, would schema-driven APIs be widely seen as being more productive? (I suspect so but I am perhaps biased.)

make3 3y ago
Python is everywhere for ML, Javascript & it's dialects are everywhere for web etc., so dynamic languages are definitely everywhere now
shellac 3y ago
> It turns out the reason static typing seemed like a pain at the time is because we didn't have good tools. Java IDEs were certainly highlighting errors, auto-completing, refactoring etc in 2008. Admittedly IntelliJ (the most impressive one) didn't have a free version then.
- deleted 3y ago
  [deleted]
- maccard 3y ago
  Eclipse was available and free long before 2008. C++ had had visual studio, as has c# for longer than that too.
- howinteresting 3y ago
  The problem with Java is that it is the most OOP language to ever exist, and OOP is an incoherent way to write production systems. Oh you've overridden a method in a subclass, ok. Who is responsible for calling whom? Which methods get to enforce invariants and which methods get to assume them? Documentation is an insufficient answer.

raphlinus 3y ago

I think the suitable followup to this is the Richard Feldman talk, "Why Static Typing Came Back."[1] It gives the major reasons why one would prefer one over the other, and makes the case that static types can provide most of the actual benefits of dynamic languages, but the reverse is not true. [1]: https://www.youtube.com/watch?v=Tml94je2edk https://www.youtube.com/watch?v=Tml94je2edk

agnosticmantis 3y ago

Recording of the lecture: https://youtu.be/tz-Bb-D6teE https://youtu.be/tz-Bb-D6teE

dehrmann 3y ago

There's a joke that dynamically typed languages are just statically typed languages with one type: hashtable.

deleted 3y ago
[deleted]
Tainnor 3y ago
I don't even think that's just a joke, that's what dynamically typed languages are from a type theory point of view (well, I guess the type theory doesn't care if you call that type "hashtable" or "any" or "foobar").

chucke 3y ago

Let's meet again in 20 years, when developers discover dynamic languages again.

snailtrail 3y ago

Can’t believe I had to live through this BS. Thank god folks embraced low entropy code