9 ms·

I feel like the dynamic typing crowd are slowly coming around to the fact that having a typesystem is just better. While we’re on the topic, a better typesyste

I feel like the dynamic typing crowd are slowly coming around to the fact that having a typesystem is just better. While we’re on the topic, a better typesystem is better than a worse typesystem. Thanks for coming to my TED talk.

btilly 2y ago
No. It's that when people who prefer type systems go to use a popular dynamic language, they try to drag in features that they like from other languages. Very honestly, optional type systems tend to be the worst of all worlds. Because people who don't care, don't need to use it, you don't get safety. But people who enjoy ceremony can inflict verbosity on others. While missing the most important reason to do it.
- paulddraper 2y ago
  Optional types are the best.* I can prototype, script, move fast. Then I can solidify, stabilize, collaborate. * To get top performance, of course you'll need compiler, types, static dispatch.
  - binary132 2y ago
    I find that good types help me model the problem and solution with clarity, and the procedures and functions take a back seat. After all, most procedures are just transformations of structured data, so putting the datastructure first makes good sense and keeps the code clean and lean. I used to believe in the “moving fast with no types” thing but in practice I find myself modeling the problem either way, it’s just clumsier without strong types.
    - paulddraper 2y ago
      It depends how large the problem is.
    - josephg 2y ago
      Yep. And even when prototyping, I make a lot more dumb mistakes without a type checker watching my back. It’s amazing how quickly a few interfaces / typedefs repay the time you spent typing them in.
  - btilly 2y ago
    Common Lisp was the first language I'm aware of with optional typing. In theory, what you're saying is true. In practice there's a lot of pressure to ship the working prototype, and retrofitting types on it later doesn't actually happen. The result was a reputation for being slow. (This was back when computers were slow enough that the overhead of being dynamic was pretty painful.)
    - paulddraper 2y ago
      Yep, hence the perf caveat.
- binary132 2y ago
  I’m not into the whole optional typing thing either. I would consider that far down the “worse typesystem” end of the spectrum I mentioned, only slightly better than “types are just arbitrary labels the language doesn’t even know about”, which is maybe even worse than lean dynamic typesystems, because you might make the mistake of believing in the shadows on the wall.
  - jimmaswell 2y ago
    “types are just arbitrary labels the language doesn’t even know about” is ok if you're aware of the limitations. I add typedefs and other jsdocs to javascript just because it makes it easier to work with in an IDE. it's nice to hover over a variable and see what it's "supposed" to be (if all went well this object should have a .id, might have a .name, etc), sometimes even declared as two types like "this variable is either an int or a boolean". I don't really want to bother learning typescript or trying to get coworkers to do so/put it in the pipeline so it's the best I can do and it certainly makes life a bit easier.
    - pistoleer 2y ago
      > if all went well this object should Why not make it easier for yourself and be able to turn that into > The compiler will tell me when this object won't
      - jimmaswell 2y ago
        the JavaScript language standard is sadly out of my control, and I'm stuck with it.
- gklitz 2y ago
  > No. It's that when people who prefer type systems go to use a popular dynamic language, they try to drag in features that they like from other languages. Very much. The “problem” people try to solve with things like dependency injection isn’t even a problem in python. 99.99% of the time you can just import you dependencies everywhere they are needed. So many times now I’ve had to unteach bulky OOP patterns for people coming from strictly typed languages to python believe are “good practices” or are “needed for reliable code” and you go from 20 different interdependent classes down to 3 functions that just directly do what they are supposed to do. And you always end up with someone being disappointed that all of these complex patterns they learned to solve problems that don’t exist in python aren’t needed, rather than someone just happy that you can proceed directly to a value adding solution and skip the crud and design pattern spam. And then they start arguing crazy stuff like the 200 extra lines unneeded code makes the solution “more readable” or “more reliable”, when in reality it’s just a desire to use the solutions they are used to even when the problems don’t exist.
  - indigo945 2y ago
    > The “problem” people try to > solve with things like > dependency injection isn’t > even a problem in python. > 99.99% of the time you can > just import you dependencies > everywhere they are needed. That's... Just not the problem DI fixes in any language? Sure, in C++ or Java you can just create a global static instance and use that everywhere. That's pretty much equivalent to just importing the same thing everywhere. But the downside of both approaches is testability: it becomes much harder to test units in isolation when they access global resources. Consider a function with `import datetime`, that gets the current time and does something with it. You want to make sure that this function still does the right thing in the extreme case of the current time being 23:59:59. How do you write this test without DI?
    - wizzwizz4 2y ago
      Easily. from datetime import datetime, timedelta def f(): now = datetime.now() future = now + timedelta(seconds=1) return now.time() < future.time() from unittest.mock import patch with patch('__main__.datetime', spec=datetime, side_effect=datetime) as mockdt: mockdt.now.return_value = datetime(2024, 10, 3, 23, 59, 59) assert f() If `datetime.datetime` were implemented in pure Python, one could even use `patch.object` here, saving a line.
- HelloNurse 2y ago
  Python type annotations are a good source of lightweight, easy to maintain metadata for many frameworks that provide valuable automatic handling of specific data types (for example defining deserialization and deserialization of nice class types with field declarations, like attrs/cattrs or Pydantic, or defining command line interfaces with function parameter declarations, like Appeal). Expecting type annotations to be more generally useful is mostly projected, baseless declaration anxiety: tools and methods that are useful in other languages are expected to be relevant in Python, certainly comforting for the type-addicted programmer but not necessarily useful. Declaring types is perceived as normal, as a necessary burden and dynamic typing is perceived as missing important structural elements. Consider the error pattern of accessing a value as if it had a different type: in C or C++ consequences are dire (possibly undetected and cascading memory corruption), likelihood is very high due to specific language features (pointers and references, raw arrays, casts, weak typing in general) and detailed type declarations are a useful mitigation because they turn run time catastrophes into actionable compile time reports, while in Python, thanks to robust duck typing without dangerous complications, consequences are mild (reasonable error messages or wrong results, before corrupting memory), likelihood is low (specific instances of unexpected and malformed data or gross API misunderstandings) and type declarations do nothing.
BiteCode_dev 2y ago
Have an optional one is nice for python. Would suck to be forced to use it all the time.
- echelon 2y ago
  As an undergrad, Python was my favorite language. Now it's one of my least favorite because of dynamic typing and the poor dependency management. Python dicts, when used as composite types or records, are a literal hellscape. Grepping through the code to find out where stringly-keyed fields get written takes way more time than thinking about types ever would. These should be structs. Static typing has so many advantages: - It lowers the software defect rate. All type errors are caught for free at compile time instead of runtime. This makes the software strong and rigid instead of brittle, and it removes an entire category of tests you would have to write and maintain. - Static typing makes code maintainable for other people, including future you. It's self-documenting. You know precisely what things are in the immediate scope. - Static typing makes bug-free automated refactoring with tools possible. There is no greater pleasure than mutating code via its AST. Static typing is not hard, either. Most typed languages don't require type declarations except in structs and function declarations - that's really not a lot of effort.
- vrighter 2y ago
  a type system is useless if you have no guarantees whether it will be used by any code you use. And if any code that declares types can violate them at will. Optional is equivalent to no type system at all, in my opinion.
  - nickm12 2y ago
    Just because a type system is optional doesn't mean it doesn't do anything, it just means that you can control how much checking you get, both in terms of the code that is typechecked and how strictly it is checked. Avoiding some type errors through type checking is much better than not having any type checking. Or put another way, optional seat belts are much better than not seat belts at all.
    - 2y ago
zo1 2y ago
Python's optional type-hinting is leaps and bounds better than a static typing system (on its own). It's fluid, allows expressibility whilst balancing guard-rails, and is making crazy cool use of "execute-time" or "import-time" time concepts (as an alternative to design-time and run-time). So no, we're not coming around. Static typing as dictated by a heavy-handed and super-strict compiler has it's place, but has gimped our industry for decades. However, we do have to be very careful. Static, compile-time typing has kept the hipsters and junior-devs at-bay, and kept them from causing too-much havoc as we've seen in the JS world. So it's definitely an up-coming hazard for us to navigate around and make sure we don't fall prey to. Otherwise python will turn into another JS dumpster fire. Luckily, the JS developers are too-distracted and enthralled with node.js to jump ship.
scott_w 2y ago
I don’t think that’s strictly true. Python developers are finding there are advantages to having a type system in larger programs such as readability and a reduction in certain classes of bugs. That said, I’ve found Python’s approach lets me still build things through experimentation then fixing the types when I’m a bit more confident that I’ve built the right thing. As a comparison, I found Go really clunky when I tried to learn it because it wouldn’t compile if the code wasn’t totally correct. It makes it hard to find the right solution through experimentation.
- sinfulprogeny 2y ago
  > then fixing the types man I wish my coworkers did this step
  - scott_w 2y ago
    Having CI hard fail definitely helps. I won’t pretend I’d be so judicious without it.
    - camjw 2y ago
      Sorry this is probably a stupid question - how do you make your CI hard fail if you don't have types? This sounds like the missing piece for me, someone who also prefers just to crack on without types and then add them later.
      - spacemanspiffii 2y ago
        You can add `mypy` to your CI pipeline https://mypy.readthedocs.io/en/stable/running_mypy.html https://mypy.readthedocs.io/en/stable/running_mypy.html. Pyright is an alternative, and there are more.
      - scott_w 2y ago
        I was referring more specifically to fixing the types. It looks like it's possible to enforce type-hinting with config files to mypy (but I've not tried it): https://stackoverflow.com/questions/55944201/python-type-hinting-how-do-i-enforce-that-project-wide https://stackoverflow.com/questions/55944201/python-type-hin...
jgb1984 2y ago
I've been writing python for a living for almost 20 years. Big projects. Never felt the need for static typing. And I strongly dislike the verbosity and complexity it adds to the language. Python is beautiful because it's simple, easy to read, easy to understand. The typing tagged on to it looks like an ugly word salad to me. I'll keep my dynamic typing, thanks!
- IshKebab 2y ago
  Have you ever tried static typing though? I suspect you don't know what you're missing. Static types make Python way easier to understand.
  - maleldil 2y ago
    Unfortunately, when many people hear of static typing they think of C++ and Java, which understandably leads to these kinds of conclusions. If they ever bothered writing typed Python for a little bit, especially in new packages or projects where the surrounding code is also typed, they might realise how useful it is. There's a world of difference between the experience you get with untyped Python and typed Python that you check with strict mypy or Pyright. After using typed Python for a while, I don't think I could go back to a completely untyped codebase.
  - diggan 2y ago
    > Have you ever tried static typing though? I suspect you don't know what you're missing. Static types make Python way easier to understand. I'd probably call myself within the "dynamic typing crowd" and I've tried plenty of static typing. It mostly just slows down iterating on something, prevents issues that I/my projects don't really suffer from in the first place, and gets in the way more than it helps. The statically typed languages I've tried are: C#, Crystal, Elm, Go, Haskell, Haxe, Java, Kotlin, Nim, Rust, TypeScript and probably more I'm forgetting about. Out of those, I've probably written most Rust code. I wouldn't say I despise static typing, but I'm not getting the same value from it that others seem to get. I still come back to Clojure, ClojureScript or just straight up vanilla JavaScript, as they're much more effective at actually helping me solve the problem I have in my practical day-to-day.
zephyrfalcon 2y ago
There is definitely a push for it; not all of us think it's an improvement. When I see modern Python code, it looks nothing like the (relatively) clean, smallish and easy-to-understand language that it was 25 years ago. I get it, things change. The language now caters to a different crowd and attracts different people. But I have often wondered, if someone wants static typing, why not just use a statically typed language?
- Philpax 2y ago
  I would and do, but a lot of existing code (especially ML code) is Python and I find myself having to interface with it. It's not an awful lot of fun, especially when there are no annotations to record what the code expects and what it outputs.
- vundercind 2y ago
  > But I have often wondered, if someone wants static typing, why not just use a statically typed language? A very high proportion of Python devs aren’t using it for the language, but for the libraries and ecosystem. Also lots of them weren’t the ones who picked it. Meanwhile, not at least having the kind of autocomplete and documentation that type hints provide is kinda hellish on any project of more than 200 or so lines. The time savings from spotting runtime bugs before they happen is just a bonus. Personally, I almost never need to add a type hint outside high-level definitions and function/method signatures, so they’re not really in the way even when I’m being pretty thorough with them.
deleted 2y ago
[deleted]
lyu07282 2y ago
or perhaps a bad typesystem is worse than no typesystem at all? I think typing in python is obviously getting better, it just feels something went wrong when they constantly have to fix design mistakes other languages never made to begin with. Typescript is fun, its powerful and strict, typing in python is ugly and frustrating. If this is the first time people are introduced to static typing in programming I can understand their frustrations and opposition to it. Its probably the worst type system in any modern, popular language out there, except perhaps when things like clojure(script) pretends to have types (shudder).
RHSeeger 2y ago
Having a type system provides benefits. Having a type system also comes with costs. The trick is whether (you believe) your specific use case gets enough out of those benefits to pay the costs.
- binary132 2y ago
  I can’t think of a time I have paid more for using a typesystem than I have been empowered by it. If you’re using types properly, it should be very empowering, and the cost not really perceptible. If anything, it reduces cost by moving things out of my brain and tests, into the typesystem.
  - RHSeeger 2y ago
    If you're using dynamic systems properly, it should be very empowering, and the lack of types is not really perceptible. If anything, it reduces the time code my moving things (having to consider types) out of my brain. I can just imagine what I want the code to do and type it, and most of the time it just kind of works out. Mind you, I prefer a type system. I'd prefer to use Typescript over Javascript, etc. But I've also used a number of dynamic languages that let me work a lot faster when needed; Tcl, Ruby, and Python are examples of these. I've also used some type systems that lift a heavier load, letting me pay more attention to the type definitions and know that it will "just work" at the end, because, mathematically, it works. Haskell falls into this category (though I rarely use it for anything other than fun). I get it, you haven't use a dynamic system in a way that it works out for you. But that doesn't mean they're wrong... just that others have different experiences.
lucasyvas 2y ago
Statically typed languages are in fact so much better nowadays that the industry should drop all dynamic / scripting languages for application development That will sadly probably never happen given the momentum they’ve built so the only choice is to retroactively add static typing and begin enforcing it in individual projects. When starting a new project, I would suggest nobody choose a dynamically typed language. Between Swift, Kotlin, C#, Go, Rust, etc… there’s no need for anything else. As long as front end web is around you might need TypeScript - and as long as ML is Python centric you might benefit from using a bit of it. But I wouldn’t make them the primary language. Context: Recovering dynamically typed language addict of 12 years. They’re slow, error prone, and don’t scale to a large engineering team.

btilly 2y ago

No. It's that when people who prefer type systems go to use a popular dynamic language, they try to drag in features that they like from other languages. Very honestly, optional type systems tend to be the worst of all worlds. Because people who don't care, don't need to use it, you don't get safety. But people who enjoy ceremony can inflict verbosity on others. While missing the most important reason to do it.

paulddraper 2y ago
Optional types are the best.* I can prototype, script, move fast. Then I can solidify, stabilize, collaborate. * To get top performance, of course you'll need compiler, types, static dispatch.
- binary132 2y ago
  I find that good types help me model the problem and solution with clarity, and the procedures and functions take a back seat. After all, most procedures are just transformations of structured data, so putting the datastructure first makes good sense and keeps the code clean and lean. I used to believe in the “moving fast with no types” thing but in practice I find myself modeling the problem either way, it’s just clumsier without strong types.
  - paulddraper 2y ago
    It depends how large the problem is.
  - josephg 2y ago
    Yep. And even when prototyping, I make a lot more dumb mistakes without a type checker watching my back. It’s amazing how quickly a few interfaces / typedefs repay the time you spent typing them in.
- btilly 2y ago
  Common Lisp was the first language I'm aware of with optional typing. In theory, what you're saying is true. In practice there's a lot of pressure to ship the working prototype, and retrofitting types on it later doesn't actually happen. The result was a reputation for being slow. (This was back when computers were slow enough that the overhead of being dynamic was pretty painful.)
  - paulddraper 2y ago
    Yep, hence the perf caveat.
binary132 2y ago
I’m not into the whole optional typing thing either. I would consider that far down the “worse typesystem” end of the spectrum I mentioned, only slightly better than “types are just arbitrary labels the language doesn’t even know about”, which is maybe even worse than lean dynamic typesystems, because you might make the mistake of believing in the shadows on the wall.
- jimmaswell 2y ago
  “types are just arbitrary labels the language doesn’t even know about” is ok if you're aware of the limitations. I add typedefs and other jsdocs to javascript just because it makes it easier to work with in an IDE. it's nice to hover over a variable and see what it's "supposed" to be (if all went well this object should have a .id, might have a .name, etc), sometimes even declared as two types like "this variable is either an int or a boolean". I don't really want to bother learning typescript or trying to get coworkers to do so/put it in the pipeline so it's the best I can do and it certainly makes life a bit easier.
  - pistoleer 2y ago
    > if all went well this object should Why not make it easier for yourself and be able to turn that into > The compiler will tell me when this object won't
    - jimmaswell 2y ago
      the JavaScript language standard is sadly out of my control, and I'm stuck with it.
gklitz 2y ago
> No. It's that when people who prefer type systems go to use a popular dynamic language, they try to drag in features that they like from other languages. Very much. The “problem” people try to solve with things like dependency injection isn’t even a problem in python. 99.99% of the time you can just import you dependencies everywhere they are needed. So many times now I’ve had to unteach bulky OOP patterns for people coming from strictly typed languages to python believe are “good practices” or are “needed for reliable code” and you go from 20 different interdependent classes down to 3 functions that just directly do what they are supposed to do. And you always end up with someone being disappointed that all of these complex patterns they learned to solve problems that don’t exist in python aren’t needed, rather than someone just happy that you can proceed directly to a value adding solution and skip the crud and design pattern spam. And then they start arguing crazy stuff like the 200 extra lines unneeded code makes the solution “more readable” or “more reliable”, when in reality it’s just a desire to use the solutions they are used to even when the problems don’t exist.
- indigo945 2y ago
  > The “problem” people try to > solve with things like > dependency injection isn’t > even a problem in python. > 99.99% of the time you can > just import you dependencies > everywhere they are needed. That's... Just not the problem DI fixes in any language? Sure, in C++ or Java you can just create a global static instance and use that everywhere. That's pretty much equivalent to just importing the same thing everywhere. But the downside of both approaches is testability: it becomes much harder to test units in isolation when they access global resources. Consider a function with `import datetime`, that gets the current time and does something with it. You want to make sure that this function still does the right thing in the extreme case of the current time being 23:59:59. How do you write this test without DI?
  - wizzwizz4 2y ago
    Easily. from datetime import datetime, timedelta def f(): now = datetime.now() future = now + timedelta(seconds=1) return now.time() < future.time() from unittest.mock import patch with patch('__main__.datetime', spec=datetime, side_effect=datetime) as mockdt: mockdt.now.return_value = datetime(2024, 10, 3, 23, 59, 59) assert f() If `datetime.datetime` were implemented in pure Python, one could even use `patch.object` here, saving a line.
HelloNurse 2y ago
Python type annotations are a good source of lightweight, easy to maintain metadata for many frameworks that provide valuable automatic handling of specific data types (for example defining deserialization and deserialization of nice class types with field declarations, like attrs/cattrs or Pydantic, or defining command line interfaces with function parameter declarations, like Appeal). Expecting type annotations to be more generally useful is mostly projected, baseless declaration anxiety: tools and methods that are useful in other languages are expected to be relevant in Python, certainly comforting for the type-addicted programmer but not necessarily useful. Declaring types is perceived as normal, as a necessary burden and dynamic typing is perceived as missing important structural elements. Consider the error pattern of accessing a value as if it had a different type: in C or C++ consequences are dire (possibly undetected and cascading memory corruption), likelihood is very high due to specific language features (pointers and references, raw arrays, casts, weak typing in general) and detailed type declarations are a useful mitigation because they turn run time catastrophes into actionable compile time reports, while in Python, thanks to robust duck typing without dangerous complications, consequences are mild (reasonable error messages or wrong results, before corrupting memory), likelihood is low (specific instances of unexpected and malformed data or gross API misunderstandings) and type declarations do nothing.

BiteCode_dev 2y ago

Have an optional one is nice for python. Would suck to be forced to use it all the time.

echelon 2y ago
As an undergrad, Python was my favorite language. Now it's one of my least favorite because of dynamic typing and the poor dependency management. Python dicts, when used as composite types or records, are a literal hellscape. Grepping through the code to find out where stringly-keyed fields get written takes way more time than thinking about types ever would. These should be structs. Static typing has so many advantages: - It lowers the software defect rate. All type errors are caught for free at compile time instead of runtime. This makes the software strong and rigid instead of brittle, and it removes an entire category of tests you would have to write and maintain. - Static typing makes code maintainable for other people, including future you. It's self-documenting. You know precisely what things are in the immediate scope. - Static typing makes bug-free automated refactoring with tools possible. There is no greater pleasure than mutating code via its AST. Static typing is not hard, either. Most typed languages don't require type declarations except in structs and function declarations - that's really not a lot of effort.
vrighter 2y ago
a type system is useless if you have no guarantees whether it will be used by any code you use. And if any code that declares types can violate them at will. Optional is equivalent to no type system at all, in my opinion.
- nickm12 2y ago
  Just because a type system is optional doesn't mean it doesn't do anything, it just means that you can control how much checking you get, both in terms of the code that is typechecked and how strictly it is checked. Avoiding some type errors through type checking is much better than not having any type checking. Or put another way, optional seat belts are much better than not seat belts at all.
  - 2y ago

zo1 2y ago

Python's optional type-hinting is leaps and bounds better than a static typing system (on its own). It's fluid, allows expressibility whilst balancing guard-rails, and is making crazy cool use of "execute-time" or "import-time" time concepts (as an alternative to design-time and run-time). So no, we're not coming around. Static typing as dictated by a heavy-handed and super-strict compiler has it's place, but has gimped our industry for decades. However, we do have to be very careful. Static, compile-time typing has kept the hipsters and junior-devs at-bay, and kept them from causing too-much havoc as we've seen in the JS world. So it's definitely an up-coming hazard for us to navigate around and make sure we don't fall prey to. Otherwise python will turn into another JS dumpster fire. Luckily, the JS developers are too-distracted and enthralled with node.js to jump ship.

scott_w 2y ago

I don’t think that’s strictly true. Python developers are finding there are advantages to having a type system in larger programs such as readability and a reduction in certain classes of bugs. That said, I’ve found Python’s approach lets me still build things through experimentation then fixing the types when I’m a bit more confident that I’ve built the right thing. As a comparison, I found Go really clunky when I tried to learn it because it wouldn’t compile if the code wasn’t totally correct. It makes it hard to find the right solution through experimentation.

sinfulprogeny 2y ago
> then fixing the types man I wish my coworkers did this step
- scott_w 2y ago
  Having CI hard fail definitely helps. I won’t pretend I’d be so judicious without it.
  - camjw 2y ago
    Sorry this is probably a stupid question - how do you make your CI hard fail if you don't have types? This sounds like the missing piece for me, someone who also prefers just to crack on without types and then add them later.
    - spacemanspiffii 2y ago
      You can add `mypy` to your CI pipeline https://mypy.readthedocs.io/en/stable/running_mypy.html https://mypy.readthedocs.io/en/stable/running_mypy.html. Pyright is an alternative, and there are more.
    - scott_w 2y ago
      I was referring more specifically to fixing the types. It looks like it's possible to enforce type-hinting with config files to mypy (but I've not tried it): https://stackoverflow.com/questions/55944201/python-type-hinting-how-do-i-enforce-that-project-wide https://stackoverflow.com/questions/55944201/python-type-hin...

jgb1984 2y ago

I've been writing python for a living for almost 20 years. Big projects. Never felt the need for static typing. And I strongly dislike the verbosity and complexity it adds to the language. Python is beautiful because it's simple, easy to read, easy to understand. The typing tagged on to it looks like an ugly word salad to me. I'll keep my dynamic typing, thanks!

IshKebab 2y ago
Have you ever tried static typing though? I suspect you don't know what you're missing. Static types make Python way easier to understand.
- maleldil 2y ago
  Unfortunately, when many people hear of static typing they think of C++ and Java, which understandably leads to these kinds of conclusions. If they ever bothered writing typed Python for a little bit, especially in new packages or projects where the surrounding code is also typed, they might realise how useful it is. There's a world of difference between the experience you get with untyped Python and typed Python that you check with strict mypy or Pyright. After using typed Python for a while, I don't think I could go back to a completely untyped codebase.
- diggan 2y ago
  > Have you ever tried static typing though? I suspect you don't know what you're missing. Static types make Python way easier to understand. I'd probably call myself within the "dynamic typing crowd" and I've tried plenty of static typing. It mostly just slows down iterating on something, prevents issues that I/my projects don't really suffer from in the first place, and gets in the way more than it helps. The statically typed languages I've tried are: C#, Crystal, Elm, Go, Haskell, Haxe, Java, Kotlin, Nim, Rust, TypeScript and probably more I'm forgetting about. Out of those, I've probably written most Rust code. I wouldn't say I despise static typing, but I'm not getting the same value from it that others seem to get. I still come back to Clojure, ClojureScript or just straight up vanilla JavaScript, as they're much more effective at actually helping me solve the problem I have in my practical day-to-day.

zephyrfalcon 2y ago

There is definitely a push for it; not all of us think it's an improvement. When I see modern Python code, it looks nothing like the (relatively) clean, smallish and easy-to-understand language that it was 25 years ago. I get it, things change. The language now caters to a different crowd and attracts different people. But I have often wondered, if someone wants static typing, why not just use a statically typed language?

Philpax 2y ago
I would and do, but a lot of existing code (especially ML code) is Python and I find myself having to interface with it. It's not an awful lot of fun, especially when there are no annotations to record what the code expects and what it outputs.
vundercind 2y ago
> But I have often wondered, if someone wants static typing, why not just use a statically typed language? A very high proportion of Python devs aren’t using it for the language, but for the libraries and ecosystem. Also lots of them weren’t the ones who picked it. Meanwhile, not at least having the kind of autocomplete and documentation that type hints provide is kinda hellish on any project of more than 200 or so lines. The time savings from spotting runtime bugs before they happen is just a bonus. Personally, I almost never need to add a type hint outside high-level definitions and function/method signatures, so they’re not really in the way even when I’m being pretty thorough with them.

deleted 2y ago

[deleted]

lyu07282 2y ago

or perhaps a bad typesystem is worse than no typesystem at all? I think typing in python is obviously getting better, it just feels something went wrong when they constantly have to fix design mistakes other languages never made to begin with. Typescript is fun, its powerful and strict, typing in python is ugly and frustrating. If this is the first time people are introduced to static typing in programming I can understand their frustrations and opposition to it. Its probably the worst type system in any modern, popular language out there, except perhaps when things like clojure(script) pretends to have types (shudder).

RHSeeger 2y ago

Having a type system provides benefits. Having a type system also comes with costs. The trick is whether (you believe) your specific use case gets enough out of those benefits to pay the costs.

binary132 2y ago
I can’t think of a time I have paid more for using a typesystem than I have been empowered by it. If you’re using types properly, it should be very empowering, and the cost not really perceptible. If anything, it reduces cost by moving things out of my brain and tests, into the typesystem.
- RHSeeger 2y ago
  If you're using dynamic systems properly, it should be very empowering, and the lack of types is not really perceptible. If anything, it reduces the time code my moving things (having to consider types) out of my brain. I can just imagine what I want the code to do and type it, and most of the time it just kind of works out. Mind you, I prefer a type system. I'd prefer to use Typescript over Javascript, etc. But I've also used a number of dynamic languages that let me work a lot faster when needed; Tcl, Ruby, and Python are examples of these. I've also used some type systems that lift a heavier load, letting me pay more attention to the type definitions and know that it will "just work" at the end, because, mathematically, it works. Haskell falls into this category (though I rarely use it for anything other than fun). I get it, you haven't use a dynamic system in a way that it works out for you. But that doesn't mean they're wrong... just that others have different experiences.

lucasyvas 2y ago

Statically typed languages are in fact so much better nowadays that the industry should drop all dynamic / scripting languages for application development That will sadly probably never happen given the momentum they’ve built so the only choice is to retroactively add static typing and begin enforcing it in individual projects. When starting a new project, I would suggest nobody choose a dynamically typed language. Between Swift, Kotlin, C#, Go, Rust, etc… there’s no need for anything else. As long as front end web is around you might need TypeScript - and as long as ML is Python centric you might benefit from using a bit of it. But I wouldn’t make them the primary language. Context: Recovering dynamically typed language addict of 12 years. They’re slow, error prone, and don’t scale to a large engineering team.