I'm a fan of this multi-language trend of gradual and optional typing. Static typing has definite benefits, but there are also diminishing returns on productivity as a language becomes more and more statically safe. Often times, type safety is a rabbit hole that can easily turn a language into what some call a "puzzle language," where the efforts to please the compiler become non-intuitive and take long times to figure out. Some of the classes in Swift for example have to adopt a hundred protocols just to compile. Rust is an even more extreme example. You might get extra safety, but at significant development cost.
Gradual typing in Python is a happy medium that lets the developer decide (to some degree) on the workflow up front. It's a nice compromise for a wide range of work.
> Rust is an even more extreme example. You might get extra safety, but at significant development cost.
This is not the indisputable fact that you seem to be portraying this as. I've written similar amounts of Rust and Python, and it is much much easier and faster for me to write robust software in Rust than in Python. Python might let me get to a prototype more quickly in some cases, but the amount of time spent on maintenance after the fact puts Rust very clearly in the lead in my experience.
There's no doubt that Rust's learning curve is much much steeper than Python's, but this is a very different thing that saying something general about overall development cost.
Do you not find that lack of a REPL-oriented workflow inhibits productivity? I sure do. I love C++ and don't use Rust beyond hobby interest, but being able to do things interactively is definitely an advantage in languages like Python.
The nice thing about gradual typing is if you get to a proof-of-concept, you can then layer in types for static analyzers to make it more robust. Sure it's not Rust-level safety, but it works for very demanding projects. Heck, all of Instagram is built on Python, and they use the static type analysis in their workflow just like this.
It's just a compromise everyone needs to find on their own or for a specific project.
You're kind of missing my point. I'm specifically not talking about gradual typing. I'm calling your claims about development cost into question.
I'm personally not a huge fan of gradual typing. I've tried it, and it didn't work well for both technical and social reasons. But I'm not here to argue that point.
>Rust is an even more extreme example. You might get extra safety, but at significant development cost.
I don't buy this argument. If you want your program to do what you intend you have to know the types anyway. I've never spent significant time on finding the right type, even in Rust.
I have spent significant time on incorrect code, because of functions that accepted inputs with the wrong type and didn't complain, because the wrong type had the same method.
I have spent significant time on looking up what a function can do, because the IDE can't figure out what my parameter is.
I have spent significant time on programs that ran into runtime problems every once in a blue moon that would have been easily detected by a good type system at compile time.
Articles like this just show me that every language that needs to have maintainability for large projects will turn into strongly, statically typed at some point. Whether it's type hints or TypeScript.
But static typing != static typing. There are many different degrees of type safety, some much more strict than others. It is often about more than just "finding the right type," as you say. How much does the compiler require features of a type to be implemented, even if they are not used, in order for it to be a certain type, or just use one featureset of a protocol/trait that it adopts? You can easily write types that eventually require a large amount of boilerplate in some languages to just do something fairly basic that is not as complex as what the compiler asks you to do.
The problem with Python is the default is untyped. I want gradual static typing for the code I write but that should be on top of a base of already well typed libraries. It's one reason I like Groovy - it's a language that lets you optionally and incrementally type
your code, but it sits within an ecosystem of mostly statically typed languages so you aren't fighting a massive legacy of culture and code that just doesn't care about declaring types.
Although Apache Groovy sits within an ecosystem of statically typed languages, Groovy itself has a long history of dynamic typing only. Its static typing was only introduced in version 2, and even then people don't use it very much -- Groovy's primary use is as a DSL specifying Gradle build scripts. Legacy Groovy code is typically littered with `def` and `{a, b-> ...}` everywhere.
Absolutely, most groovy code is written in the dynamic style. But it's still way better off than Python where that is true AND its true for all the libraries it uses. With Python you can add as many type hints as you want, you are still going to get stuck at the first call that reaches outside your own code where nobody cared about types. With Groovy that call is going into Java or typed GDK code 95% of the time (unless you are talking about Grails which I'm not a big fan of for that reason), and hence you have the benefit of 95% of code already being typed by default.
I think you're vastly underestimating what makes a script language "scripty" - not having to declare types is only one factor and probably not the most important.
Type annotations more completely describe a program. This can be useful if your code-base's requirements are subject to rapid change (e.g. websites). But when your program is something which has been well thought-out from the start, and thus whose requirements don't change during the course of development, I trust a program which has been statically-typed to not develop bugs over time. case in point: /usr/bin/git
Gradual typing in Python is a happy medium that lets the developer decide (to some degree) on the workflow up front. It's a nice compromise for a wide range of work.
I love this explanation from a few months ago:
https://blog.merovius.de/2017/09/12/diminishing-returns-of-s...