Clojurians Log v2

Languages in general is optimized for specific objectives. It is always easy to point to the unoptimized parts for criticism. Based you your experience what does ruby optimize for?

the creator of ruby claims that it's "optimized for programmer happiness", but having worked on it professionally for over a decade before bailing on the language it seems like it's optimized for superficial delight

I still use ruby, but I use it for text processing and for when I need something just a little more powerful than shell scripts, it's a perl replacement

superficial delight meaning "not typing pesky delimiters" and "not being restricted in what you can customize and extend at runtime", but long-term it leads to syntax warts like this and unpredictable systems that need a mountain of (always slow) tests just to have any confidence in a large application

I think Ruby optimises for "reading like natural language". The problem is, when you optimize for that, you unoptimize for everything else.

A good example is how the community decided to use DSLs for basically everything. This week I had to literally write almost the same 30 lines in five different files because they are all DSLs so I can't just re-use code - because there's no "data" or even "API" in use, it's all custom syntax

@corasaurus-hex Ruby became more tolerable for me because I ported my Clojure plug-in for Ruby. Amazingly, I have a nREPL for Ruby, and I connect to it, can evaluate code, load file, and check results. Otherwise, I would probably be screaming right now (or, at least, screaming more than what I am hahahahaa)

instead you could just include a module in each of those classes and use the included hook to metaprogram those DSL calls!!

@mauricio.szabo Maybe that's why majority of Ruby is used with a dsl (I.e. Rails). That make sense

yeah, it's not destructuring, it's a named parameter

it's an annoying difference

When I did the Washington University "Programming Languages" course (CSE341), they taught Racket (dynamically typed FP), Standard ML (statically typed FP), and Ruby (dynamically typed OOP) -- my first real exposure to Ruby -- and it is a weird language in so many ways. I didn't care for the syntax in the first place, but the metaprogramming and every class being open for extension -- even the built-in classes like numbers -- seemed to make it nearly impossible to tell what any given piece of code would do purely by inspection, since any behavior can be modified anywhere else in the code. 🤯

@nbtheduke yes, it's a named parameter... except that it doesn't behave as a parameter. If I try to do some_method(parameter) in my example, it would crash with Wrong number of arguments (expected 0, got 1)

huhhh

Yep, that was the behavior starting at Ruby 3.0

I think what bothers me on this is this whole weird thing that Ruby have, that are "special parameters" to methods. There are "regular" parameters, like def a_method(a, b), there are "blocks" like def other_method(&a_block), and now "named parameters" is a special thing too, with this syntax def named_method(a:, b:) Like, I can't call other_method(something) because something will be interpreted as a "regular parameter", nor I can call named_method(something).

I feel like this is due to the ruby allergy to typing delimiters like parens and curly braces, creating a syntax that thrives on ambiguity and special cases

and then if you take that and accrete new features on top of it, constantly compromising with new ambiguous syntaxes, you end up with this mess