Hacker News new | ask | show | jobs
by fantasticsid 2345 days ago
I think focusing on the syntax level is a bit superficial. While Ruby (especially in the context of RoR) lends itself very well to making DSLs and making abstractions, and thus writing superficially good looking, concise, easy to follow (on a syntax level) application code, it really breaks down when the abstraction does not work perfectly the way you want it.

If you have debugged a Rails app and tried to find where in the 10 level call stack a side effect is introduced, knowing that at each level a 'method_missing' could've changed things, and thus you're really looking at a non-linear call stack since each function call can branch out, you'll know the beautiful looking syntax is not free and in fact very costly.

And don't get me started on poorly documented (if any) CoC (black magic)..

4 comments

I think the syntax is very important. It is the aesthetics of a wood floor versus a vinyl floor. Sure, both may get it done, but clean and beautiful syntax that resonants with your brain makes the job more delightful.
> And don't get me started on poorly documented (if any) CoC (black magic)..

I have never liked the idea of (framework-enforced) CoC.

First of all, RoR isn't as CoC as it claims; many things can be configured, which defeats the purpose entirely, and all that remains is the a CoC philosophy.

If Rails would actually enforce CoC, it'd be too restrictive to build anything new with it, so true framework-enforced CoC is not really viable in the real world.

So what people really mean when they say is "Convention over Configuration" they really just mean that the framework doesn't generate a default configuration, but instead the defaults are all encoded within the framework code and its documentation. This is bad. The only benefit is that an empty project looks less cluttered, but that is really only an aesthetic advantage to draw in new users.

The downside is that the project loses documentation. Ideally, I want to jump into a new project, open a config file and be able to have a look at all of its configurations. In Rails I can't do this; I have to either memorize or look up the defaults and then check if they're changed in the current project.

Ultimately, its idea of CoC makes rails easier for starters to get into, but a total pain for people who don't care to get into it and just want to make some specific change and for anyone with a specific goal in mind that doesn't align neatly with how the framework thinks you should do things.

I agree with you on the comment about abstractions, but I think I would rather have Rails with esoteric code than something less "conventional" with esoteric code.
yeah, esoteric is bad, whether Rails or others. But that's just my impression with Rails, and I'm much more comfortable using other less magical libraries. I guess Ruby is just too good at making abstractions, and I tend to believe that 'making and using abstractions feel great and productive, unless it's made by others'
CoC means many things. What do you use it to mean here?
Yeah, sorry for the abbreviation. I meant 'Convention over Configuration'
Probably "convention over configuration".
my best bet: Convention over Configuration (had to google tbh)