5 ms·

Programming languages shouldn't have two competing two type systems in them. Static typing in a scripting language like Ruby is just poor engineering.

Timon3 3y ago
Static typing for JavaScript hasn't turned out to be poor engineering - it helps massively and has become the de-facto norm. Similarly, static typing in Python is a massive help and keeps getting better. Why would Ruby be any different?
- ReflectedImage 3y ago
  Because JavaScript is the worse programming language in common commerical usage today. It was designed over several decades by browser manufacturers. 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.
  - Timon3 3y ago
    > Because JavaScript is the worse programming language in common commerical usage today. It was designed over several decades by browser manufacturers. 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.
    - ReflectedImage 3y ago
      Static typing is a very bad software development practice. There are a lot of other software development practices that are superior to it. "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.
      - Timon3 3y ago
        > Static typing is a very bad software development practice. There are a lot of other software development practices that are superior to 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?
pawelduda 3y ago
Type systems aren't competing, it's usually people fighting over them and it's no different in Ruby
baq 3y ago
Typescript is so good I'd love to see Python, Ruby, PHP, etc. and every other dynamic language steal at least half of it. Python already tries, I think it was typescript's early success which tipped the scales from 'type hints are whatever' to what's there today.
- pawelduda 3y ago
  Sorbet is pretty good in Ruby, there are rough edges but for that you have good escape hatches so you don't have to work full time for the type system
  - davidatbu 3y ago
    In my experience, in an RoR codebase, the dynamic-ness of rails severely reduces its utility to only enabling better auto-complete (as opposed to also helping out with writing logically correct code). 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.
  - dtech 3y ago
    In my experience Sorbet is a lot less useful than mypy and frequently unhelpful or useless, and both of those aren't in the same league as Typescript.
    - davidatbu 3y ago
      That ranking of type systems matches my experience a 100% too.
- stephenr 3y ago
  PHP already has an opt-in type system that's runtime safe (ie it's not just compiled away like in TS). The major piece of the puzzle missing is generics support, but other type handling is already there.
macspoofing 3y ago
>Static typing in a scripting language like Ruby is just poor engineering. 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.
- ReflectedImage 3y ago
  "maintaining LARGE applications" 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.
  - macspoofing 3y ago
    I can't tell if this is a troll post or not. >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.

Timon3 3y ago

Static typing for JavaScript hasn't turned out to be poor engineering - it helps massively and has become the de-facto norm. Similarly, static typing in Python is a massive help and keeps getting better. Why would Ruby be any different?

ReflectedImage 3y ago
Because JavaScript is the worse programming language in common commerical usage today. It was designed over several decades by browser manufacturers. 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.
- Timon3 3y ago
  > Because JavaScript is the worse programming language in common commerical usage today. It was designed over several decades by browser manufacturers. 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.
  - ReflectedImage 3y ago
    Static typing is a very bad software development practice. There are a lot of other software development practices that are superior to it. "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.
    - Timon3 3y ago
      > Static typing is a very bad software development practice. There are a lot of other software development practices that are superior to 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?

pawelduda 3y ago

Type systems aren't competing, it's usually people fighting over them and it's no different in Ruby

baq 3y ago

Typescript is so good I'd love to see Python, Ruby, PHP, etc. and every other dynamic language steal at least half of it. Python already tries, I think it was typescript's early success which tipped the scales from 'type hints are whatever' to what's there today.

pawelduda 3y ago
Sorbet is pretty good in Ruby, there are rough edges but for that you have good escape hatches so you don't have to work full time for the type system
- davidatbu 3y ago
  In my experience, in an RoR codebase, the dynamic-ness of rails severely reduces its utility to only enabling better auto-complete (as opposed to also helping out with writing logically correct code). 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.
- dtech 3y ago
  In my experience Sorbet is a lot less useful than mypy and frequently unhelpful or useless, and both of those aren't in the same league as Typescript.
  - davidatbu 3y ago
    That ranking of type systems matches my experience a 100% too.
stephenr 3y ago
PHP already has an opt-in type system that's runtime safe (ie it's not just compiled away like in TS). The major piece of the puzzle missing is generics support, but other type handling is already there.

macspoofing 3y ago

>Static typing in a scripting language like Ruby is just poor engineering. 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.

ReflectedImage 3y ago
"maintaining LARGE applications" 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.
- macspoofing 3y ago
  I can't tell if this is a troll post or not. >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.