Live data from Hacker News

Dynamic Languages Strike Back (2008)

steve-yegge.blogspot.com

21–30 of 48 posts

Re: Dynamic Languages Strike Back (2008)

#21
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…

> current crop of compilers not only can produce stunningly fast code

There are highly dynamic languages like Lisp that have implementations that have generated “stunningly fast code” for ages.

Re: Dynamic Languages Strike Back (2008)

#23
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…

> You'd ~~write code for a while, then you'd run the compiler,~~ run code, and UGH there's all these errors to go back through and fix.

The error checking nature of compilers was never a real pain point. It's a question of if you want pain now or later.

Re: Dynamic Languages Strike Back (2008)

#25
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…

What are you even talking about? The amount of JavaScript and Python in the world has probably grown exponentially since that article was written. The article points out that there are ways to make dynamic languages faster and JavaScript interpreters have indeed been made blazingly fast since this article.

Sure a handful of people use Rust now and Swift and Go now, but I think you missed the whole point of the fine article

Re: Dynamic Languages Strike Back (2008)

#26
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…

JSON is better than xml which it replaced. It's now such a defacto standard that if you make an API without json it will just be a hassle for your api users. Doesn't really matter if your encoding format is better or not.

You can still have schemas in the code through. We use alot of pydantic at work for this. You have your data schema class that is statically typed which you interact with and decide/encode it to json in the background.

All services expose an api to get JSON schemas from the apis so you can automatically generate the remote types used by other services when they change.

Using schemas for remote services has made life simpler for us so I would say schemas are a huge win. Not supporting JSON is not something I see happening anytime soon though, multiple parallel encodings based on schemas might be a possibility though.

Re: Dynamic Languages Strike Back (2008)

#27

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.

Re: Dynamic Languages Strike Back (2008)

#28
post #6

Earlier quoted context omitted.

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.

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 optimiser down useless rabbit holes.

That said, I agree with the rest of your comment - static types for correctness and static types for performance are two different goals, and most gradually typed systems work towards the former and not the matter. (And more to the point: adding types alone is not sufficient for the latter. Python is not slow because it has no types, Python is slow because it isn't designed to be fast, and changing that now would require a lot of fundamental changes to the language and ecosystem, of which types would be one of the least relevant.)

Re: Dynamic Languages Strike Back (2008)

#29
post #7
post #5

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

Well, if the programmer writes the type annotation to actually have their code checked, how would a gradually typed language differ in practice from a static language? Yes, you can still do dynamic typing. But I'd argue that using `dyn Any` you can do so in Rust, which is a statically typed language if I ever saw one. Otherwise I completely agree about the languages growing closer together.

Here's a practical example: you have your beautiful statically typed check code in python. But still, something doesn't work, or works but is too slow. So you write, in less than a page of code, some function to instrument bits of code you care about to collect and display some relevant info as the thing is running.

Dyn Any is precisely no use here. If it's a simple on/off thing, you can maybe hack up some macro in rust, but that's a completely different (and not very well designed) language, will require you to manually modify all the source you want to instrument, and also if you want do dynamically alter at runtime what gets instrumented based you're out of luck.

Basically, there can be a lot of value in sporadically leveraging the dynamic nature of python or similar languages, even if you use it as a poor man's statically typed language > 99% of the time.

Re: Dynamic Languages Strike Back (2008)

#30
post #25
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…

What are you even talking about? The amount of JavaScript and Python in the world has probably grown exponentially since that article was written. The article points out that there are ways to make dynamic languages faster and JavaScript interpreters have indeed been made blazingly fast since this article. Sure a handful of people use Rust now and Swift and Go now, but I think you missed the whole point of the fine a…

Except both Javascript and Python - along with a bunch of other dynamic languages such as Ruby and Elixir - are adopting gradual typing into the ecosystem. In both Javascript and Python, most of the major libraries and frameworks are either typed directly, or provide typings. It's difficult to get a good overview of the ecosystem on the closed source side of things, but most of the people I talk to in the Javascript world are moving pretty quickly towards Typescript, or have done it already.

But the key thing is that none of this is for performance purposes. Which is kind of the whole point of this talk: speed isn't everything, and the productivity of languages without types outweighs that of languages with types. But it turns out that types are really useful even without any sort of performance benefit, hence why a lot of languages are turning back to typing code without using those types at runtime at all.

Or similarly, he makes a point about how it's often possible to statically analyse dynamic languages, which is true, but it turns out that it's still so much easier to analyse statically typed languages that adding types back in often makes sense. If you read library documentation for packages using gradual typing, this is often one of the things they specifically mention as a reason for using their library with static types instead of without.

The point, as I understood it, was that you don't need static types to still get lots of cool things (performance, analysis, etc). Which is stuff I don't disagree with. But the quality of those things with (well-designed) static languages is still so much higher than it is in dynamic languages, which is why so many languages are now trying to support both modes.

Post reply on HN