4 ms·

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.
  - vrighter 2y ago
    except in the real world, seat belts are mandatory. Because not wearing them is always a net negative. giving me some confidence is completely useless on a large scale, especially because the type system could literally be lying even when it does give me something when it is optional and unenforced (an external linter does not count as enforcement, because it is not exhaustive). I still have to write tests for everything to check types, or run some external type checker which is guaranteed to not be able to catch all errors because the language semantics don't even allow for it. giving me full confidence is not. In typed languages, if the compiler (not some external tool) says there are no type errors, then there are no type errors. I'm not "reasonably confident". I'm sure.
- binary132 2y ago
  Most people using strong typesystems care less about safety of imported code and more about usability of their own codebase.
  - vrighter 2y ago
    i also care about usability of the dependencies for myself, the dev. If the dependency doesn't provide type information, I can miss bugs in my own code.
khafra 2y ago
I guess you could just write the program in Python, then have ChatGPT automatically translate it into a strongly-typed language.
- yen223 2y ago
  What is ChatGPT written in? Because it would be hilarious if ChatGPT was itself written in Python.
  - josephg 2y ago
    I have no inside knowledge. But given the performance and scale chatgpt runs at (and the caliber of the team), I think it’s safe to assume a lot of their production code is written in C++ / cuda.
    - binary132 2y ago
      Python is really popular for both training and inference, and in both cases it uses native-compiled libs under the hood to ameliorate performance problems. I mean, maybe they’re chasing the last few % now, but it looks to me like most of their R&D is focused on their models and their interactive capabilities.
- maleldil 2y ago
  That misses the primary reasons many people use Python: the ecosystem and network effects. I would not use Python if it weren't the only language my colleagues know (many of them not computer scientists by training) and if it didn't have the best (or second/third best) libraries for almost everything.
globular-toast 2y ago
Yes. I like to use type annotations on functions because it's documentation. If you use good names then it makes docstrings redundant. I'm thinking something like this: def bounding_box(points: list[Point]) -> Box: ... A decent IDE will be able to quickly jump to definition of those Box and Point etc. if you need it. This is much better than having a docstring and having to look stuff up manually. The fact you can run a static type checker like mypy is a bonus! I also really like being able to document the imperative code like `def do_thing() -> None`. Of course, it's completely up to the programmer to follow the rule of not doing side effects in routines that return something. But having to do it everywhere? Ugh. I don't think people realise how powerful duck typing is for doing polymorphic code. I can write something like: def mean(things): return sum(things)/len(things) And I don't care what concrete type you pass me as long as it supports `sum` and `len`. What am I going to do, define an ABC or typing.Protocol called `ListLike` or something? Hell no, I've got better things to do. But of course learning when to define static types vs when not to comes down to experience. Python treats you like an adult. I feel like a lot of people who want static typing everywhere want it as training wheels for other devs they don't trust to make the right judgement calls.
- maleldil 2y ago
  You picked a poor example for `mean` because there's a very easy answer: collections.abc.Sequence – typing.Sequence in earlier versions – an object that supports __getitem__ and __len__. You can check the collections.abc documentation[1] for the available protocols; you might be surprised about how much they cover already. I often use Sequence/Iterable or Mapping as parameter types instead of concrete types like list or dict. > I feel like a lot of people who want static typing everywhere want it as training wheels for other devs they don't trust to make the right judgement calls. Now, I want it because it makes my life a lot easier. It finds many classes of errors before runtime and improves auto-completion in my editor. For most programs, it's not a lot of effort. The frustrating part is interfacing with untyped libraries while using strict type-checking, but thankfully, more and more libraries are adopting typing. The type system itself is fine: most things you want to express are doable, but it's not at the same level of complexity as Typescript. It's certainly a better type system than Go's for example. [1] https://docs.python.org/3/library/collections.abc.html https://docs.python.org/3/library/collections.abc.html

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.
- vrighter 2y ago
  except in the real world, seat belts are mandatory. Because not wearing them is always a net negative. giving me some confidence is completely useless on a large scale, especially because the type system could literally be lying even when it does give me something when it is optional and unenforced (an external linter does not count as enforcement, because it is not exhaustive). I still have to write tests for everything to check types, or run some external type checker which is guaranteed to not be able to catch all errors because the language semantics don't even allow for it. giving me full confidence is not. In typed languages, if the compiler (not some external tool) says there are no type errors, then there are no type errors. I'm not "reasonably confident". I'm sure.
binary132 2y ago
Most people using strong typesystems care less about safety of imported code and more about usability of their own codebase.
- vrighter 2y ago
  i also care about usability of the dependencies for myself, the dev. If the dependency doesn't provide type information, I can miss bugs in my own code.

khafra 2y ago

I guess you could just write the program in Python, then have ChatGPT automatically translate it into a strongly-typed language.

yen223 2y ago
What is ChatGPT written in? Because it would be hilarious if ChatGPT was itself written in Python.
- josephg 2y ago
  I have no inside knowledge. But given the performance and scale chatgpt runs at (and the caliber of the team), I think it’s safe to assume a lot of their production code is written in C++ / cuda.
  - binary132 2y ago
    Python is really popular for both training and inference, and in both cases it uses native-compiled libs under the hood to ameliorate performance problems. I mean, maybe they’re chasing the last few % now, but it looks to me like most of their R&D is focused on their models and their interactive capabilities.
maleldil 2y ago
That misses the primary reasons many people use Python: the ecosystem and network effects. I would not use Python if it weren't the only language my colleagues know (many of them not computer scientists by training) and if it didn't have the best (or second/third best) libraries for almost everything.

globular-toast 2y ago

Yes. I like to use type annotations on functions because it's documentation. If you use good names then it makes docstrings redundant. I'm thinking something like this: def bounding_box(points: list[Point]) -> Box: ... A decent IDE will be able to quickly jump to definition of those Box and Point etc. if you need it. This is much better than having a docstring and having to look stuff up manually. The fact you can run a static type checker like mypy is a bonus! I also really like being able to document the imperative code like `def do_thing() -> None`. Of course, it's completely up to the programmer to follow the rule of not doing side effects in routines that return something. But having to do it everywhere? Ugh. I don't think people realise how powerful duck typing is for doing polymorphic code. I can write something like: def mean(things): return sum(things)/len(things) And I don't care what concrete type you pass me as long as it supports `sum` and `len`. What am I going to do, define an ABC or typing.Protocol called `ListLike` or something? Hell no, I've got better things to do. But of course learning when to define static types vs when not to comes down to experience. Python treats you like an adult. I feel like a lot of people who want static typing everywhere want it as training wheels for other devs they don't trust to make the right judgement calls.

maleldil 2y ago
You picked a poor example for `mean` because there's a very easy answer: collections.abc.Sequence – typing.Sequence in earlier versions – an object that supports __getitem__ and __len__. You can check the collections.abc documentation[1] for the available protocols; you might be surprised about how much they cover already. I often use Sequence/Iterable or Mapping as parameter types instead of concrete types like list or dict. > I feel like a lot of people who want static typing everywhere want it as training wheels for other devs they don't trust to make the right judgement calls. Now, I want it because it makes my life a lot easier. It finds many classes of errors before runtime and improves auto-completion in my editor. For most programs, it's not a lot of effort. The frustrating part is interfacing with untyped libraries while using strict type-checking, but thankfully, more and more libraries are adopting typing. The type system itself is fine: most things you want to express are doable, but it's not at the same level of complexity as Typescript. It's certainly a better type system than Go's for example. [1] https://docs.python.org/3/library/collections.abc.html https://docs.python.org/3/library/collections.abc.html