Dynamic Languages Strike Back (2008)
11–20 of 48 posts
Re: Dynamic Languages Strike Back (2008)
#12Yeah, 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're seeing a swing to what I call "pragmatically typed" languages: those with extensive type inference and possible escape hatches.
Re: Dynamic Languages Strike Back (2008)
#13I 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…
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.
Re: Dynamic Languages Strike Back (2008)
#14Re: Dynamic Languages Strike Back (2008)
#15I 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…
The main issue is that static typing is a global property of a program, and big distributed systems don't have such global properties. Each part can be upgraded independently, at any time.
In general, you don't own both sides of the wire. People who have worked at Google are used to owning both sides of the wire :) (I also think the model of the data center as a single computer stopped scaling, and that's why it's so hard to write software there these days)
The argument I usually make is: Why isn't the entire Internet statically typed? Why don't we have statically typed HTTP and SMTP and IRC and XMPP ?
If you admit there's a problem there, then there are also problems with static typing in the areas where people use JSON.
---
Dynamic typing is basically for when static typing stops scaling / runs out of steam.
I wrote a long post about this - A Sketch of the Biggest Idea in Software Architecture, i.e. about software composition at runtime, not compile time:
https://www.oilshell.org/blog/2022/03/backlog-arch.html
Also, static typing doesn't scale to the code even on a SINGLE machine, on either Windows (COM and successors) or Linux (Debian-style ABI compatibility, and shell-style composition)
https://lobste.rs/s/sqtnxf/shells_are_two_things#c_pa4wqo
Some people scratched their heads at that argument, but I would say it's only irrelevant if you don't care if your system works when it's deployed. If all you want is for the IDE to say green and commit your code, then you can just lean on static typing. But if you care the problem from end-to-end, you should also care about dynamic typing and runtime software composition :)
The other argument I make is that SREs are responsible for all the problems that escaped the static type system, and ~10 years ago SREs started making as much or more money than SWEs. So that is a lot of problems.
The problems that static types catch aren't the most important ones; they're just the ones that affect certain people's jobs.
---
Protobufs do a pretty good job of evolution, but I've noticed it takes awhile for people to understand that field presence is dynamic, not static. They want their Maybe type, but that kind of static typing simply doesn't work in distributed systems.
I'd say better tools could help in some ways, but you still have the fundamental problem that even if I go and download Github's or Stripe's schema from their codebase and statically link it into my code, I don't control when they deploy their systems.
They can literally update it in the FUTURE, and static checks fundamentally can't handle that -- only dynamic checks can.
Re: Dynamic Languages Strike Back (2008)
#16Yeah, 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…
Re: Dynamic Languages Strike Back (2008)
#17Earlier quoted context omitted.
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 cou…
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.
Re: Dynamic Languages Strike Back (2008)
#18I 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.
Re: Dynamic Languages Strike Back (2008)
#19I 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.
Re: Dynamic Languages Strike Back (2008)
#20Yeah, 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…
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 cou…