8 ms·

Funny, everything in this post is exactly why i prefer Python(+Django/Flask) over Ruby(+Rails). Too much magic happening everywhere, a gazillion of built-in met

by sauere 11y ago

Funny, everything in this post is exactly why i prefer Python(+Django/Flask) over Ruby(+Rails). Too much magic happening everywhere, a gazillion of built-in methods, weird shit happening all over the place, all that combined with all the syntactic sugar Ruby offers. Granted, it might look "beautiful" in the eyes of a experienced RoR developer, but personally i find it just makes code very hard to read. Just my 2 cents.

shockzzz 11y ago
Yeah, I go back and forth. I find Ruby aesthetically pleasing, but, in a way, harder to understand. Python represents a lot of "truth" for me. I would definitely say, though, that I find Ruby development to be amazing. And I find debugging in Python to be similarly awesome.
- jessewmc 11y ago
  What do you use for Python debugging? I'm working on a large Python project coming from rails work and my biggest frustration is no equivalent to pry. I find Python debugging incredibly painful by comparison.
  - reinhardt 11y ago
    Not a ruby dev so don't know how they compare to pry but I've been a happy heavy user of ipdb [1] and pdbpp [2]. [1] https://pypi.python.org/pypi/ipdb https://pypi.python.org/pypi/ipdb [2] https://pypi.python.org/pypi/pdbpp https://pypi.python.org/pypi/pdbpp
  - jsmeaton 11y ago
    pdb and pudb seem to be reasonably popular. I use pdb myself. I haven't used pry, so I'm not sure about equivalences.
  - heroprotagonist 11y ago
    PyCharm's debug tools are top notch. It's based on PyDev, which is an alternative that can be used independently in other IDE, but it's really the integration with the IDE that makes it a much better alternative than using, say, PyDev in Eclipse or vim. Here's a brief overview of PyCharm debugging functionality: http://pedrokroger.net/python-debugger/ http://pedrokroger.net/python-debugger/ I really like the ease of use for remote debugging. It's essential in helping to maintain a Linux development environment that closely resembles production while actually coding on a work laptop that runs Windows. Beyond that, I often use the remote functionality to run one-off scripts to retrieve and process data from a production Django system (though, generally this is restricted to 'read' operations unless it's been tested in dev).
  - antod 11y ago
    In terms of web debugging instead of general code debugging tools mentioned by others, the common Python frameworks have toolbars based on Armin's Werkzeug one: http://werkzeug.pocoo.org/docs/dev/debug/ http://werkzeug.pocoo.org/docs/dev/debug/ eg... For Pyramid: http://docs.pylonsproject.org/projects/pyramid-debugtoolbar/en/latest/ http://docs.pylonsproject.org/projects/pyramid-debugtoolbar/... For Flask: http://flask-debugtoolbar.readthedocs.org/en/latest/ http://flask-debugtoolbar.readthedocs.org/en/latest/ For Django: https://github.com/django-debug-toolbar/django-debug-toolbar https://github.com/django-debug-toolbar/django-debug-toolbar I have no idea how well they compare to equivalent Rails tools though.
glossyscr 11y ago
> Too much magic happening everywhere, a gazillion of built-in methods, weird shit happening all over the place Couldn't agree more on this. Magic is good if you understand the underlying stuff but if you don't and you are once offtrack you are lost. Maybe it's also a matter of taste. However the hype and traction DHH could build when RoR started was quite impressive.
- jshen 11y ago
  I think this is wrong. Nearly all of us build on top of things we don't understand. I don't understand the physics of a harddisk, or the pipelining of a CPU, or some of the low level OS functionality. The issue is when do each of us, as individuals and/or teams, really need to understand more. And perhaps more importantly, when does it make business sense to leverage magic to get to market faster, build cheaper, or find market fit before worrying about building the most robust thing possible.
  - deleted 11y ago
    [deleted]
    - random_rr 11y ago
      That's a pretty crazy claim. So, do you build your own interrupt gates, and take those into account when you're writing PHP? How about electrons? Can you draw me a graph of the electrons currently residing in your computer case/laptop? Can you explain to me exactly how your PHP code will look in binary? Sorry to be snippy, but you're making a pretty audacious claim there. I don't think any reasonable software engineer/developer can claim to fully understand every underlying principle. I mean, you can have an abstract, high-level idea of how things work, but do you really think you know the intimate details of every single piece of hardware/software involved in writing your code?
      - jacquesm 11y ago
        Making a specific claim about this is nonsense but making a claim about this in principle is perfectly valid. it's the difference between being able to wire up a logic gate from transistors with a basic understanding of how they work and to be able to wire up a cpu, ram and some io from logic gates, being able to wire up a computer from cpu chips, ram chips and IO chips. Even if you don't know the exact details of the latter in principle you understand that whole device that you just built. So the claim is not so crazy as it might sound initially.
hoorayimhelping 11y ago
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.
- minimaxir 11y ago
  It's perfectly fair to compare competing products in an apples-to-apples comparison.
- afarrell 11y ago
  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.
- tolmasky 11y ago
  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 11y ago
    How was it a critique? He just said he didn't like it, and exaggerated a few things.
    - tolmasky 11y ago
      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".
tclancy 11y ago
This was my reaction as well. "The menu is omakase" clearly violates "explicit is better than implicit".
- aantix 11y ago
  Why throw out some catch phrase without providing specifics? We all adopt certain amount of implicit choices in our lives because if we had to be explicit about everything, we'd be bogged down in choice-making and not really get anything done. Why care about choosing the right ORM, Logger, templating engine when there's real business problems to solve? If there's a true business advantage to choosing an alternative, then substitute, but eventually you have to get on with the show and make something meaningful. Strong defaults and conventions are a feature and Rails nails it better than any other framework out there.
lectrick 11y ago
Similarly, Python turned me off immediately when I tried to exit the REPL with "exit" and it goes "The way you exit is with control-D." It fucking knew I wanted to exit, and instead lectured me. WTF, Python? Seeya, dick.
- talideon 11y ago
  That's because there's no magic in the REPL. You're typing nothing but regular Python code. 'exit' is an object. Expressions typed at the REPL are stringified. Thus, when you type 'exit', it gets stringified, and thus you get that message. 'exit' is also a callable, so if you type 'exit()', the REPL will exit. The same goes for 'help', 'copyright', 'credits', and 'license': they're just objects that get stringified. Having the REPL work the way you want would mean building magic into it, and magic avoidance is part of the language's culture, so that's not going to happen. Having it print that message is a compromise between keeping things friendly and building magic into the REPL, if you consider printing the result of expressions automatically to be magic. The Python REPL isn't being a dick, it's being parsimonious and predictable in its behaviour.
  - NoGravitas 11y ago
    I wrote nearly the exact same explanation minutes after yours, but I've deleted mine because yours is clearer.
  - bphogan 11y ago
    Yet the code behind the REPL knows exactly what I was attempting to do and tells me that. This is what Ruby developers mean when they say they optimize for developer happiness over bowing to the will of the computer. /uses Python regularly and enjoys it.
    - sanderjd 11y ago
      > Yet the code behind the REPL knows exactly what I was attempting to do and tells me that. Not really – all the code knows is to stringify objects, and it saw the object called `exit`, for which the stringified version is that error message. But nowhere in that flow does the code know how call anything that could exit the REPL. /doesn't use Python regularly and thinks the smart move would be to make the REPL understand certain things as commands instead of normal Python code.
aivosha 11y ago
Funny you should mention Django, because its the magic framework in python land that does all those things you label Rails doing and it does it way way worse than Rails.
- batiste 11y ago
  Care to develop what he labeled and how Django is making does it worse than Rails? I have a hard time to see it knowing both Frameworks.
- acdha 11y ago
  That might plausibly have been true in the past, at least if you hadn't heard of Zope/Plone, but Django has been moving away from that for close to a decade: https://www.djangoproject.com/weblog/2006/may/01/magicremoval/ https://www.djangoproject.com/weblog/2006/may/01/magicremova... By now, it's hard to tell what you had in mind – something like contrib.admin or the global settings file?
- jsmeaton 11y ago
  The only real magic left in Django is the metaclasses that ORM models use to turn class based fields into instance level descriptors. class Model(models.Model): field = models.SomeField() rather than.. class Model(models.Model): def __init__(self, *args, **kwargs): field = models.SomeField() super(*args, **kwargs) Django is most certainly the framework that bundles a whole lot of choices together (similar to Rails), but the magic it performs on behalf of the user is extremely minimal.
JohnBooty 11y ago
I'm a Rails developer and I'm coming to feel this way as well. I agree with most of what's in the Rails Manifesto except the convention-over-configuration thing. Too much "magic" happening. Magic's cool, but I need to know why a certain thing works or why it doesn't work. Rails is the only environment in which I've routinely found myself utterly stumped. Not because it's hard, because it isn't. But the thick layer of "magic" makes it awfully hard to debug sometimes.
- jmagoon 11y ago
  We are in the same boat. I find myself relying way more on pure ruby classes. It's also dangerous because Rails fits a specific niche, like he mentions--building (potentially) many web systems quickly. We chose to migrate large legacy systems to rails, which meant lots of the nice convention just. doesn't. work. Day 1, you're already digging in to figure out how to get around the magic!
- ansonhoyt 11y ago
  For me, magic isn't the problem. I like the magic of conventions, but not when it is painful to pull back the curtain. For Rails, I think pain comes when magic stands on poor internals, which gets amplified when gems layer on their own painful workarounds...and I have to sort through all of it. That's why I'm excited about Sean Griffin's work on the [Attributes API](http://edgeapi.rubyonrails.org/classes/ActiveRecord/Attributes/ClassMethods.html http://edgeapi.rubyonrails.org/classes/ActiveRecord/Attribut...). To do it, he's had to refactor out a lot of internal monkey patching so that (in Rails 5) there is only one source of type information for an AR model. This means gems can extend AR, I can extend AR, new requirements can walk into my door that I can deliver on without monkey patching or opening Pandora's box of a patch of crappy Rails internals. The magic is still there, but it's done it a way so the magic doesn't fall apart in unexpected, unmanageable ways. That's what matters to me.
krstck 11y ago
As I've entered the more intermediate stage as a Rails developer, I've noticed that the "magicalness" that allowed me to do so much so quickly as a beginner, is often actually getting in my way. Perhaps when I reach the "advanced" stages, I'll learn to love the magic again, but I'm in this awkward stage of knowing what I want to do but not knowing how to tell Rails to do it (or stop doing it, as the case may be).
hardwaresofton 11y ago
Everyone that feels this way please give Sinatra (http://www.sinatrarb.com/intro.html http://www.sinatrarb.com/intro.html) a try Complexity/perceived burdenwise, I think java is to rails as rails is to sinatra (or a similiarly small framework). There may be a point where you want your functionality bundled and presented as a framework (if you, like me, think of frameworks as bundled and groomed libraries/functionality), but if you're not sure you're at that point (or don't know what that point is), try to start smaller (like sinatra) and go bigger, rather than the other way around (starting with the biggest tool you could find, trying to find the smallest). I strive not to become a good developer on X platform (for Y language) but rather just a good developer who's proficient with Y language (and happens to be able to use X lib).
- supergeek133 11y ago
  Seconded. I started on Rails and said to myself "this is doing too much on it's own, there is WAY too much going on". Then I started using and looking into Sinatra, and it's way more basic and Ruby instead of Magic.
  - fennecfoxen 11y ago
    Sinatra is all well and good until you have an application complex enough that you want to start applying some interesting methods of code reuse across several routes, and want to share several facets of, say, object loading and authorization, or something around page rendering. At that point you run into the fact that all your tools for manipulating the request and response are built into a singleton object (your instance of Sinatra::Base) which begins to inhibit several very useful forms of code reuse (such as most OO inheritance schemes, for a start). If I had a dollar for every minute I wasted rewriting things that I could have for nearly-free with (for example) Rails and CanCan and a quick call to load_and_authorize_resource in my ApplicationController, or a lame hacked substitute Rake task for ActiveMigration... that'd be a distressingly accurate description of way too much of my career. Of course if you really are just building just the one microservice and don't have any complexity to manage, then yes, Sinatra all the way, 100%.
wh-uws 11y ago
Every bit of that "magic" is either meta programming or a dsl. A large part of both rails and ruby is very well documented to the point where you can click on methods and see the code that makes them work. When that fails you can debug with pry. This stuff is not magic. Its not havening to reinvent the wheel poorly again and again. The strongest sign someone hasnt spent much time building even a trivial app in ruby with rails is complaints of magic. The magic straight forword once you see there is just code that generates methods (meta programming) ...
- cgag 11y ago
  It wasn't until after spending non-trivial amounts of time building a non-trivial app in rails that I realized I hated the magic. It's not like I don't know that "magic" is metaprogramming and DSLs. I hate the metaprogramming and DSLs.
  - mmanfrin 11y ago
    It wasn't until after spending non-trivial amounts of time building a non-trivial app in rails that I realized I hated the magic. And it wasn't until after spending a non-trivial amount of time building many non-trivial apps in rails that I realized I sincerely appreciate the legwork that Rails saves me from doing. And having worked with rails for a non-trivial amount of time, nearly all of the 'magic' has been dispelled and replaced by an understanding of what Rails does and why. Giving me metaprogrammed finder methods or metaprogrammed getters and setters is wonderful. Maybe you don't like it, but I do, and this is a matter of opinions so the fact that it metaprograms is not a point of critique against the framework. Telling us you hate metaprogramming does nothing beyond riling up more of a bickerwar.
    - hueving 11y ago
      >Maybe you don't like it, but I do, and this is a matter of opinions so the fact that it metaprograms is not a point of critique against the framework. Almost every 'critique' of a language is because people don't like the features used/not-used. It's like saying that the syntax is not a valid critique of brainfuck because you like it.
tomphoolery 11y ago
Words written in a language you don't understand are always hard to read.
jimbokun 11y ago
I think your response shows why this is a great document. It's something any programmer can read and quickly determine whether or not Rails is right for them.
erikpukinskis 11y ago
This is I think the biggest reason Rails has remained a pro development tool and has failed to usurp PHP in the beginner realm. Rails took me about a year of full time work before I could reliably fix bugs in a 1-day timeframe. Before that there were frequent unpredictable week-long goose chases through the Rails stack... usually just to learn I was Doing It Wrong and there was some convention you just really can't break without everything falling apart. I had the same experience with Ember.js, another convention-over-configuration framework. A year of full time development before I could bang stuff out without being afraid I'd get totally lost and have a feature balloon up from two days to a month. And this is with a computer science degree and 10 years of web development experience. Once you get past that first year, it's great. Or, if you're on a team of people, you just get help. I taught RailsBridge a few times, and it's kind of crazy how many concepts you have to teach someone just to get to the point of a simple web form on Rails. It's probably at least 100 totally disconnected ideas, from routers to HTML to templating engines to MVC. We're just not doing a good job paving a path from PHP's functional, minimalist, "copy/paste this snippet of code into your template" architecture to things like Rails/Ember which provide ergonomic toolkits for modern apps.
- wh-uws 11y ago
  You are so right and it breaks my heart every time I think about it. I just don't know what could really bridge that gap. So many terrible php and <insert language you like to make fun of> codebases come from exactly > "copy/paste this snippet of code into your template" programming. Which is how most beginners learn (myself included. cobbling together myspace and wordpress templates) and it takes a while before you've done enough of it to see how deep the holes you dig with it can be but in the mean time your stuff "works" but is a nightmare to maintain and understand long term. I had a lot of hope for the node community (because at least then newbies only have to learn the quirks of one scripting language) solving this with express/ sails or something else but they've stalled. I guess its just a hard problem. No idea how to solve it
  - enraged_camel 11y ago
    >>Which is how most beginners learn (myself included. cobbling together myspace and wordpress templates) That right there is the problem: too many people are after quick wins and instant gratification and aren't willing to make an effort to learn something the proper way and appreciate its complexity, even if they are not exposed to it directly. I learned Rails via the Rails Tutorial[1], and finished it in three weeks of evening and weekend sessions. When I started, I knew a little JavaScript, but not much else. By the end of the tutorial, I had a fully functioning app (parts of it I had customized, even!) and was ready to start building my own stuff. It was very empowering and I was blown away by how incredibly smooth and easy the Rails framework was. That said, if I had taken the approach that lazy PHP beginners take and tried to learn by copy/pasting stuff (or relied on Rails scaffolds from the get-go), I would have stumbled over and over and probably given up. [1]https://www.railstutorial.org/book https://www.railstutorial.org/book edit: not sure why people are downvoting -- did I say something controversial?
jpulec 11y ago
Couldn't help but think the same thing as I read this.

by sauere 11y ago

shockzzz 11y ago

Yeah, I go back and forth. I find Ruby aesthetically pleasing, but, in a way, harder to understand. Python represents a lot of "truth" for me. I would definitely say, though, that I find Ruby development to be amazing. And I find debugging in Python to be similarly awesome.

jessewmc 11y ago
What do you use for Python debugging? I'm working on a large Python project coming from rails work and my biggest frustration is no equivalent to pry. I find Python debugging incredibly painful by comparison.
- reinhardt 11y ago
  Not a ruby dev so don't know how they compare to pry but I've been a happy heavy user of ipdb [1] and pdbpp [2]. [1] https://pypi.python.org/pypi/ipdb https://pypi.python.org/pypi/ipdb [2] https://pypi.python.org/pypi/pdbpp https://pypi.python.org/pypi/pdbpp
- jsmeaton 11y ago
  pdb and pudb seem to be reasonably popular. I use pdb myself. I haven't used pry, so I'm not sure about equivalences.
- heroprotagonist 11y ago
  PyCharm's debug tools are top notch. It's based on PyDev, which is an alternative that can be used independently in other IDE, but it's really the integration with the IDE that makes it a much better alternative than using, say, PyDev in Eclipse or vim. Here's a brief overview of PyCharm debugging functionality: http://pedrokroger.net/python-debugger/ http://pedrokroger.net/python-debugger/ I really like the ease of use for remote debugging. It's essential in helping to maintain a Linux development environment that closely resembles production while actually coding on a work laptop that runs Windows. Beyond that, I often use the remote functionality to run one-off scripts to retrieve and process data from a production Django system (though, generally this is restricted to 'read' operations unless it's been tested in dev).
- antod 11y ago
  In terms of web debugging instead of general code debugging tools mentioned by others, the common Python frameworks have toolbars based on Armin's Werkzeug one: http://werkzeug.pocoo.org/docs/dev/debug/ http://werkzeug.pocoo.org/docs/dev/debug/ eg... For Pyramid: http://docs.pylonsproject.org/projects/pyramid-debugtoolbar/en/latest/ http://docs.pylonsproject.org/projects/pyramid-debugtoolbar/... For Flask: http://flask-debugtoolbar.readthedocs.org/en/latest/ http://flask-debugtoolbar.readthedocs.org/en/latest/ For Django: https://github.com/django-debug-toolbar/django-debug-toolbar https://github.com/django-debug-toolbar/django-debug-toolbar I have no idea how well they compare to equivalent Rails tools though.

glossyscr 11y ago

> Too much magic happening everywhere, a gazillion of built-in methods, weird shit happening all over the place Couldn't agree more on this. Magic is good if you understand the underlying stuff but if you don't and you are once offtrack you are lost. Maybe it's also a matter of taste. However the hype and traction DHH could build when RoR started was quite impressive.

jshen 11y ago
I think this is wrong. Nearly all of us build on top of things we don't understand. I don't understand the physics of a harddisk, or the pipelining of a CPU, or some of the low level OS functionality. The issue is when do each of us, as individuals and/or teams, really need to understand more. And perhaps more importantly, when does it make business sense to leverage magic to get to market faster, build cheaper, or find market fit before worrying about building the most robust thing possible.
- deleted 11y ago
  [deleted]
  - random_rr 11y ago
    That's a pretty crazy claim. So, do you build your own interrupt gates, and take those into account when you're writing PHP? How about electrons? Can you draw me a graph of the electrons currently residing in your computer case/laptop? Can you explain to me exactly how your PHP code will look in binary? Sorry to be snippy, but you're making a pretty audacious claim there. I don't think any reasonable software engineer/developer can claim to fully understand every underlying principle. I mean, you can have an abstract, high-level idea of how things work, but do you really think you know the intimate details of every single piece of hardware/software involved in writing your code?
    - jacquesm 11y ago
      Making a specific claim about this is nonsense but making a claim about this in principle is perfectly valid. it's the difference between being able to wire up a logic gate from transistors with a basic understanding of how they work and to be able to wire up a cpu, ram and some io from logic gates, being able to wire up a computer from cpu chips, ram chips and IO chips. Even if you don't know the exact details of the latter in principle you understand that whole device that you just built. So the claim is not so crazy as it might sound initially.

hoorayimhelping 11y ago

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.

minimaxir 11y ago
It's perfectly fair to compare competing products in an apples-to-apples comparison.
afarrell 11y ago
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.
tolmasky 11y ago
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 11y ago
  How was it a critique? He just said he didn't like it, and exaggerated a few things.
  - tolmasky 11y ago
    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".

tclancy 11y ago

This was my reaction as well. "The menu is omakase" clearly violates "explicit is better than implicit".

aantix 11y ago
Why throw out some catch phrase without providing specifics? We all adopt certain amount of implicit choices in our lives because if we had to be explicit about everything, we'd be bogged down in choice-making and not really get anything done. Why care about choosing the right ORM, Logger, templating engine when there's real business problems to solve? If there's a true business advantage to choosing an alternative, then substitute, but eventually you have to get on with the show and make something meaningful. Strong defaults and conventions are a feature and Rails nails it better than any other framework out there.

lectrick 11y ago

Similarly, Python turned me off immediately when I tried to exit the REPL with "exit" and it goes "The way you exit is with control-D." It fucking knew I wanted to exit, and instead lectured me. WTF, Python? Seeya, dick.

talideon 11y ago
That's because there's no magic in the REPL. You're typing nothing but regular Python code. 'exit' is an object. Expressions typed at the REPL are stringified. Thus, when you type 'exit', it gets stringified, and thus you get that message. 'exit' is also a callable, so if you type 'exit()', the REPL will exit. The same goes for 'help', 'copyright', 'credits', and 'license': they're just objects that get stringified. Having the REPL work the way you want would mean building magic into it, and magic avoidance is part of the language's culture, so that's not going to happen. Having it print that message is a compromise between keeping things friendly and building magic into the REPL, if you consider printing the result of expressions automatically to be magic. The Python REPL isn't being a dick, it's being parsimonious and predictable in its behaviour.
- NoGravitas 11y ago
  I wrote nearly the exact same explanation minutes after yours, but I've deleted mine because yours is clearer.
- bphogan 11y ago
  Yet the code behind the REPL knows exactly what I was attempting to do and tells me that. This is what Ruby developers mean when they say they optimize for developer happiness over bowing to the will of the computer. /uses Python regularly and enjoys it.
  - sanderjd 11y ago
    > Yet the code behind the REPL knows exactly what I was attempting to do and tells me that. Not really – all the code knows is to stringify objects, and it saw the object called `exit`, for which the stringified version is that error message. But nowhere in that flow does the code know how call anything that could exit the REPL. /doesn't use Python regularly and thinks the smart move would be to make the REPL understand certain things as commands instead of normal Python code.

aivosha 11y ago

Funny you should mention Django, because its the magic framework in python land that does all those things you label Rails doing and it does it way way worse than Rails.

batiste 11y ago
Care to develop what he labeled and how Django is making does it worse than Rails? I have a hard time to see it knowing both Frameworks.
acdha 11y ago
That might plausibly have been true in the past, at least if you hadn't heard of Zope/Plone, but Django has been moving away from that for close to a decade: https://www.djangoproject.com/weblog/2006/may/01/magicremoval/ https://www.djangoproject.com/weblog/2006/may/01/magicremova... By now, it's hard to tell what you had in mind – something like contrib.admin or the global settings file?
jsmeaton 11y ago
The only real magic left in Django is the metaclasses that ORM models use to turn class based fields into instance level descriptors. class Model(models.Model): field = models.SomeField() rather than.. class Model(models.Model): def __init__(self, *args, **kwargs): field = models.SomeField() super(*args, **kwargs) Django is most certainly the framework that bundles a whole lot of choices together (similar to Rails), but the magic it performs on behalf of the user is extremely minimal.

JohnBooty 11y ago

I'm a Rails developer and I'm coming to feel this way as well. I agree with most of what's in the Rails Manifesto except the convention-over-configuration thing. Too much "magic" happening. Magic's cool, but I need to know why a certain thing works or why it doesn't work. Rails is the only environment in which I've routinely found myself utterly stumped. Not because it's hard, because it isn't. But the thick layer of "magic" makes it awfully hard to debug sometimes.

jmagoon 11y ago
We are in the same boat. I find myself relying way more on pure ruby classes. It's also dangerous because Rails fits a specific niche, like he mentions--building (potentially) many web systems quickly. We chose to migrate large legacy systems to rails, which meant lots of the nice convention just. doesn't. work. Day 1, you're already digging in to figure out how to get around the magic!
ansonhoyt 11y ago
For me, magic isn't the problem. I like the magic of conventions, but not when it is painful to pull back the curtain. For Rails, I think pain comes when magic stands on poor internals, which gets amplified when gems layer on their own painful workarounds...and I have to sort through all of it. That's why I'm excited about Sean Griffin's work on the [Attributes API](http://edgeapi.rubyonrails.org/classes/ActiveRecord/Attributes/ClassMethods.html http://edgeapi.rubyonrails.org/classes/ActiveRecord/Attribut...). To do it, he's had to refactor out a lot of internal monkey patching so that (in Rails 5) there is only one source of type information for an AR model. This means gems can extend AR, I can extend AR, new requirements can walk into my door that I can deliver on without monkey patching or opening Pandora's box of a patch of crappy Rails internals. The magic is still there, but it's done it a way so the magic doesn't fall apart in unexpected, unmanageable ways. That's what matters to me.

krstck 11y ago

As I've entered the more intermediate stage as a Rails developer, I've noticed that the "magicalness" that allowed me to do so much so quickly as a beginner, is often actually getting in my way. Perhaps when I reach the "advanced" stages, I'll learn to love the magic again, but I'm in this awkward stage of knowing what I want to do but not knowing how to tell Rails to do it (or stop doing it, as the case may be).

hardwaresofton 11y ago

Everyone that feels this way please give Sinatra (http://www.sinatrarb.com/intro.html http://www.sinatrarb.com/intro.html) a try Complexity/perceived burdenwise, I think java is to rails as rails is to sinatra (or a similiarly small framework). There may be a point where you want your functionality bundled and presented as a framework (if you, like me, think of frameworks as bundled and groomed libraries/functionality), but if you're not sure you're at that point (or don't know what that point is), try to start smaller (like sinatra) and go bigger, rather than the other way around (starting with the biggest tool you could find, trying to find the smallest). I strive not to become a good developer on X platform (for Y language) but rather just a good developer who's proficient with Y language (and happens to be able to use X lib).

supergeek133 11y ago
Seconded. I started on Rails and said to myself "this is doing too much on it's own, there is WAY too much going on". Then I started using and looking into Sinatra, and it's way more basic and Ruby instead of Magic.
- fennecfoxen 11y ago
  Sinatra is all well and good until you have an application complex enough that you want to start applying some interesting methods of code reuse across several routes, and want to share several facets of, say, object loading and authorization, or something around page rendering. At that point you run into the fact that all your tools for manipulating the request and response are built into a singleton object (your instance of Sinatra::Base) which begins to inhibit several very useful forms of code reuse (such as most OO inheritance schemes, for a start). If I had a dollar for every minute I wasted rewriting things that I could have for nearly-free with (for example) Rails and CanCan and a quick call to load_and_authorize_resource in my ApplicationController, or a lame hacked substitute Rake task for ActiveMigration... that'd be a distressingly accurate description of way too much of my career. Of course if you really are just building just the one microservice and don't have any complexity to manage, then yes, Sinatra all the way, 100%.

wh-uws 11y ago

Every bit of that "magic" is either meta programming or a dsl. A large part of both rails and ruby is very well documented to the point where you can click on methods and see the code that makes them work. When that fails you can debug with pry. This stuff is not magic. Its not havening to reinvent the wheel poorly again and again. The strongest sign someone hasnt spent much time building even a trivial app in ruby with rails is complaints of magic. The magic straight forword once you see there is just code that generates methods (meta programming) ...

cgag 11y ago
It wasn't until after spending non-trivial amounts of time building a non-trivial app in rails that I realized I hated the magic. It's not like I don't know that "magic" is metaprogramming and DSLs. I hate the metaprogramming and DSLs.
- mmanfrin 11y ago
  It wasn't until after spending non-trivial amounts of time building a non-trivial app in rails that I realized I hated the magic. And it wasn't until after spending a non-trivial amount of time building many non-trivial apps in rails that I realized I sincerely appreciate the legwork that Rails saves me from doing. And having worked with rails for a non-trivial amount of time, nearly all of the 'magic' has been dispelled and replaced by an understanding of what Rails does and why. Giving me metaprogrammed finder methods or metaprogrammed getters and setters is wonderful. Maybe you don't like it, but I do, and this is a matter of opinions so the fact that it metaprograms is not a point of critique against the framework. Telling us you hate metaprogramming does nothing beyond riling up more of a bickerwar.
  - hueving 11y ago
    >Maybe you don't like it, but I do, and this is a matter of opinions so the fact that it metaprograms is not a point of critique against the framework. Almost every 'critique' of a language is because people don't like the features used/not-used. It's like saying that the syntax is not a valid critique of brainfuck because you like it.

tomphoolery 11y ago

Words written in a language you don't understand are always hard to read.

jimbokun 11y ago

I think your response shows why this is a great document. It's something any programmer can read and quickly determine whether or not Rails is right for them.

erikpukinskis 11y ago

This is I think the biggest reason Rails has remained a pro development tool and has failed to usurp PHP in the beginner realm. Rails took me about a year of full time work before I could reliably fix bugs in a 1-day timeframe. Before that there were frequent unpredictable week-long goose chases through the Rails stack... usually just to learn I was Doing It Wrong and there was some convention you just really can't break without everything falling apart. I had the same experience with Ember.js, another convention-over-configuration framework. A year of full time development before I could bang stuff out without being afraid I'd get totally lost and have a feature balloon up from two days to a month. And this is with a computer science degree and 10 years of web development experience. Once you get past that first year, it's great. Or, if you're on a team of people, you just get help. I taught RailsBridge a few times, and it's kind of crazy how many concepts you have to teach someone just to get to the point of a simple web form on Rails. It's probably at least 100 totally disconnected ideas, from routers to HTML to templating engines to MVC. We're just not doing a good job paving a path from PHP's functional, minimalist, "copy/paste this snippet of code into your template" architecture to things like Rails/Ember which provide ergonomic toolkits for modern apps.

wh-uws 11y ago
You are so right and it breaks my heart every time I think about it. I just don't know what could really bridge that gap. So many terrible php and <insert language you like to make fun of> codebases come from exactly > "copy/paste this snippet of code into your template" programming. Which is how most beginners learn (myself included. cobbling together myspace and wordpress templates) and it takes a while before you've done enough of it to see how deep the holes you dig with it can be but in the mean time your stuff "works" but is a nightmare to maintain and understand long term. I had a lot of hope for the node community (because at least then newbies only have to learn the quirks of one scripting language) solving this with express/ sails or something else but they've stalled. I guess its just a hard problem. No idea how to solve it
- enraged_camel 11y ago
  >>Which is how most beginners learn (myself included. cobbling together myspace and wordpress templates) That right there is the problem: too many people are after quick wins and instant gratification and aren't willing to make an effort to learn something the proper way and appreciate its complexity, even if they are not exposed to it directly. I learned Rails via the Rails Tutorial[1], and finished it in three weeks of evening and weekend sessions. When I started, I knew a little JavaScript, but not much else. By the end of the tutorial, I had a fully functioning app (parts of it I had customized, even!) and was ready to start building my own stuff. It was very empowering and I was blown away by how incredibly smooth and easy the Rails framework was. That said, if I had taken the approach that lazy PHP beginners take and tried to learn by copy/pasting stuff (or relied on Rails scaffolds from the get-go), I would have stumbled over and over and probably given up. [1]https://www.railstutorial.org/book https://www.railstutorial.org/book edit: not sure why people are downvoting -- did I say something controversial?

jpulec 11y ago

Couldn't help but think the same thing as I read this.