151–160 of 187 posts
Earlier quoted context omitted.
You're not supposed to acknowledge insincerity. You're supposed to make up another reason that merges the sincere and the insincere viewpoint together.
Yup. But the Dale Carnegie stuff is exhausting. I'm sincere in that I want people to listen to my points without getting their egos in the way.
Earlier quoted context omitted.
I'm one of those people. I'm not sure I'd keep loving Ruby as much as I do now if the majority of Ruby developers end up using the type checker and I'll also have to. I like Ruby in part because it's strongly typed but I don't have to lose time writing types. That was very welcome coming from C and Java in 2006. I prefer to lose time when I pass a type that I shouldn't have passed. It doesn't happen often (not every…
> I don't have to lose time writing types In C#, I write type names when I declare a type, when I create instance of a type, when I declare method argument or return type (which you would probably do even in a dynamic language as a comment - you don't want people to have to go through your code to figure it out themselves, right?) and when I declare a collection of that type. Out of all of these, only the last one se…
ok this is going to sound snarky but it's an honest question: Why not just use Crystal[1]? It's basically just compiled ruby with static types, and it can infer types correctly in most cases without you explicitly noting which they are. The best argument for this (instead of Crystal) is keeping access to ruby gems. [1]: https://crystal-lang.org/
For me it would have the same things that make Typescript appealing: - Full access to a large and mature ecosystem (one that Crystal doesn't quite have) - The ability to gradually add typing to an existing Ruby codebase. No need to rewrite an entire application. Just gradually add types to new code and during refactors. If I was starting a new project I would definitely be considering Crystal, but I still feel like s…
That said, Flow style gradual/optional typing in Ruby would be awesome
Earlier quoted context omitted.
We don't know very much about what ruby 3 types will look like or what other information we'll have. Even a small subset of ruby being transpiled would be a useful thing for some developers. You're much more aware of some of the constraints here than I am, as Oracle doesn't pay me to hack ruby for a living. With a typed AST, there'd be enough information there to build a foundation for a rb2cr tool. I didn't say the…
> Most of the ruby code I want to rescue isn't littered with string-based define_method nonsense. I see what you are saying - but this is where the issue is I think. You may not write code that does sophisticated metaprogramming, but the gems you use are probably fundamentally based on it. Even just requiring some of the standard library uses a surprising amount of of metaprogramming. For example you can't load somet…
I really appreciate your thought on this! I look up to your work a lot. Sometimes I wish I had spent my career with compiler a instead of disassemblers...
Yes, there will be a lot of ruby that can never by crystallized. Yes that kinda sucks. So yes it's very good to explore optional or gradual for incremental refactors and modernization. But if even 1% of ruby code CAN be crystallized, then it's worth it to do it. Maybe not for you, but my time isn't nearly as expensive as yours must be, so I understand your reasoning here I think.
I don't mean to be adversarial here.
Earlier quoted context omitted.
I do need to mix up the verbiage more. In practical terms, people respond much better to having their egos stroked than they do to being told they're wrong. Evidence and logic work much better when someone doesn't feel like their ego is at stake. Telling someone they're right before pointing out that they could be more right is one way to do this. Telling people that they're wrong is more likely to provoke a defensiv…
The only place this works the way you think it does is in your mind. Any normal person is going to see that and register it as goofy and ingratiating. Like Spock or some alien that thinks it's cracked the human code when really it's nowhere even near the uncanny valley.
This may surprise you, but I really wish my experience agreed with you. I really wish most people saw immediately through insincerity and ego-stroking and empty complements. Indeed, some do.
Most of the time, it's disturbingly effective. My data to date suggests that most people won't look too closely when you feed them kind words to hide the others.
Earlier quoted context omitted.
You're absolutely right! Any Turing-complete language can be transpiled to any other. That said, you can't always expect sensible or human-brain-friendly results if you're moving between two languages that work very different.
Why must you keep telling people "You're absolutely right!" It seems insincere and condescending at best. If you really think you know better than the person you're responding to, use evidence and logic, not cheap conversational ploys.
Just my two cents, not parent btw
Earlier quoted context omitted.
> Most of the ruby code I want to rescue isn't littered with string-based define_method nonsense. I see what you are saying - but this is where the issue is I think. You may not write code that does sophisticated metaprogramming, but the gems you use are probably fundamentally based on it. Even just requiring some of the standard library uses a surprising amount of of metaprogramming. For example you can't load somet…
That's where the boundary for transpilation will lie then, but I don't consider that to be a good enough reason to justify not trying to write a tool like that. I really appreciate your thought on this! I look up to your work a lot. Sometimes I wish I had spent my career with compiler a instead of disassemblers... Yes, there will be a lot of ruby that can never by crystallized. Yes that kinda sucks. So yes it's very…
If people are happy to use a subset of Ruby then yes it could be transpiled. But a simple subset of Ruby should work great in the new JIT compilers we're getting anyway, without using Crystal.
IMO it would be a complete waste of time to add a type system that only prevented the most trivial of type errors: mismatching Integer and String.
"Why don't they just use (insert static-typed system here) instead?" someone will inevitably ask. "Because converting a large, complex set of living codebases from one language to another is a non-trivial task that requires boiling any number of oceans. This approach doesn't have that problem." comes the wiser, if less interesting, response.
So it might (or not) be the best option for them at this point, but on the other hand, is it another case that shows a static-typed language is a better option for developing complex systems? IMHO, it is.