[HN Gopher] Dynamic Languages Strike Back (2008)
___________________________________________________________________
Dynamic Languages Strike Back (2008)
Author : curling_grad
Score : 44 points
Date : 2023-07-03 12:31 UTC (1 days ago)
(HTM) web link (steve-yegge.blogspot.com)
(TXT) w3m dump (steve-yegge.blogspot.com)
| dehrmann wrote:
| There's a joke that dynamically typed languages are just
| statically typed languages with one type: hashtable.
| [deleted]
| bluefishinit wrote:
| 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 wrote:
| 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 wrote:
| They were never better than Maven and NuGET, regarding the use
| cases, and corner cases.
| llogiq wrote:
| 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!
| novok wrote:
| IMO I miss static typing at around the 500 line mark especially
| when making programs. I was surprised it was that fast.
| marcelr wrote:
| Give it another 10 years, it'll swing back.
|
| Dynamic languages increase productivity, static languages learn
| from dynamic languages & find ways to statically verify the
| previously thought dynamic patterns.
| jmull wrote:
| 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.
| lelanthran wrote:
| Optional typing is closer to dynamically typed than to
| statically typed.
| frou_dh wrote:
| 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 wrote:
| 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.
| MrJohz wrote:
| 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.)
| howinteresting wrote:
| Static types are at a ~45 degree angle to performance,
| not orthogonal. Static types are essential for optimizing
| code and data layout, which contribute hugely to
| performance.
|
| It is valid to critique gradually typed systems like
| Python for not improving performance.
| llogiq wrote:
| 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.
| patrec wrote:
| 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.
| LispSporks22 wrote:
| > 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.
| spankalee wrote:
| TypeScript is not a statically typed language. It's more like a
| type-aware linter for a dynamic language. It doesn't "run on"
| JavaScript, it more-or-less _is_ JavaScript. Any runtime
| helpers that TypeScript includes are merely polyfills for
| JavaScript features and compiling to the esnext target includes
| no runtime code at all.
|
| TypeScript isn't faster than JavaScript, it doesn't even change
| it's emit based on types - which are completely erased.
|
| Similarly, Python with type annotations is not a statically
| typed language either.
| behnamoh wrote:
| > So while we have a lot of python in ML (where most things
| haven't left prototyping stage)...
|
| That's a really good observation. Many people ask why Python is
| the lingua franca of ML. It's a glue language that allows you
| to prototype quickly and use low-level libraries like numpy for
| matrix calculations, etc.
|
| I wish Python type hints were taken more seriously. It's crazy
| that you can type them in function definitions but then Python
| completely ignores them. mypy does a much better job at that,
| but that's not the Python most people use.
| troupo wrote:
| > We've all seen the backswing to statically typed languages.
|
| We're seeing a swing to what I call "pragmatically typed"
| languages: those with extensive type inference and possible
| escape hatches.
| krupan wrote:
| 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
| MrJohz wrote:
| 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.
| agnosticmantis wrote:
| Recording of the lecture:
|
| https://youtu.be/tz-Bb-D6teE
| kentonv wrote:
| 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.)
| dehrmann wrote:
| > 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.
| shellac wrote:
| > 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]
| maccard wrote:
| Eclipse was available and free long before 2008. C++ had had
| visual studio, as has c# for longer than that too.
| howinteresting wrote:
| 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.
| make3 wrote:
| Python is everywhere for ML, Javascript & it's dialects are
| everywhere for web etc., so dynamic languages are definitely
| everywhere now
| chubot wrote:
| _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_
|
| 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.
| cxr wrote:
| > 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.
|
| You're not wrong, but you are underselling what reasonably
| disciplined adherents to a static regime can use to their
| advantage.
|
| ----
|
| My favorite commentary (in favor of your position of what
| static can't do*) include:
|
| - some remarks Gilad Bracha once made on some podcast
| (might've been Software Engineering Radio) about how hardware
| at base is not static, which feels somewhat counterintuitive
| when low high-level languages like C are in the same room
| suggesting that the truth is otherwise
|
| - Lars Bak giving an interview about V8 at Microsoft to Erik
| Meijer and Charles Torre(?) where Lars breaks the latter's
| brain by pointing out that even if JS hadn't won and you were
| dealing with a purportedly better static language like C#
| compiled down to CIL, then the engine would still apply the
| same treatment to the payload it received, insofar as
| performing "inefficient" dynamic validation
|
| * which happens to be my position, too, to be clear
| zerodensity wrote:
| 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.
| chucke wrote:
| Let's meet again in 20 years, when developers discover dynamic
| languages again.
| raphlinus wrote:
| 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
___________________________________________________________________
(page generated 2023-07-04 23:02 UTC)