Programming languages shouldn't have two competing two type systems in them. Static typing in a scripting language like Ruby is just poor engineering.
Absolute anything else would be better than it.
Static typing in Python is a complete disaster when it's used on real commerical projects. I've seen the code thank you very much.
Do you mean "the worst"? There are plenty languages that are worse, and that are still in use. It's not great, but it's also not as terrible as you're making it seem.
> Absolute anything else would be better than it.
Okay, what does that have to do with static typing? Or are you saying that Typescript is better than Javascript? If static typing can make such "the worse" language better, why can't it improve other languages as well?
> Static typing in Python is a complete disaster when it's used on real commerical projects. I've seen the code thank you very much.
You make it seem like the alternative, not having static typing, is in any way better. No, it's definitely not - having e.g. your IDE know the types of values to help you in refactoring is extremely valuable, as is having static type checkers tell you about issues before running your code.
You either have unknown type problems because you're missing test cases, or you're re-building a static type system in your test suites. There is no way around verifying your assumptions about types if you want to build stable software.
"help you in refactoring" It's a terrible way to refactor your code.
There are far better and far superior software development practices out there, which do everything static typing does and more.
"There is no way around verifying your assumptions about types" Yes, there are. There are many many ways to do this that do a lot better job than static typing. Static typing is known to be terrible at eliminating bugs from code.
The complain here is not that static typing isn't better than nothing but that static typing is such a low tier solution, that if you were doing anything proper you wouldn't be touching it.
Can you give some examples for these supposedly superior techniques?
> "help you in refactoring" It's a terrible way to refactor your code.
Could you explain why you think so? Say I'm changing the name of an attribute. Why is using static typing to find the places I have to change terrible?
> "There is no way around verifying your assumptions about types" Yes, there are. There are many many ways to do this that do a lot better job than static typing. Static typing is known to be terrible at eliminating bugs from code.
I didn't say what you think I said, since I didn't touch on static typing in this. Want to try responding to my actual argument?
In typescript, when I do a refactor, or I add a feature, I will code for hours, relying solely on the typechecker for feedback, and then I will manually test, and then write unit tests. (It helps that I use discriminated unions with exhaustiveness-checks, and avoid shortcuts like `any`, to the extent possible).
Such a workflow is impossible with how limited sorbet is in the RoR context.
I'd still choose an RoR codebase with sorbet than without it any day of the week tho.
The major piece of the puzzle missing is generics support, but other type handling is already there.
I agree, but in that case, using a scripting language to build and maintain applications with significant LOC ... is poor engineering.
Static typing is there so you can get compile-time support for validating assumptions made throughout your source code, which is critical for developing and maintaining LARGE applications by teams of engineers of all skill-sets, over significant periods of time.
And that is very poor software engineering. You should be breaking down those large applications into smaller more maintainable micro-services.
It's bad really bad.
"compile-time support for validating assumptions"
Bad software development again. If you are checking assumptions at compile time then you are slowing down your software development iteration loop. It's the 4 hour compile time problem from C++ revisited.
"over significant periods of time"
Bad, really bad software development again. As business requirements change over the life-time of a software project, you need to retire and replace old code with new code that better meets the changing business needs.
Static typing is useful for performance reasons but that doesn't apply in a scripting language. In pretty much every other context it's terrible.
>You should be breaking down those large applications into smaller more maintainable micro-services.
This take ... I'm not even sure where to start: 1. Everything I said applies equally to microservices as it does to monoliths. 2. You must have never worked with microservices if you think they are a panacea. 3. What is the difference between the same amount of code but split between one monolith versus many microservices?
>It's the 4 hour compile time problem from C++ revisited.
Do you know what's even more expensive? Tracking down TypeErrors at Runtime.
> As business requirements change over the life-time of a software project, you need to retire and replace old code with new code that better meets the changing business needs.
Yes .. keep rewriting working code - that's a path to success.
Encapsulation at a larger grain level.
"Yes .. keep rewriting working code - that's a path to success." If you had done any courses on software requirements, you wouldn't be saying that. It's the entire premise behind agile software development.
Oh really? Twenty years of professional experience say otherwise. I don't remember if that came up in either my graduate or undergraduate classes, but I also remember this post going around: https://www.joelonsoftware.com/2000/04/06/things-you-should-... - in my experience, this post is as true as it ever way. Sometimes a ground-up rewrite is necessary, but more often than not, you do it at your own peril.
>Encapsulation at a larger grain level.
Encapsulation has nothing to do with it. The value of compile-time support rises as LOC and complexity goes up - this is irrespective of your development methodology, or the architecture of your stack.
>It's the entire premise behind agile software development.
No. It's not. Agile does not directly address code maintenance or code quality since Agile is (as Wikipedia puts it) "an iterative development process". You can perfectly follow Agile, and turn out unmaintenable code.