5 ms·

It's not like strong typing came after Ruby. In fact, duck typing was a _feature_ of Ruby on its days. At the end of the day, you choose your battles, it's n

It's not like strong typing came after Ruby. In fact, duck typing was a _feature_ of Ruby on its days. At the end of the day, you choose your battles, it's not a black-or-white decision.

JW_00000 4y ago
No, but gradual/optional typing did come after Ruby. Back in 2005, you could choose between static typing with type checking but lots of verbosity (e.g. Java "Point point = new Point();" or C++ "for (std::map<int, BlaBla>::iterator it = myMap.begin(); it != myMap.end(); it++)") or dynamic typing without type checking but also without the verbosity. Since optional typing, dynamically typed languages got the guarantees of type checking, and JavaScript/TypeScript and Python have embraced this. With type inferencing, statically typed languages lose their verbosity, and Java and C++ have embraced that (as have newer languages like Rust, Go, and Swift). It feels like Ruby hasn't progressed on this front...
- JeremyNT 4y ago
  Ruby does have optional type annotations, if you want them: https://github.com/ruby/rbs https://github.com/ruby/rbs
- FpUser 4y ago
  >"for (std::map<int, BlaBla>::iterator it = myMap.begin(); it != myMap.end(); it++)")" All you really needed is: for (auto it : myMap) and you still get compile type safety
  - Yoric 4y ago
    Well, in 2005, you didn't.
    - FpUser 4y ago
      Well we are not discussing 2005 version of Ruby. Why limit C++ to that particular time?
      - Yoric 4y ago
        Well, the GP was very explicitly discussing the situation in 2005, which led to the then appeal of dynamic languages. Comparing with the situation in 2023 doesn't seem to contribute?
- Yoric 4y ago
  I'll pedantically remind the audience that type inference dates back to the 70s and has been present in the industry at least since the 90s. But in truth, you're right. Very few people know/cared about type inference at the time.
- pantulis 4y ago
  Isn't RBS for Ruby a way of having optional typing? (Not challenging here, honest question :P)
  - Gigachad 4y ago
    I’m not aware of anyone using it, we evaluated it at work and decided it wasn’t worth using despite us making heavy use of TypeScript and Rust.
- munificent 4y ago
  > Since optional typing, dynamically typed languages got the guarantees of type checking Optional typing, at least in TypeScript, will not give you the guarantees of type checking. It finds many of your type errors, but not all of them because the type system is deliberately unsound.
jerf 4y ago
Static typing was a nightmare (by modern standards) in the 1990s. Dynamic scripting languages were such a breath of fresh air that we were willing to pay the steep performance penalties without hardly a thought. Sort of like the saying "deleted code is debugged code", code that you actually write always performs better than the code you didn't write because it was too soul-sucking. But static typing languages, library stacks, and environments have come a long way in the last 30 years. Now I prefer even to "prototype" in static languages because the crossover to when they start providing me net benefit is around a week or so into my development process. I will not claim one is completely better than the other, but the balance is a lot more even than I would say it was ~20 years ago.
- lmm 4y ago
  Actually almost all the stuff that's gone mainstream in the last 30 years was already around in the '90s if you used OCaml (or indeed Haskell). But in fairness not many people did.
  - jerf 4y ago
    Even the languages that were painful in the 1990s have gotten better. Some of it was the system libraries, some was just the lack of experience in API design, some was just a lack of awareness that better was even possible. While I don't like C++ at all, certainly C++ in 2023 is a lot more tolerable than C++ in 1997. I learned programming in the late 1990s. Looking at Windows programming at the time looking like gibberish to me and I looked forward to the day I would understand it. Honestly, it still looks like gibberish to me. I understand the whys and the wherefores better now and if I had no choice, yeah, I could learn it and write it, but the code from that still reads absolutely awfully to me, just unbelievably bad by almost every modern standard. Even when you're writing approximately equivalent code in C# at the same low level of acquiring handles and manipulating them with very low level APIs, it's just so much better now.
- brigandish 4y ago
  > Now I prefer even to "prototype" in static languages because the crossover to when they start providing me net benefit is around a week or so into my development process. I've moved from Ruby to Crystal as much as I can, and at first I found it painful but now I appreciate the myriad complaints from the type checker. It's eliminated 99% of the specs I used to have to write.
JamesSwift 4y ago
Ruby is one of the few successors to smalltalk with "true" everything is an object and message passing. As such, duck typing is in fact a feature and if you can internalize how it differs from traditional OOP then it becomes very powerful. It is a double edged sword however, and can be wielded poorly.

It's not like strong typing came after Ruby. In fact, duck typing was a _feature_ of Ruby on its days. At the end of the day, you choose your battles, it's not a black-or-white decision.

JW_00000 4y ago

No, but gradual/optional typing did come after Ruby. Back in 2005, you could choose between static typing with type checking but lots of verbosity (e.g. Java "Point point = new Point();" or C++ "for (std::map<int, BlaBla>::iterator it = myMap.begin(); it != myMap.end(); it++)") or dynamic typing without type checking but also without the verbosity. Since optional typing, dynamically typed languages got the guarantees of type checking, and JavaScript/TypeScript and Python have embraced this. With type inferencing, statically typed languages lose their verbosity, and Java and C++ have embraced that (as have newer languages like Rust, Go, and Swift). It feels like Ruby hasn't progressed on this front...

JeremyNT 4y ago
Ruby does have optional type annotations, if you want them: https://github.com/ruby/rbs https://github.com/ruby/rbs
FpUser 4y ago
>"for (std::map<int, BlaBla>::iterator it = myMap.begin(); it != myMap.end(); it++)")" All you really needed is: for (auto it : myMap) and you still get compile type safety
- Yoric 4y ago
  Well, in 2005, you didn't.
  - FpUser 4y ago
    Well we are not discussing 2005 version of Ruby. Why limit C++ to that particular time?
    - Yoric 4y ago
      Well, the GP was very explicitly discussing the situation in 2005, which led to the then appeal of dynamic languages. Comparing with the situation in 2023 doesn't seem to contribute?
Yoric 4y ago
I'll pedantically remind the audience that type inference dates back to the 70s and has been present in the industry at least since the 90s. But in truth, you're right. Very few people know/cared about type inference at the time.
pantulis 4y ago
Isn't RBS for Ruby a way of having optional typing? (Not challenging here, honest question :P)
- Gigachad 4y ago
  I’m not aware of anyone using it, we evaluated it at work and decided it wasn’t worth using despite us making heavy use of TypeScript and Rust.
munificent 4y ago
> Since optional typing, dynamically typed languages got the guarantees of type checking Optional typing, at least in TypeScript, will not give you the guarantees of type checking. It finds many of your type errors, but not all of them because the type system is deliberately unsound.

jerf 4y ago

Static typing was a nightmare (by modern standards) in the 1990s. Dynamic scripting languages were such a breath of fresh air that we were willing to pay the steep performance penalties without hardly a thought. Sort of like the saying "deleted code is debugged code", code that you actually write always performs better than the code you didn't write because it was too soul-sucking. But static typing languages, library stacks, and environments have come a long way in the last 30 years. Now I prefer even to "prototype" in static languages because the crossover to when they start providing me net benefit is around a week or so into my development process. I will not claim one is completely better than the other, but the balance is a lot more even than I would say it was ~20 years ago.

lmm 4y ago
Actually almost all the stuff that's gone mainstream in the last 30 years was already around in the '90s if you used OCaml (or indeed Haskell). But in fairness not many people did.
- jerf 4y ago
  Even the languages that were painful in the 1990s have gotten better. Some of it was the system libraries, some was just the lack of experience in API design, some was just a lack of awareness that better was even possible. While I don't like C++ at all, certainly C++ in 2023 is a lot more tolerable than C++ in 1997. I learned programming in the late 1990s. Looking at Windows programming at the time looking like gibberish to me and I looked forward to the day I would understand it. Honestly, it still looks like gibberish to me. I understand the whys and the wherefores better now and if I had no choice, yeah, I could learn it and write it, but the code from that still reads absolutely awfully to me, just unbelievably bad by almost every modern standard. Even when you're writing approximately equivalent code in C# at the same low level of acquiring handles and manipulating them with very low level APIs, it's just so much better now.
brigandish 4y ago
> Now I prefer even to "prototype" in static languages because the crossover to when they start providing me net benefit is around a week or so into my development process. I've moved from Ruby to Crystal as much as I can, and at first I found it painful but now I appreciate the myriad complaints from the type checker. It's eliminated 99% of the specs I used to have to write.

JamesSwift 4y ago

Ruby is one of the few successors to smalltalk with "true" everything is an object and message passing. As such, duck typing is in fact a feature and if you can internalize how it differs from traditional OOP then it becomes very powerful. It is a double edged sword however, and can be wielded poorly.