Dynamic Languages Strike Back (2008) • Hacker News Board

Re: Dynamic Languages Strike Back (2008)

#41

Post by Tainnor » Wed, Jul 05, 2023, 10:51 AM UTC

pjmlp wrote: post #27

bluefishinit wrote: post #2

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.

They were never better than Maven and NuGET, regarding the use cases, and corner cases.

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.

Re: Dynamic Languages Strike Back (2008)

#42

Post by Tainnor » Wed, Jul 05, 2023, 10:59 AM UTC

llogiq wrote: post #3

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 requ…

> We've all seen the backswing to statically typed languages.

I think, in general, we've seen the hype cycle shift from static to dynamic to static, and we see that e.g. startups and otherwise highly opinionated people who care about such things maybe change their preferences (or simply new people entering the field with new preferences), but...

the millions of people writing Java code didn't go away when Ruby and later Node were all the rage, and all the PHP jobs also still exist.

Trends come and go, but dynamic and static typing have coexisted since forever. LISP is the second oldest language and if that's too niche, Smalltalk was decently popular for a while.

I also agree though that modern statically typed languages are much better than e.g. Java used to be.

Re: Dynamic Languages Strike Back (2008)

#43

Post by pjmlp » Wed, Jul 05, 2023, 11:03 AM UTC

Tainnor wrote: post #41

pjmlp wrote: post #27

Earlier quoted context omitted.

They were never better than Maven and NuGET, regarding the use cases, and corner cases.

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 thi…

It is still better than many alternatives, and the lengthy description about Ruby kind of proves my point.

Re: Dynamic Languages Strike Back (2008)

#44

Post by Tainnor » Wed, Jul 05, 2023, 11:09 AM UTC

dehrmann wrote: post #22

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

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").

Re: Dynamic Languages Strike Back (2008)

#45

Post by Tainnor » Wed, Jul 05, 2023, 11:14 AM UTC

pjmlp wrote: post #43

Tainnor wrote: post #41

Earlier quoted context omitted.

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 thi…

It is still better than many alternatives, and the lengthy description about Ruby kind of proves my point.

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.

Re: Dynamic Languages Strike Back (2008)

#46

Post by kentonv » Wed, Jul 05, 2023, 4:19 PM UTC

shellac wrote: post #13

kentonv wrote: post #8

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 m…

> 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.

Yes, but outside of Java developers a lot of people didn't understand the power of this yet.

Re: Dynamic Languages Strike Back (2008)

#47

Post by frou_dh » Thu, Jul 06, 2023, 12:52 PM UTC

MrJohz wrote: post #28

zerodensity wrote: post #17

Earlier quoted context omitted.

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…

As I understand it, even for a jit compiler, the type annotations are typically less useful than runtime behaviour. For example, at runtime, a type might typically be narrower than the compile time declaration. Also, with most gradually typed languages, the types aren't enforced at runtime, and the type system can often be circumvented, which means basing optimisations on the declared type hints will send the optimis…

Put it like this... programmer in language X expends the effort to write a well-typed codebase and is rewarded with both reliability and performance. Programmer in Python expends the effort to write a well-typed codebase and only receives half the reward. Kinda tragic you have to admit.

Re: Dynamic Languages Strike Back (2008)

#48

Post by uranusjr » Thu, Jul 06, 2023, 7:09 PM UTC

MrJohz wrote: post #28

zerodensity wrote: post #17

Earlier quoted context omitted.

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…

As I understand it, even for a jit compiler, the type annotations are typically less useful than runtime behaviour. For example, at runtime, a type might typically be narrower than the compile time declaration. Also, with most gradually typed languages, the types aren't enforced at runtime, and the type system can often be circumvented, which means basing optimisations on the declared type hints will send the optimis…

> As I understand it, even for a jit compiler, the type annotations are typically less useful than runtime behaviour.

What I’ve heard from people who work on performance is, the type hints can provide benefits potentially, but just not relatively as useful as other runtime improvements. The development effort is simply better placed elsewhere.