8 ms·

As a static typing advocate I do find it funny how all the popular dynamic languages have slowly become statically typed. After decades of people saying it's no

• adalacelove 1y ago
  People adapt to the circumstances. A lot of Python uses are no longer about fast iteration on the REPL. Instead of that we are shipping Python to execute in clusters on very long running jobs or inside servers. It's not only about having to start all over after hours, it's simply that concurrent and distributed execution environments are hostile to interactive programming. Now you can't afford to wait for an exception and launch the debugger in postmortem. Or even if you do it's not very useful. And now my personal opinion: If we are going the static typing way I would prefer simply to use Scala or similar instead of Python with types. Unfortunately in the same way that high performance languages like C attracts premature optimizers static types attract premature "abstracters" (C++ both). I also think that dynamic languages have the largest libraries for technical merit reasons. Being more "fluid" make them easier to mix. In the long term the ecosystem converges organically on certain interfaces between libraries. And so here we are with the half baked approach of gradual typing and #type: ignore everywhere.
  • yurishimo 1y ago
    PHP is a great example of the convergence of interfaces. Now they have different “PSR” standards for all sorts of things. There is one for HTTP clients, formatting, cache interfaces, etc. As long as your library implements the spec, it will work with everything else and then library authors are free to experiment on the implementation and contribute huge changes to the entire ecosystem when they find a performance breakthrough. Types seem like a “feature” of mature software. You don’t need to use them all the time, but for the people stuck on legacy systems, having the type system as a tool in their belt can help to reduce business complexity and risk as the platform continues to age because tooling can be built to assert and test code with fewer external dependencies.
  • pydry 1y ago
    Here we are because: * Types are expensive and dont tend to pay off on spikey/experimental/MVP code, most of which gets thrown away. * Types are incredibly valuable on hardened production code. * Most good production code started out spikey, experimental or as an MVP and transitioned. And so here we are with gradual typing because "throwing away all the code and rewriting it to be "perfect" in another language" has been known for years to be a shitty way to build products. Im mystified that more people here dont see that the value and cost of types is NOT binary ("they're good! theyre bad!") but exists on a continuum that is contingent on the status of the app and sometimes even the individual feature.
    • tossandthrow 1y ago
      The issue with moving the ship where it's passanger wants it to be makes it more difficult for new passengers to get on. This is clearly seen with typescript and the movement for "just use JS". Furthermore, with LLMs, it should be easier than ever to experiment in one language and use another language for production loads.
    • adalacelove 1y ago
      In some fields throwing away and rewriting is the standard, and it works, more or less. I'm thinking about scientific/engineering software: prototype in Python or Matlab and convert to C or C++ for performance/deployment constraints. It happens frequently with compilers too. I think migrating languages is actually more successful than writing second versions.
    • cyberax 1y ago
      > * Types are expensive and dont tend to pay off on spikey/experimental/MVP code, most of which gets thrown away. Press "X" to doubt. Types help _a_ _lot_ by providing autocomplete, inspections, and helping with finding errors while you're typing. This significantly improves the iteration speed, as you don't need to run the code to detect that you mistyped a varible somewhere.
      • mixmastamyk 1y ago
        Pycharm, pyflakes, et all can do most of these without written types. The more interesting questions, like “should I use itertools or collections?” Autocomplete can’t help with.
  • zero_bias 1y ago
    Python is ubiquitous in ML, often you have no choice but to use it
  • huflungdung 1y ago
    [dead]
• aurareturn 1y ago
  Javascript is no longer was just scripting. Very large and complex billion dollar apps were being written in pure Javascript. It grew up. I guess Python is next.
• Elucalidavah 1y ago
  > how all the popular dynamic languages have slowly become statically typed Count the amount of `Any` / `unknown` / `cast` / `var::type` in those codebases, and you'll notice that they aren't particularly statically typed. The types in dynamic languages are useful for checking validity in majority of the cases, but can easily be circumvented when the types become too complicated. It is somewhat surprising that dynamic languages didn't go the pylint way, i.e. checking the codebase by auto-determined types (determined based on actual usage).
  • jakobnissen 1y ago
    Julia (by default) does the latter, and its terrible. It makes it a) slow, because you have to do nonlocal inference through entire programs, b) impossible to type check generic library code where you have no actual usage, c) very hard to test that some code works generically, as opposed to just with these concrete types, and finally d) break whenever you have an Any anywhere in the code so the chain of type information is broken.
• pansa2 1y ago
  > all the popular dynamic languages have slowly become statically typed I’ve heard this before, but it’s not really true. Yes, maybe the majority of JavaScript code is now statically-typed, via Typescript. Some percentage of Python code is (I don’t know the numbers). But that’s about it. Very few people are using static typing in Ruby, Lua, Clojure, Julia, etc.
  • Kwpolska 1y ago
    How many people are using Ruby, Lua, Clojure, Julia, etc.?
    • pansa2 1y ago
      Fair enough, apart from Ruby they’re all pretty niche. OTOH I’m not arguing that most code should be dynamically-typed. Far from it. But I do think dynamic typing has its place and shouldn’t be rejected entirely. Also, I would have preferred it if Python had concentrated on being the best language in that space, rather than trying to become a jack-of-all-trades.
  • Hamuko 1y ago
    I have my doubts about majority of JavaScript being TypeScript.
    • pansa2 1y ago
      You’re probably right. RedMonk [0] shows JavaScript and TypeScript separately and has the former well above the latter. [0] https://redmonk.com/sogrady/2025/06/18/language-rankings-1-25/ https://redmonk.com/sogrady/2025/06/18/language-rankings-1-2...
    • seanparsons 1y ago
      Even if they're not written as TypeScript, there are usually add on definitions like "@types/prettier" and the like.
  • majoe 1y ago
    I disagree for Julia, but that probably depends on the definition of static typing. For the average Julia package I would guess, that most types are statically known at compile time, because dynamic dispatch is detrimental for performance. I consider, that to be the definition of static typing. That said, Julia functions seldomly use concrete types and are generic by default. So the function signatures often look similar to untyped Python, but in my opinion this is something entirely different.
• vladms 1y ago
  I like static types but advocating for enforcing them in any situation is different. Adding them when you need (Python currently) seems a better strategy than forcing you to set them always (Typescript is in between as many times it can determine them). Many years ago I felt Java typing could be overkill (some types could have been deduced from context and they were too long to write) so probably more an issue about the maturity of the tooling than anything else.
• flohofwoe 1y ago
  OTH I only came to realize that I actually like duck typing in some situations when I tried to add type hints to one of my Python projects (and then removed them again because the actually important types consisted almost entirely of sum types, and what's the point of static typing if anything is a variant anyway). E.g. when Python is used as a 'scripting language' instead of a 'programming language' (like for writing small command line tools that mainly process text), static typing often just gets in the way. For bigger projects where static typing makes sense I would pick a different language. Because tbh, even with type hints Python is a lousy programming language (but a fine scripting language).
  • lolive 1y ago
    Note1: Type hints are hints for the reader. If you cleverly discovered that your function is handling any type of data, hint that! Note2: From my experience, in Java, i have NEVER seen a function that consumes explicitely an Object. In Java, you always name things. Maybe with parametric polymorphism, to capture complex typing patterns. Note 3: unfortunately, you cannot subclass String, to capture the semantic of its content.
    • 1313ed01 1y ago
      > Java, i have NEVER seen a function that consumes explicitely an Object So you did not see any Java code from before version 5 (in 2004) then, because the language did not have generics for the first several years it was popular. And of course many were stuck working with older versions of the language (or variants like mobile Java) without generics for many years after that.
      • lolive 1y ago
        Exactly, I have never seen such codes [*]. Probably because the adoption of the generics has been absolutely massive in the last 20 years. And I expect the same thing to eventually happen with Typescript and [typed] Python. [*]: nor have I seen EJB1 or even EJB2. Spring just stormed them, in the last 20 years.
    • 1y ago
• lolive 1y ago
  Next stop is to agree that JSON is really NOT the semantic data exchange serialization for this "properly typed" world.
  • dotancohen 1y ago
    Then what is? Everybody knows the limitations of JSON. Don't state the obvious problem without stating a proposed solution.
    • lolive 1y ago
      The RDF structure is a graph of typed instances of typed objects, serializable as text. Exchanging RDF, more precisely its [more readable] "RDF/turtle" variant, is probably what will eventually come to the market somehow. Each object of a RDF structure has a global unique identifier, is typed, maintains typed links with other objects, have typed values.
      • lolive 1y ago
        For an example of RDF being exchanged between a server and a client, you can test https://search.datao.net/beta/?q=barack%20obama https://search.datao.net/beta/?q=barack%20obama Open your javascript console, and hover the results on the left hand side of the page with your mouse. The console will display which RDF message triggered the viz in the center of the page. Update: you may want to FIRST select the facet "DBPedia" at the top of the page, for more meaningful messages exchanged. Update2: the console does not do syntax higlighting, so here is the highlighted RDF https://datao.net/ttl.jpg https://datao.net/ttl.jpg linked to the 1st item of " https://search.datao.net/beta/?q=films%20about%20barack%20obama# https://search.datao.net/beta/?q=films%20about%20barack%20ob... "
      • dotancohen 1y ago
        That's a circular argument. What serialization format would you recommend? JSON?
        • 1y ago
• bushbaba 1y ago
  I think both found middle ground. In Java you don’t need to define the type of variables within the method. In Python people have learned types in method arguments is a good thing.
• isodev 1y ago
  > After decades of people saying You have to admit that the size and complexity of the software we write has increased dramatically over the last few "decades". Looking back at MVC "web applications" I've created in the early 2000s, and comparing them to the giant workflows we deal with today... it's not hard to imagine how dynamic typing was/is ok to get started, but when things exceed one's "context", you type hints help.
• jmorenoamor 1y ago
  Coming from Java extreme verbosity, I just loved the freedom of python 20 years ago. Working with complex structures with mixed types was a breeze. Yes, it was your responsibility to keep track of correctness, but that also taught me to write better code, and better tests.
  • procaryote 1y ago
    Writing tests is harder work than writing the equvalent number of type hints though
    • dirkc 1y ago
      Type hints and/or stronger typing in other languages are not good substitutes for testing. I sometimes worry that teams with strong preferences for strong typing have a false sense of security.
      • procaryote 1y ago
        People write tests in statically typed languages too, it's just that there's a whole class of bugs that you don't have to test for.
    • mixmastamyk 1y ago
      Hints are not sufficient, you’ll need tests anyway. They somewhat overlap.
  • ivanjermakov 1y ago
    Writing and maintaining tests that just do type checking is madness. Dynamic typing also gives tooling such as LSPs and linters a hard time figuring out completions/references lookup etc. Can't imagine how people work on moderate to big projects without type hints.
• afiori 1y ago
  In the discussion of static vs dynamic typing solutions like typescript or annotated python were not really considered. IMHO the idea of a complex and inference heavy type system that is mostly useless at runtime and compilation but focused on essentially interactive linting is relatively recent and its popularity is due to typescript success I think that static typing proponents were thinking of something more along the lines of Haskell/OCaml/Java rather than a type-erased system a language where [1,2] > 0 is true because it is converted to "NaN" > "0"
• al_be_back 1y ago
  dynamically-typed languages were typically created for scripting tasks - but ended up going viral (in part due to d-typing), the community stretched the language to its limits and pushed it into markets it wasn't designed/thought for (embedded python, server-side js, distributed teams, dev outsourcing etc). personally i like the dev-sidecar approach to typing that Python and JS (via TS) have taken to mitigate the issue.
• kubb 1y ago
  What I would need is a statically typed language that has first class primitives for working with untyped data ergonomically. I do want to be able to write a dynamically typed function or subsystem during the development phase, and „harden” with types once I’m sure I got the structure down. But the dynamic system should fit well into the language, and I should be able to easily and safely deal with untyped values and convert them to typed ones.
  • promiseofbeans 1y ago
    So… Typescript?
    • whizzter 1y ago
      Yes, the sad part is that some people experienced early TypeScript that for some reason had the idea of forcing "class" constructs into a language where most people wasn't using or needing them (and still aren't). Sometimes at about TypeScript 2.9 finally started adding constructs that made gradual typing of real-world JS code sane, but by then there was a stubborn perception of it being bad/bloated/Java-ish,etc despite maturing into something fairly great.
    • kubb 1y ago
      I like Typescript :)
• pjmlp 1y ago
  Thing is, famous dynamic languages of the past, Common Lisp, BASIC, Clipper, FoxPro, all got type hints for a reason, then came a new generation of scripting languages made application languages, and everyone had to relearn why the fence was in the middle of the field.
• cardanome 1y ago
  > slowly become statically typed They don't. They become gradually typed which is a thing of it's own. You can keep the advantages of dynamic languages, the ease of prototyping but also lock down stuff when you need to. It is not a perfect union, generally the trade-off is that you can either not achieve the same safety level as in a purely statically typed language because you need to provide same escape hatches or you need a extremely complex type system to catch the expressiveness of the dynamic side. Most of the time it is a mixture of both. Still, I think this is the way to go. Not dynamic typing won or static typing won but both a useful and having a language support both is a huge productivity boost.
• Sharlin 1y ago
  Everything goes in cycles. It has happened before and it will happen again. The softward industry is incredibly bad at remembering lessons once learned.
• mhitza 1y ago
  I think you're ignoring how for some of us, gradual typing, is a far better experience than languages with static types. For example what I like about PHPStan (tacked on static analysis through comments), that it offers so much flexibility when defining type constraints. Can even specify the literal values a function accepts besides the base type. And subtyping of nested array structures (basically support for comfortably typing out the nested structure of a json the moment I decode it).
  • seanparsons 1y ago
    Not ignoring, I just didn't write an essay. In all that time working with TypeScript there was very little that I found to be gradually typed, it was either nothing or everything, hence my original comment. Sure some things might throw in a bunch of any/unknown types but those were very much the rarity and often some libraries were using incredibly complicated type definitions to make them as tight as possible.
    • choomahs187 1y ago
      Worked with python, typescript and now php, seems that phpstan allows this gradual typing, while typescript kinda forces you to start with strict in serious projects.
• whizzter 1y ago
  That's because many do small things that don't really need it, sure there are some people doing larger stuff and are happy to be the sole maintainer of a codebase or replace the language types with unit-test type checks. And I think they can be correct for rejecting it, banging out a small useful project (preferably below 1000 loc) flows much faster if you just build code doing things rather than start annotating (that quickly can be come a mind-sinkhole of naming decisions that interrupts a building flow). However, even less complex 500 loc+ programs without typing can become a pita to read after the fact and approaching 1kloc it can become a major headache to pick up again. Basically, can't beat speed of going nude, but size+complexity is always an exponential factor in how hard continuing and/or resuming a project is.
• crabbone 1y ago
  Same nonsense repeated over and over again... There aren't dynamic languages. It's not a thing. The static types aren't what you think they are... You just don't know what you are saying and your conclusion is just a word salad. What happened to Python is that it used to be a "cool" language, whose community liked to make fun of Java for their obsession with red-taping, which included the love for specifying unnecessary restrictions everywhere. Well, just like you'd expect from a poorly functioning government office. But then everyone wanted to be cool, and Python was adopted by the programming analogue of the government bureaucrats: large corporations which treat programming as a bureaucratic mill. They don't want fun or creativity or one-of bespoke solutions. They want an industrial process that works on as large a scale as possible, to employ thousands of worst quality programmers, but still reliably produce slop. And incrementally, Python was made into Java. Because, really, Java is great for producing slop on an industrial scale. But the "cool" factor was important to attract talent because there used to be a shortage, so, now you have Python that was remade to be a Java. People who didn't enjoy Java left Python over a decade ago. So that Python today has nothing in common with what it was when it was "cool". It's still a worse Java than Java, but people don't like to admit defeat, and... well, there's also the sunk cost fallacy: so much effort was already spent at making Python into a Java, that it seems like a good idea to waste even more effort to try to make it a better Java.
  • ModernMech 1y ago
    Yeah, this is the lens through which I view it. It's a sort of colonization that happens, when corporations realize a language is fit for plunder. They start funding it, then they want their people on the standards boards, then suddenly the direction of the language is matched very nicely to their product roadmap. Meanwhile, all the people who used to make the language what it was are bought or pushed out, and the community becomes something else entirely.
• ktosobcy 1y ago
  Well, we do coalesce on certain things... some static type languages are dropping type requirements (Java and `var` in certain places) :D
  • constantcrying 1y ago
    var does absolutely nothing to make Java a less strictly typed language. There is absolutely no dropping of the requirement that each variable has a type which is known at compile time. Automatic type inference and dynamic typing are totally different things.
    • hirvi74 1y ago
      I have not written a line of Java in at least a decade, but does Java not have any 'true' dynamic typing like C# does? Truth be told, the 'dynamic' keyword in C# should only be used in the most niché of circumstances. Typically, only practitioners of Dark Magic use the dynamic type. For the untrained, it often leads one down the path of hatred, guilt, and shame. For example: dynamic x = "Forces of Darkness, grant me power"; Console.WriteLine(x.Length); // Dark forces flow through the CLR x = 5; Console.WriteLine(x.Length); // Runtime error: CLR consumed by darkness. C# also has the statically typed 'object' type which all types inherit from, but that is not technically a true instance of dynamic typing.
  • moefh 1y ago
    There's no dropping of type requirements in Java, `var` only saves typing. When you use `var`, everything is as statically typed as before, you just don't need to spell out the type when the compiler can infer it. So you can't (for example) say `var x = null` because `null` doesn't provide enough type information for the compiler to infer what's the type of `x`.
    • procaryote 1y ago
      > `var` only saves typing. this is a lovely double entendre
• constantcrying 1y ago
  The need for typing changed, when the way the language is used changed. When JavaScript programs were a few hundred lines to add interactivity to some website type annotationd were pretty useless. Now the typical JavaScript project is far larger and far more complex. The same goes for python.
• LudwigNagasena 1y ago
  Static typing used to be too rigid and annoying to the point of being counterproductive. After decades of improvement of parsers and IDEs they finally became usable for rapid development.
• DarkNova6 1y ago
  Huh. It's almost like these people didn't know what they were talking about. How strange.
• tetha 1y ago
  I think that the practically available type checkers evolved to a point where many of the common idioms can be expressed with little effort. If one thinks back to some of the early statically typed languages, you'd have a huge rift: You either have this entirely weird world of Caml and Haskell (which can express most of what python type hints have, and could since many years), and something like C, in which types are merely some compiler hints tbh. Early Java may have been a slight improvement, but eh. Now, especially with decent union types, you can express a lot of idioms of dynamic code easily. So it's a fairly painless way to get type completion in an editor, so one does that.
• theptip 1y ago
  Type hints / gradual typing is crucially different from full static typing though. It’s valid to say “you don’t need types for a script” and “you want types for a multi-million LOC codebase”.
• jshen 1y ago
  Trends change. There is still no hard evidence that static types are net positive outside of performance.
• screye 1y ago
  AI tab-complete & fast LSP implementations made typing easy. The tools changed, and people changed their minds. JSON's interaction with types is still annoying. A deserialized JSON could be any type. I wish there was a standard python library that deserialized all JSON into dicts, with opinionated coercing of the other types. Yes, a custom normalizer is 10 lines of code. But, custom implementations run into the '15 competing standards' problem. Actually, there should be a popular type-coercion library that deals with a bunch of these annoying scenarios. I'd evangelize it.