Do you subscribe to Seth Godin's or Simon Sinek's posts?
This is a series of similar very small posts, but instead of being inspirational, they talk about SaaS metrics and how to use them.
Here's an example:
"At Growth Ceiling MRR your current marketing spend is required just to prevent your SaaS from shrinking.
As your business grows, eventually the back door will have as much traffic as the front door. Aim to be profitable at that point. Try to keep the Growth Ceiling MRR 20-50% higher than your MRR goal".
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).
Let's use 'attr_reader' as a simple example. It defines a method that returns the value of a member variable. It would be nice to refer to the variable name literally, but this is not possible:
attr_reader foo
The 'foo' above would evaluate to the contents of the variable 'foo'. So, you have to do this:
attr_reader :foo
Because we cannot control how this code evaluated, we must quote 'foo'. This greatly limits what we can express.
Typically, you'd write syntactic sugar on top of regular functions, so that the underlying API is available in the host language to do things like in your example. Using Ruby's class syntax as an example, it gives you a convenient means to describe classes, but underneath that is an API for programmatic manipulation of class objects.
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.
'alias' is special syntax in Ruby. This emphasizes my point: You, as the user of Ruby, do not have the power that the language designers have. You cannot create new syntax rules. I argue that this power is a necessary component for creating true EDSLs, but in practice the term is used much more loosely.
But this isn't about regular Ruby syntax, this is about extending Ruby syntax by embedding new languages within it. A new language may have new evaluation rules. As another user points out, there's a syntax called 'alias' that works similarly to my example, so I disagree that it would be violating anything.
>I'm glad ruby does not allow whatever it is that you're asking for.
I'm essentially asking for macros commonly found in the Lisp family of languages.
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.
Not really it's a good advice BUT this book is targeted at wanabee php developers. Telling them to patch Apache is a very bad idea. He should have chosen phpBB or something like that.
You could think that people are smart enough to understand that they can't patch the most used webserver in the world like that, but hey, remember that Dunning–Kruger effect ?
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.
>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.
You're right. But saying something like
"I’ve never taken a hard look at the Apache source code before, but I have found a few bugs in Apache that I’d love to have fixed."
is like launching a stick in front of a dog.
>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.
It's a book about php. Don't tell me about Composer, Symfony or other things that 0,1% of php coders are using. Php coders don't read, they cut'n'paste.
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?
People wo could write better code in php have already learned how to write better code in other languages. I don't even see the point of this book. Learning to write good code with php looks to me like learning ornithology with Angry Birds
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.