[hoorayimhelping]

Isn't it great that people can find the tool that suits them best? Now if only we could make it so people were secure enough in their choices and preferences that they didn't have to point out that they prefer X in a thread specifically focused on Y, we might avoid a bunch of needless gnashing of teeth and flame wars.

[tolmasky]

Seems like a reasonable critique in a thread exalting the amazing success of Y. I'm sure the developers of Y care about a newbie perspective of Y, and a comparison often serves as a good tool to show why something is confusing.

[aeze]

How was it a critique? He just said he didn't like it, and exaggerated a few things.

[tolmasky]

Maybe its because I'm a JavaScript dev, but I seem to clearly understand the critique (vs maybe if you are a Ruby dev it just sounds like "I don't like it"): too many built-in methods, lots of magic behavior, and an over-reliance on syntactic sugar. Seems pretty straightforward.

Possible non-code-altering solutions to the problems include: 1) limiting educational material on Rails to only use a subset of the built-in methods so that newcomers aren't overwhelmed by feeling they need to learn the entire std library before being able to make progress, 2) Using more explicit versions of code vs the more terse but harder to understand versions enabled by syncretic sugar to ensure that people coming from other languages first understand what is going on, then are blown away when they discover you can write it in an even cooler way, 3) a deeper explanation of what is going on under the hood to make the magic seem "OK".

[aeze]

I considered it an "I don't like it" post because aspects that the top level poster described are intentional features, not problems or issues that need to be fixed (at least according to DHH & co).

And I guess the word 'critique' connotes a somewhat more detailed, analytical assessment - at least to me.

[tolmasky]

I guess the perspective difference comes from having run and worked in open source myself in the past: its a better strategy to try to understand the pain point the user is facing regardless of how "analytical" the assessment is. A lost customer is a lost customer, and in this particular case, this seems to be a common critique. Given that the critique attacks as you say intentional features, that's why my mind went directly to the problem of education of the features. Perhaps this class of use is a lost cause: or perhaps this reflects a gap in the learning curve that could be strengthened.

[aeze]

Fair enough. There are great resources available like https://rebuilding-rails.com/ which should receive more attention, IMO.

[Finnucane]

Python and Ruby come at problems from different directions, and you have to go with the one that suits you. Python-philosophy says "explicit is better than implicit" and Ruby-philosophy says "convention over configuration."--at some level these are irreconcilable. If you want to work one way, the other way is not going to make you happy.

[publicfig]

Well, we might as well get rid of the comments altogether if making a statement related to the content of an article is grounds to consider it "needless gnashing of teeth and flame wars".

[minimaxir]

It's perfectly fair to compare competing products in an apples-to-apples comparison.

[afarrell]

I find people mostly tend to get defensive when they are being attacked. I think as long as people can police their own tone effectively, that it prevents discussions from devolving into something toxic.