|
|
|
|
|
|
by zverok
935 days ago
|
|
|
(Author here) I don't think this corresponds to my experience. I am working as a staff engineer in big production codebases (with all the traits of those: some code is good, some is bad, some is unrecognizable legacy, sometimes we are in a hurry and write awful code, sometimes we have time for refactoring etc.) And my observations about the logic and perception of the features are drawn from the practice of code reviews, mentoring new people, and discussing ways of solving tasks in this environment. Obviously, I am frequently a driver of new code practices, but I am also trying to be a good person and a good colleague and notice how comfortable people are with various parts of the codebase, various idioms, etc. One of the main topics of this article series is uncovering the language's logic and intuitions (to stop perceiving it as a "bag of random syntactic features you need to learn or should guess") and using those intuitions for code that is, yes, better for the reader, but the code that can be created in a quickly-changing production environment and rewritten fearlessly. |
|
|
A smart individual can adapt to any environment and its quirks and thrive. But some of their capacity always goes towards serving the "quirks adaptations". It's kind of like GPT. It's a smart bot, and if you ask it to answer a math puzzle by writing backwards in Romanian haikus - it will. But the effort to make haikus in backwards Romanian make its math puzzle answer that much more likely to be wrong.
I have no shadow of a doubt that people who are used to Ruby know every shade of gray in how to forward arguments through byzantine syntax. Much like PHP programmers have zero issues with every function in stdlib randomly switching needle/haystack parameter order, or remembering which identifiers are case sensitive and which aren't, and the mix of conditions where an identifier needs a $ in front or doesn't need it. Or which one of 10 different stdlib APIs doing kind of the same, but in different state of deprecation and introduction they should use. Or the fact PHP has a type system, but not for the most common data type (array), and there are two modes of validating parameters (strict and non-strict) which can be switched on and off per file and bomb on you unexpectedly when combining both, despite your code is logically correct in isolation. It's trivial stuff to them. They can juggle all this and more. But someone coming from outside would take one look and say "how about no". Because PHP for all its advancements is not a good language.
And Ruby is also not a good language. In fact, it's clearly getting worse over time.