71–80 of 360 posts
Earlier quoted context omitted.
Why? Ruby is relatively harmless. Now C… that’s a blight that’s never going away. ;)
I think Python does everything in Ruby's niche but better and Ruby's only benefit is to be different.
Honestly I don't get why some people want to move to static types. Ruby is a dynamic language, that's the point of it... Giant orgs can just use Java or something. We need some languages to stay productive for those of us who work solo or in small groups. If I wanted static types I'd use Java, Go or something (probably Haskell).
Granted, I've only written C in University settings where I'm writing small programs. I had no idea how to write "real" programs. But with Python and Javascript it felt like I could more easily write "real" programs.
What I found out is that I quickly burned out. Around 2011 I felt like I don't know how to start making programs. Programming basically became dreadful. I taught myself to wade through it anyway, convinced I would find the joy again when I get more proficient.
What eventually made me redisocver the joy of Programming is switching to procedural programming and static typing.
First it was with Typescript. Now with Go.
Writing programs with just structs and functions is really enjoyable.
Programming in dynamically typed languages is dreadful. There's no joy in it.
Earlier quoted context omitted.
I think what the parent comment is saying (that I agree with) is that it's easy to over-estimate the cost and under-estimate the value. You don't _have_ to do anything with types, but it's another tool to use where it makes sense. Or put another way, provided it's not mandatory what's the downside to having another tool in the toolbox?
The downside is the ecosystem turning into the JS/TS ecosystem. Where the zealots have pushed TS to the point it all just looks like C# and what makes JS nice is being lost.
2. What made JS uniquely nice?
I wanted to leave these questions entirely open to answer, but I'll add my own opinion on (2) because I feel compelled: nothing, JS is quite possibly the worst language ever designed. Certainly the worst in widespread use.
This is really cool. I’ve used a number of languages and dabbled in a few frameworks but nothing I’ve used brings me joy like ruby does. I approach programming creatively. I think in large systems and architecture. Ruby allows me to skip worrying about the details. Code blocks abstract away thinking about loops and just focus on data. Just about every array operation I could want is there, waiting for a code block. I…
Without those imports, how will people reading the code find the definitions? How will they track down the source code for all the methods being called?
If the answer is "with an IDE / tools", then can't those same tools be used to solve the "mess of importing modules"? If you're using a good IDE, imports and go-to-definition are both solved problems, no matter what language you're using.
If you're not using an IDE, that's a more interesting situation, and without an IDE I much prefer having the explicit imports so that I at least know where to start digging.
Earlier quoted context omitted.
I think what the parent comment is saying (that I agree with) is that it's easy to over-estimate the cost and under-estimate the value. You don't _have_ to do anything with types, but it's another tool to use where it makes sense. Or put another way, provided it's not mandatory what's the downside to having another tool in the toolbox?
The downside is the ecosystem turning into the JS/TS ecosystem. Where the zealots have pushed TS to the point it all just looks like C# and what makes JS nice is being lost.
I don't think I've talked to anyone who has gotten "over the hump" with TS and felt like they were missing something from JS - I may be in a bubble though. It's almost frustratingly beloved in my experience.
Earlier quoted context omitted.
Ruby isn't forcing you to use static types. That being said, I actually think something like Sorbet makes even solo/small teams more productive because it trades some additional time writing boilerplate for dramatically reducing the number of bugs you write.
A good test suite is better at keeping the code bug free. Not needing types is another benefit of good testing. That's my experience, at least.
* Static typing catches many kinds of bugs earlier by simply not allowing you to write incorrect code in the first place.
* No matter how good your test suite is, you're still putting the burden on the human to always remember to write tests for corner cases.
* Static typing allows you have to write many fewer tests by making invalid data unrepresentable. You don't have to write millions of unit tests of the type "what if this list is empty" if the function literally can't accept an empty list.
The RBS files seem like a weird compromise to me. I I'm not sure I see the practical benefit, but maybe someone who has used .d.ts files can explain it. Is it just helpful if your IDE has tooling to use it? Seems like it could be helpful, but also sounds like it will become an annoying "code quality" hoop those of us that don't use VSCode will have to jump through for little benefit. When you read code outside of you…
Earlier quoted context omitted.
Do you think it's possible for well used types to displace the need for some tests?
I'm not the person you're responding to, but I would say: "yeah, but it'd probably be bad practice." What would you be testing for, exactly? That `SomeClass#some_method` raises a `NoMethodError` when you pass it the wrong thing? You could test for that, but I don't think that would be a good use of code or your time. If A is passing the wrong things to B, your specs will fail anyway on that `NoMethodError` once B tri…
Also, what happens when you don't get a NoMethodError? Duck typing is an extremely common practice in Ruby, which means that you can easily run into situations where code "runs" but the output is nonsensical.
Earlier quoted context omitted.
Do you think it's possible for well used types to displace the need for some tests?
I'm not the person you're responding to, but I would say: "yeah, but it'd probably be bad practice." What would you be testing for, exactly? That `SomeClass#some_method` raises a `NoMethodError` when you pass it the wrong thing? You could test for that, but I don't think that would be a good use of code or your time. If A is passing the wrong things to B, your specs will fail anyway on that `NoMethodError` once B tri…
Having types not line up at various boundaries (DB/API/reading from a file) is already a pain, but Ruby made it worse by having that bad data pass through many layers until it actually blows up somewhere far removed from the issue. I worked on very real bugs where e.g. a corner case lead to a date being deserialized as a string and then because the last few characters were numeric interpreted as a number so when treated as a date resolved as millis since epoch (or something similarly crazy). It took ~1 of those bugs for me to be convinced that I had no interest in dealing with those kinds of problems, and adding a 'Date' type means it fails in exactly the right place immediately and is a 2 second fix.
I agree with you though - it'd be a silly test to write, so how do you get the correctness/robustness without either types or tests that look like they're effectively validating types?
Don't get me wrong. I'm happy to see type declaration support in Ruby and have sorely missed it working on long-lived Rails codebases. But it is pretty funny that after years of rah-rah about how static typing was a pointless barrier to productivity, all the "duck-typing" languages have eventually added it after all.
I think it's less funny and more an endorsement of how good tooling has gotten over the last few years. Intellisense et al. have changed the game so that you can actually be more productive from the start with statically typed languages because the inference (and UX/DX to utilize those inferences) is so much better than with dynamic/duck typing.