Hacker News Reader

Comment by raverbashing | Hacker News Reader

Ruby is "too magical" for its own sake. And then people abuse their right to use it, things like overriding class methods, etc (the syntax doesn't help in the least and it has some weird quirks when compared to python)

I'd take a smoke test and some high-level functionality test before the over-testing preached by the TDD "gurus" or any crap spouted by uncle bob. 100% code coverage is a myth, your code still can fail spectacularly with a good code coverage and guess what, most of the software in production today was not TDD'd let alone unit tested.

People sell TDD like a OCD inducing religion instead of something that might be a good idea in some specific cases

View on HN

>Ruby is "too magical" for its own sake

Magic is extremely useful in the right place (e.g. building ORM or admin frameworks) - these can save you from writing a ridiculous amount of code.

Unfortunately since it's an 'advanced' feature lots of programmers want to shove it in places where it not only isn't necessary, but is actively harmful.

Python has all the same features and allows you to write code that is equally horrible (or powerful), but it benefits from a cultural bias in favor of simplicity.

That said, I've still seen unnecessary magic code written by people looking to prove that they are no longer "intermediate developers".

>People sell TDD like a OCD inducing religion instead of something that might be a good idea in some specific cases

I think TDD with integration testing works in almost all cases, but unit tests fail or work poorly in about 85% of cases. Unfortunately, unit test driven development is what the zealots preach.

> Magic is extremely useful in the right place (e.g. building ORM or admin frameworks) -

Totally agree. Python does it in a more explicit way, so that you know "Here be Dragons" (in this object, that was defined in that specific place)

It's not like a piece of casual code in any module can turn your world upside down.

> Python has all the same features and allows you to write code that is equally horrible (or powerful), but it benefits from a cultural bias in favor of simplicity.

It's not a cultural bias. It's a critical difference in the language designs.

In python, monkeypatching is scoped to a module.

In Ruby, monkeypatching is global to the execution environment.

So in Python, you can look at the source code for a module in isolation and deterministically reason about what it does.

In Ruby, you can't. Because you can't know what the execution environment will be.

IMO, it's the main reason why Ruby projects become harder to manage as they grow. Somewhere, someone is monkeypatching, and reasoning about the code becomes harder and less local. I spent 2 years with Ruby and will never use it again if I can help it.

Monkey patching can still make horrendously unreadable python code. I agree that it's better that its scope is localized, but I still think that it's more important that monkey patching is used sparingly, and that requires a cultural bias against it.

Yes, there are few (but important) use cases for it

- Patching a library for testing purposes

- Fixing a bug in some library you can't change

Monkeypatching in Ruby can be localize if you want it to be, see refinements.

I like to think of it as the difference between magical and mechanical.

Imagine you need to know what time it is, and you're offered two options to find out.

One is to recite an incantation, a magic word, and the current time will appear in the air in front of you.

The other option you are offered is a clock or a watch. With this option, anytime you need to know the time you can simply look at the clock face and simply and immediately know, but when peeling back the surface, you can see an intricate set of gears all working together to keep track of the time.

On the surface, both of these options are equally easy to use and useful to find out the current time, but the clock will be far more fixable and extensible.

IMO we should strive to make our frameworks "mechanical" like the clock rather than magical.

I think there is a kind of Goldilocks syndrome that many programmers fall into. The opposite of "too magical" is having to sift through 48 custom implementations in StackOverflow and 192 npm packages to answer questions like "How do I deep clone a POJO?" I hear a lot of developers saying "Ruby/Rails is too constricted". At the same time, I hear a lot of developers saying "Javascript has no clear direction". Well, which bowl of oatmeal will you choose?

100% code coverage of behaviour you care about should not be a myth. I think the qualifier is implicit in most cases.

I agree with this definition, but nobody mentions this qualifier, quite the contrary

I'm curious as to what you think is "magical" in Ruby. If anything, I've found it to be reasonably un-magical as a language. Rails is certainly "magical", but that's a different thing.

method_missing is a prime example. The case of a variable indicating scope and optional brackets are both less magical but still magical in their own right.

But `method_missing` isn't magical, is it? It's entirely logical, well specified, and obviously derived from its Smalltalk message-passing history.

'Missing' brackets are merely a syntactic choice, though I will grant you that variable case is quite weird (though in that sense, I suppose Go is magical too :))

Reply on news.ycombinator.com