Haha: “A space breaks everything.” Fuck YES! Are you kidding me‽ It’s one of the best features!
Why? Because it’s so easy to see. In other languages you’ve got semicolons which are surprisingly difficult to notice when they’re missing. Depending on the situation (or if you’re just new to programming) you could spend a great deal of time troubleshooting your code only to find out that you’re missing a semicolon. It’s frustrating and it makes you feel stupid which is never a good thing for people who are new programming.
Types are in a different category altogether with seemingly infinite reasons why you’d want a feature-rich, low-level type system and also why you’d want to avoid that.
IMHO, the point of Python is to be a simple language that’s quick to write yet also very powerful and speedy when you need it to be (by taking advantage of modules written in C or better, Rust). If it had a complex type system I think it would significantly lower the value of the language. Just like how when I see an entire code repo using Pydantic and type hints everywhere it makes the code unnecessarily complex (just use type hints where it matters 🙄).
I’m not saying using type hints on everything is a terrible thing… I just think it makes the code harder to read which, IMHO defeats the point of using Python and adds a TON of complexity to the language.
The promise of type hints is that they’ll enable the interpreter to significantly speed up certain things and reduce memory utilization by orders of magnitude at some point in the future. When that happens I’ll definitely be reevaluating the situation but right now there doesn’t seem to be much point.
For reference, I’ve been coding in Python for about 18 years now and I’ve only ever encountered a bug (in production) that would’ve been prevented by type hints once. It was a long time ago, before I knew better and didn’t write unit tests.
These days when I’m working on code that requires type hints (by policy; not actual necessity) it feels like doing situps. Like, do I really need to add a string type hint to a function called, parse_log()? LOL!
I don’t mean this insultingly because lots of programming jobs don’t require this and for the ones that do we still tend to all start here, but in all honesty this sounds like it’s coming from someone who’s never worked on a large project maintained by multiple people over time.
First of all, the hysteria over semicolons is ridiculous when JavaScript, Typescript, C#, Java, Go, Swift, etc. etc. wil all automatically highlight missing semicolons, if not automatically insert them for you when paired with an IDE and standard linter. On top of that, JavaScript and Typescript do not require semicolons at all, but they are still used alongside braces, because they make your code more scannable, readable, and moveable.
Secondly, without type safety your code is no longer predictable or maintainable. If you’re working to quickly sketch out some new fangled logic for a research paper it’s one thing, if you need to write test code so that your codebase can be tested an infinite number of times by other coders and whatever CI/ CD pipelines to make sure that nothing’s broken, then all of the sudden you start seeing the value in strict typing.
Honestly, complaining about type safety adding “extra code” is a complaint that almost every coder has when they start out, before you eventually realize that all that “extra code” isn’t just boiler plate for no reason but is adding specificity, predictability, reusability, and maintainability to your code base.
When defining types looked like this it was one thing:
String name = newString("Charles Xavier");
But when it looks like this, there’s no reason not to use strong typing:
I started out with Visual Basic using the Variant type all the time, and even though I was usually just working on one-person projects it was a fucking disaster. You don’t even have to collaborate to see the virtues of strong typing.
Right, so this is the part where I get to sound like a smart ass, because I snuck a “tons of” into there.
What you do always need, is tests serving as a specification of the intended behavior, to document it for your team members and your future self.
But the thing that static typing is an alternative to, is integration tests for many code paths. For example, in dynamic languages you have no reassurance that a call to your database library still works, unless you have an integration test which actually calls into the database. Similarly, you hardly know whether the many error-handling code paths are working, unless you write tests for those, too.
In static languages, we don’t test this stuff outside of the specification-like integration tests, because the database library and the error handling library are already separately tested, and the type system ensures that we interface with them correctly.
without type safety your code is no longer predictable or maintainable
This sounds like someone who’s never worked on a large Python project with multiple developers. I’ve been doing this for almost two decades and we never encounter bugs because of mismatched types.
For reference, the most common bugs we encounter are related to exception handling. Either the code captured the exception and didn’t do the right thing (whatever that is) in specific situations or it didn’t capture the exception in the right place so it bubbles up waaaaay too high up the chain and we end up with super annoying troubleshooting where it’s difficult to reproduce or difficult to track down.
This sounds like someone who’s never worked on a large Python project with multiple developers. I’ve been doing this for almost two decades and we never encounter bugs because of mismatched types.
Have you worked on major projects in other languages in that time period to be able to compare and contrast?
The last two python projects I had to work on didn’t have bugs because of type issues, but it was much harder to come into the codebase and understand what was going on given that you didn’t have type information in many many places which forced you to go back and comb through the code instead.
because semicolons are tiny characters that oftenhave to be appended to the end of lines (precisely the worst place for them to be easily visible, since they’ll blend in with the previous character)
whitespace meanwhile is very easy to notice that it’s missing, as i’m sure you noticed when reading the above sentence.
It’s kinda funny that Godot’s custom language GDScript is, at least on a surface level, pythonic (no list comprehensions, context managers, decorators, etc, it’s mostly syntactical similarities). But type hints do make it run faster!
I was blessed to get to skip most of the old pains in python. I only had a handful of scripts that ever needed to be ported from 2 and they didn’t rely on any libraries. The ecosystem is easy to work with and I’m looking forward to working with Python for the foreseeable future
Haha: “A space breaks everything.” Fuck YES! Are you kidding me‽ It’s one of the best features!
Why? Because it’s so easy to see. In other languages you’ve got semicolons which are surprisingly difficult to notice when they’re missing. Depending on the situation (or if you’re just new to programming) you could spend a great deal of time troubleshooting your code only to find out that you’re missing a semicolon. It’s frustrating and it makes you feel stupid which is never a good thing for people who are new programming.
Types are in a different category altogether with seemingly infinite reasons why you’d want a feature-rich, low-level type system and also why you’d want to avoid that.
IMHO, the point of Python is to be a simple language that’s quick to write yet also very powerful and speedy when you need it to be (by taking advantage of modules written in C or better, Rust). If it had a complex type system I think it would significantly lower the value of the language. Just like how when I see an entire code repo using Pydantic and type hints everywhere it makes the code unnecessarily complex (just use type hints where it matters 🙄).
I’m not saying using type hints on everything is a terrible thing… I just think it makes the code harder to read which, IMHO defeats the point of using Python and adds a TON of complexity to the language.
The promise of type hints is that they’ll enable the interpreter to significantly speed up certain things and reduce memory utilization by orders of magnitude at some point in the future. When that happens I’ll definitely be reevaluating the situation but right now there doesn’t seem to be much point.
For reference, I’ve been coding in Python for about 18 years now and I’ve only ever encountered a bug (in production) that would’ve been prevented by type hints once. It was a long time ago, before I knew better and didn’t write unit tests.
These days when I’m working on code that requires type hints (by policy; not actual necessity) it feels like doing situps. Like, do I really need to add a string type hint to a function called,
parse_log()? LOL!I don’t mean this insultingly because lots of programming jobs don’t require this and for the ones that do we still tend to all start here, but in all honesty this sounds like it’s coming from someone who’s never worked on a large project maintained by multiple people over time.
First of all, the hysteria over semicolons is ridiculous when JavaScript, Typescript, C#, Java, Go, Swift, etc. etc. wil all automatically highlight missing semicolons, if not automatically insert them for you when paired with an IDE and standard linter. On top of that, JavaScript and Typescript do not require semicolons at all, but they are still used alongside braces, because they make your code more scannable, readable, and moveable.
Secondly, without type safety your code is no longer predictable or maintainable. If you’re working to quickly sketch out some new fangled logic for a research paper it’s one thing, if you need to write test code so that your codebase can be tested an infinite number of times by other coders and whatever CI/ CD pipelines to make sure that nothing’s broken, then all of the sudden you start seeing the value in strict typing.
Honestly, complaining about type safety adding “extra code” is a complaint that almost every coder has when they start out, before you eventually realize that all that “extra code” isn’t just boiler plate for no reason but is adding specificity, predictability, reusability, and maintainability to your code base.
When defining types looked like this it was one thing:
String name = new String("Charles Xavier");But when it looks like this, there’s no reason not to use strong typing:
const name = "Charles Xavier";Anyone who thinks a strong type system is a drawback has never worked on any real project where you actually have to collaborate with others.
I started out with Visual Basic using the Variant type all the time, and even though I was usually just working on one-person projects it was a fucking disaster. You don’t even have to collaborate to see the virtues of strong typing.
Yeah, the alternative to static typing is to write tons of unit tests, which definitely adds a lot more code to your codebase.
That’s not an alternative, you always need tests
Right, so this is the part where I get to sound like a smart ass, because I snuck a “tons of” into there.
What you do always need, is tests serving as a specification of the intended behavior, to document it for your team members and your future self.
But the thing that static typing is an alternative to, is integration tests for many code paths. For example, in dynamic languages you have no reassurance that a call to your database library still works, unless you have an integration test which actually calls into the database. Similarly, you hardly know whether the many error-handling code paths are working, unless you write tests for those, too.
In static languages, we don’t test this stuff outside of the specification-like integration tests, because the database library and the error handling library are already separately tested, and the type system ensures that we interface with them correctly.
This sounds like someone who’s never worked on a large Python project with multiple developers. I’ve been doing this for almost two decades and we never encounter bugs because of mismatched types.
For reference, the most common bugs we encounter are related to exception handling. Either the code captured the exception and didn’t do the right thing (whatever that is) in specific situations or it didn’t capture the exception in the right place so it bubbles up waaaaay too high up the chain and we end up with super annoying troubleshooting where it’s difficult to reproduce or difficult to track down.
Also, testing is completely orthogonal to types.
Have you worked on major projects in other languages in that time period to be able to compare and contrast?
The last two python projects I had to work on didn’t have bugs because of type issues, but it was much harder to come into the codebase and understand what was going on given that you didn’t have type information in many many places which forced you to go back and comb through the code instead.
So the code did have type hints, just not consistently. Sounds like bad code.
What are you writing your code in? Windows notepad? How the hell do you not see the semicolon missing?
because semicolons are tiny characters that oftenhave to be appended to the end of lines (precisely the worst place for them to be easily visible, since they’ll blend in with the previous character)
whitespace meanwhile is very easy to notice that it’s missing, as i’m sure you noticed when reading the above sentence.
In both cases, you press compile and the compiler goes “you missed a whitespace/semicolon HERE”
Exactly! I’ve wasted more time hunting missing semicolons in languages that use them, than fixing wrong indentation in Python.
It’s kinda funny that Godot’s custom language GDScript is, at least on a surface level, pythonic (no list comprehensions, context managers, decorators, etc, it’s mostly syntactical similarities). But type hints do make it run faster!
I was blessed to get to skip most of the old pains in python. I only had a handful of scripts that ever needed to be ported from 2 and they didn’t rely on any libraries. The ecosystem is easy to work with and I’m looking forward to working with Python for the foreseeable future