Languages come and go. There was a time when there was a huge momentum behind Ruby (and Rails). It is not (sadly) the case anymore. It is a matter of traction. C'est la vie. I remember back in the 90s there was great interest in Delphi (Borland OO language) but then came Java. I don't even know if someone is still coding in Delphi. I guess Ruby will eventually go the same way.
Do I not like Ruby anymore? (2024)
151–160 of 184 posts
Re: Do I not like Ruby anymore? (2024)
#152Back when autocompletion and stuff were only available in Visual Studio/Xcode/Other bug IDEs, I was forced to use Ruby and fell in love with it. It didn't matter what I used as my editor was Sublime. But when VSCode came and language features became democratized, I never touched a type-less language again. Why should someone opt for a language with absolutely no features where one can have autocompletion, typecheckin…
> jumping to definitions and implementations
This is undervalued. So frustrating in ruby that this doesnt exist or at least isnt easy.
Re: Do I not like Ruby anymore? (2024)
#153I fully agree to the points here, even as a full time ruby lover. Jumping around different languages over the past 10 years really shows staleness in Ruby as a language, even if the ecosystem tries to keep up. The ergonomics of ruby still have me very much liking the language as it fits how I think, but there are a lot of good developments in the usual neighbors, and I see myself picking up both Python and JS ever mo…
Ruby fully typed would be awesome imo, but I know that goes against a lot of the fundamentals in the language. I just like the syntax and expressiveness of it, but coming from typescript, its just such a bad DX having to work in a large Ruby codebase.
> I know that goes against a lot of the fundamentals in the language.
You're not the only person to reply with something like this but just to repeat, Ruby has had official gradual static typing support for 5 years now.
Gradual typing is fundermentally already part of Ruby.
Ruby could do with better static analysis tooling but people are being paid to work on that.
Re: Do I not like Ruby anymore? (2024)
#154> Python is not my favorite programming language. In fact, allow me to drop the euphemism and express my pure, unadulterated thoughts about it: I never liked Python, I see it as a huge red flag and I think the world would be a better place if we all decided to finally move on from it. Why do people make hating a tool their entire personality? I have noticed this same thing with languages like Go ("oh no Go still bad"…
If you do carpentry and you've previously lost a finger using a saw without a saw-stop, and now table saws with saw-stops are an option, you might rightly hate using table saws without one, to the point you wouldn't be willing to work at a shop that forces you to use one.
Re: Do I not like Ruby anymore? (2024)
#155Earlier quoted context omitted.
Lets not equate silly and possibly dysfunctional string substitution macros with macros in higher level languages, which let you inspect and act according to the structure of the AST.
But that's an implementation issue. Do you really want to say, work on a project where somebody renamed "if" to "wenn" because they thought writing code in German would be neat? If you want to make a special use tool, you can write a function like custom_if(cond, then_callback, else_callback) in most languages. Maybe I'm just getting old, but as time goes by I like it more and more when things are obvious and non-mag…
I would rather risk the possibility of dealing with a project where someone did something unorthodox and clearly wrong than work with a language that tries to forbid a priori everything it considers unorthodox. Not that I'm out to defend C's awful clumsy macros, but it's no better when the alternative is nothing at all.
Re: Do I not like Ruby anymore? (2024)
#156Earlier quoted context omitted.
As someone coming from Ruby to TypeScript, I find types cumbersome, verbose, complex, and not of much use. I have been writing and reading TS for the past six months. What am I missing?
Types really start pulling their own weight as the size of an application increases. In order to catch problems in dynamic type languages you end up needing a bunch of additional tests to, ironically, verify the expected type. And even then, those tests don't and can't tell you how a method is actually used throughout the program. Consider the following class class Human def initialize(name) @name = name end end Now…
The classical counterargument to this is that, if you have good test coverage then eliminating @name should lead you directly (via failing tests) to where the name field was being used. This works especially well in codebases which enforce what I tend to call "pseudo"-type systems, for example via clojure's spec and Racket's contracts. Where the shape of data is enforced structurally at runtime.
To be honest, the argument in favor of static typing that I find more compelling is the IDE argument. It definitely is a much richer experience browsing code in an IDE with the benefit of hovering over values and knowing their type, ctrl-clicking to go to where something is defined, et cetera. The equivalent of this interactive experience for dynamically-typed languages was supposed to be the REPL. But I feel like true REPL-driven development has mostly fallen by the wayside, and most environments don't have great support for it.
Re: Do I not like Ruby anymore? (2024)
#157This post reminds me of something. During my first Introduction to Programming course at university, I was taught Java. One thing that I found very troubling is that it wasn't easy, or possible in many cases, to change the programming language. Sure, you can write new functions or methods or classes, but I can't change the keyword for an if-statement. I also remember the TA saying "why would you want that?" I caught…
The reason “custom” programming languages (sometimes called macros) are not popular is that (statistically) no one wants to learn a custom language for each project. People want to learn the basics as few times as possible. Orgs prefer to standardize, most businesses are not snowflakes.
It can be done, but it is not economical, and therefore not practical.
Re: Do I not like Ruby anymore? (2024)
#158Earlier quoted context omitted.
What I meant was how (op modifier *params) "homomorphism" is praised by literally everyone and their dog and it is simply worse than params.op1(modifier).op2(modifier)
What GP (probably) meant is that in Lisp you're supposed to write macros, and when you do, this "is simply not worse" than the dotted message sends: (-> params (op1 mod2) (op2 mod2)) params .op1(mod2) .op2(mod2) There's a reason why just about every Lisp currently in use[1] has `->`/`->>`[2] macros: they're just so easy to write that not having them would be strange. Same with |> in OCaml - with currying, it's litera…
OCaml does have the |> operator
Re: Do I not like Ruby anymore? (2024)
#159Earlier quoted context omitted.
Types in TS can indeed become very complex (depending on their usage of course) and it might not be the best example of the benefits. I personally think that simpler Rust is a better example of the benefits static typing (or maybe something like Gleam).
I'm on the fence. On the one hand I love the power of TS types that they can expose. On the other, I've seen a class of dev that, instead of relying on simple types, will try and make a monstrosity type that does unholy things. I feel a little bit about it like I feel about RegEx. Small and simple are good, but once you start diving into the entire catalog of regex capabilities for a single expression you've made a m…
> On the other, I've seen a class of dev that, instead of relying on simple types, will try and make a monstrosity type that does unholy things.
Totally agree, however that love of complexity will just squeeze into something else had they not had types to have fun with.
Re: Do I not like Ruby anymore? (2024)
#160Earlier quoted context omitted.
Types really start pulling their own weight as the size of an application increases. In order to catch problems in dynamic type languages you end up needing a bunch of additional tests to, ironically, verify the expected type. And even then, those tests don't and can't tell you how a method is actually used throughout the program. Consider the following class class Human def initialize(name) @name = name end end Now…
The classical counterargument to this is that, if you have good test coverage then eliminating @name should lead you directly (via failing tests) to where the name field was being used. This works especially well in codebases which enforce what I tend to call "pseudo"-type systems, for example via clojure's spec and Racket's contracts. Where the shape of data is enforced structurally at runtime. To be honest, the arg…
Yes, the type system basically replaces a degree of unit tests. You no longer need unit tests that are basically just type checking. And it's more comprehensive too. It's much easier to have incomplete test coverage without knowing it than an invalid type system. With such a type system, the app will fail to compile. Of course, you still need unit tests for many other things, but the type system does remove a class of them.
Whether typechecking or unit tests is "better" is really a question of taste.