Yes. Too often this is done even with complex procedures inside methods. A good DSL should be syntactic sugar for making things easy or at least provide some syntactic vinegar for doing non-recommended things (while still allowing them).
Ah. I see. That Ruby doesn't afford this can be somewhat annoying.
A counter example is using "alias". It can accept bare words, symbols, or strings.
If you really wanted to get around this you could use method_missing on the class but that can open a can of worms.
I'm the author. In fact, the first bit of advice I have in the book is: Don't.
DSLs often involve metaprogramming, but they don't have to. I'm writing it to record the code practices that I have found useful in getting things right and gather advice and tips from others who have done the same. DSLs are always about communication, so my goal is to create a book that helps developers communicate the purpose of the aspects of their project through code.
The article is about writing better code. My guess is that the PHP developers who do want to write better code would probably take the advice.
Is your point that nobody should ever suggest that PHP developers write better code?
He says: "Working with others to get patches accepted and bugs closed is a crucial skill in writing good code"
This article does not tell people to patch Apache. The point, as for as I can tell, is to explore the projects you use so you can learn to write better code.
Then you say "they can't patch the most used webserver in the world like that"
What is "like that"? As far as I can tell it's "working with others". Although I've never patched Apache, I'm confident I'll need to work with others to do so.
The article gives good advice. I don't understand why you would jump to the Dunning–Kruger effect to seemingly assume that the readers are incapable of following the advice.
I actually have customers on that product. But they're unfocused and unrelated. How do you add features when the customer needs aren't clear? You don't. You just kill it.
This is why I made the point about killing my other "product". I had nowhere to go with it. Perhaps I didn't say it well enough, but my initial plan was to build something but the problem wasn't marketing, it was that nobody wanted it.
My book, however, people want. I looked for what developers need first and then built a product around that, rather than thinking of something that might be nice and try to get people to buy it (like my CMS hosting).
Less than an hour of billing and they've got new techniques and better understanding of application architecture. It's also the answer to life the universe and everything.
It does still have 1 failing test about redefining the initialize method with a block, but it works for all other cases.
The Ruby 3.2 Data class is based on C code from Struct. This is all implemented with Ruby.