Of all Armin's articles to date, this one I agree the most with. > Python is a language that suffers from not having a language specification ... There are so many quirks and odd little behaviors that the only thing a language specification would ever produce, is a textual description of the CPython interpreter... Keeping a language lean and well defined seems to be very much worth the troubles. Future language desig…
I think Python had one chance to do what you suggest - remove bizarre behaviors. This chance was Python 3.
This is also one of the things that bothers me a bit about Rust. The complexity of the compiler means that writing an actual language spec is hard, and the spec is very much tied to "what rustc's borrow checker is capable of".
>If you feel like the type system fights against you, chances are that you are doing something wrong. Like most things, I think this depends on context. Doing exploratory data analysis in a static, strongly-typed language, for example, is extremely painful. And writing quick, one-time scripts in such languages is usually more trouble than it's worth. For this reason, Python is a wonderful language for doing data anal…
"But for building a robust application that will have to be maintained a long-time, you have to religiously write tests in these languages or you'll be buried in bugs. And even then, you still may be buried in bugs that a static, strongly-typed language would have detected." People make this sort of claim all the time, but my personal experience has not borne it out, and I have seen no data to backup this claim which…
If you value time spent writing code higher than preventing bugs, I have doubts about the size of codebases you were maintaining. The reality I have experienced is that working with a large codebase in Python (talking 100kloc+ here, and teams larger than 3) is an absolute nightmare. Lack of explicit typing on argument values and returns means that everytime you add an argument to a function, or move things around, you are frantically grepping trying to find all the callers and hoping that you caught all of them. Add in the more functional aspects such as passing functions around and lambdas and *args and kwargs and different return types depending on function behavior and it gets very ugly. Given the fact that adding functionality and refactoring are the most common activities when working with a large existing codebase, this becomes very old, very quickly. I suspect that Guido's newfound interest in explicit typing coincides with his employment at Dropbox and Google and realizing the very real pain that comes with maintaining large Python codebases.
Of all Armin's articles to date, this one I agree the most with. > Python is a language that suffers from not having a language specification ... There are so many quirks and odd little behaviors that the only thing a language specification would ever produce, is a textual description of the CPython interpreter... Keeping a language lean and well defined seems to be very much worth the troubles. Future language desig…
Python 3 should have been a from the ground rewrite of a new core runtime written to a language specification. Maybe we can get that in Python 4.
>So what's the solution? Not having null references and having explicitly typed arrays. Throwing the baby out with the bath water. Null types are extremely useful. I don't get why the author claims the null type in C# is a form of "damage". It's just said that it's bad, not why. The problem with None in python was that you can't tell what it's supposed to be. In C# you know what type the null is meant to be.
If you have ever programmed in a language with strict enforcement of something like a "maybe" or "option" type then you'll see that it's fairly trivial to have a separate type for a nullable pointer and a non-nullable pointer.
It is essentially brain-dead that the type Foo really means "Either a Foo, or null" Failure to properly check for null is a source of many, many bugs, and there is an almost trivial way (assuming you're creating a new language, like C# was) to completely prevent it in statically typed languages that was well known when C# was invented.
Armin didn't address what I belive is the main point of adding type annotations to Python: compiler checkable documentation and as hints to IDE:s. Seen in that perspective, a sucky type system is good enough because it's use isn't to verify program correctness. Personally, I think a standardized format for describing types in docstrings would be 100x better but that's not the way the Python core devs have choosen. An…
I think Armin didn't address these valid points, because as he points out, "The first one is that I barely understand them[type systems] at all myself."
Seems odd for someone who doesn't understand type systems to be writing a high profile blog post about why they don't belong in Python, no?
"But for building a robust application that will have to be maintained a long-time, you have to religiously write tests in these languages or you'll be buried in bugs. And even then, you still may be buried in bugs that a static, strongly-typed language would have detected." People make this sort of claim all the time, but my personal experience has not borne it out, and I have seen no data to backup this claim which…
If you value time spent writing code higher than preventing bugs, I have doubts about the size of codebases you were maintaining. The reality I have experienced is that working with a large codebase in Python (talking 100kloc+ here, and teams larger than 3) is an absolute nightmare. Lack of explicit typing on argument values and returns means that everytime you add an argument to a function, or move things around, yo…
I've been writing software for a long time at some of the largest companies in the world. My experience does not match yours.
Some people may not understand the context of this part: So not long ago someone apparently convinced someone else at a conference that static typing is awesome and should be a language feature. I'm not exactly sure how that discussion went but the end result was that mypy's type module in combination with Python 3's annotation syntax were declared to be the gold standard of typing in Python. Ronacher is referring to…
The thing that function annotation syntax is good for is the ability to catch errors before they hit your production server at 2AM on a Tuesday. If you can describe the types that a function accepts and returns, violations of those rules can be caught by static analysis such as pylint and let you know before you commit. The current approach in Python after refactoring a large chunk of code is to grep through all the existing callers, fix what you can find, run the tests and hope for the best.
Of all Armin's articles to date, this one I agree the most with. > Python is a language that suffers from not having a language specification ... There are so many quirks and odd little behaviors that the only thing a language specification would ever produce, is a textual description of the CPython interpreter... Keeping a language lean and well defined seems to be very much worth the troubles. Future language desig…
Python 3 should have been a from the ground rewrite of a new core runtime written to a language specification. Maybe we can get that in Python 4.
Who's going to work on that, and most importantly bless it as official and unite people? I haven't seen anything from Guido on the criticisms of Python 3 and CPython, like this post and other unicode complexity complaints in Python 3. It seems that a lot of people who like Python because it lets them move fast hit a wall when they encounter main Python developers as moving so slow as to consider it okey to have two major versions of a language competing until 2020.
I'm not sure why, but your examples aren't working with me... 1 *| meter |+| 35 *| centi meter 1.35 m works, but 1 meter fails with :42:1: No instance for (Num (Value LengthDimension (U Meter) f0 -> t0)) arising from the literal `1' Possible fix: add an instance declaration for (Num (Value LengthDimension (U Meter) f0 -> t0)) In the expression: 1 In the expression: 1 meter In an equation for `it': it = 1 meter :42:3:…
Try running "import UnitTyped.NoPrelude" first. EDIT: you may also want to start ghci with the "-XNoImplicitPrelude" flag, or explicitly disambiguate operations such as "*" with "UnitTyped.NoPrelude.*" or "Prelude.*"
Thanks, but that's not enough. The error seems due to the fact that `meter` is passed as an argument to `1` which is not a function, and indeed I don't see how that could be valid haskell code (unless there's some language flag I should enable, but unfortunately the wiki/docs of unittyped doesn't seem to be comprehensive enough)