16 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.

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.
        jshen 11y ago
        What is the claim exactly? Ruby/Rails is bad because ... too much magic. I think this is a false claim because. 1. Rails is easier to learn than most of the things mentioned above, so not magic 2. It's perfectly reasonable, and good, to build on top of and leverage things that you haven't taken the time to learn intimately.
        jacquesm 11y ago
        > What is the claim exactly? Ruby/Rails is bad because ... too much magic. No, that wasn't the claim. > 1. Rails is easier to learn than most of the things mentioned above, so not magic Ignoring the strawman component: that's a matter of opinion, for some those electronic bits and pieces are actually simpler to understand than software. > 2. It's perfectly reasonable, and good, to build on top of and leverage things that you haven't taken the time to learn intimately. Yes, absolutely. Just like we don't require everybody that uses the highways to be car mechanics or road construction workers. Society would grind to a very rapid halt if we had to have an intimate understanding of everything we use everyday.
    - tonyarkles 11y ago
      I'm with you on this; I can't reply to the sibling comment, but I'll elaborate on what this means in my own professional practice. I did a dual-major in CS and EE, and then an MSc in CS. While I'm a little fuzzy on the specific details of the current transistor geometries (14nm?! that's wild!), I do pretty much understand the entire stack upwards from there. I could design a fully-functional computer from the logic gate level, although it likely would be slow as hell and be exceptionally boring. It's not my strong point, but I understand enough about what's going on. Honestly, most of my electronic design work these days is analog circuits slung onto the side of a microcontroller, with code written in C. I'll do schematic design and capture, and board layout without too much difficulty. Going up from there, I've written my own (toy) operating system from scratch. I've written Linux kernel drivers for both off-the-shelf devices and for custom devices implemented in FPGAs. High-bandwidth/low-latency TCP servers written in C. My own (toy) programming language. I've written C extensions for PHP and Python, and have done pretty intense profiling work on them; this requires a pretty deep understanding of how the internals of the interpreter work (part of my MSc coursework). And I've done web apps in PHP, Python, Ruby, and Elixir. The whole point of this is that I'm totally comfortable going as deep into the stack of abstractions as necessary to solve whatever problem I'm facing. When I started learning Rails, I was mystified by all of the "magic". I'd never even really used Ruby, let alone all the extra stuff Rails does. But I set up the emacs-bundler library (https://github.com/tobiassvn/bundler.el https://github.com/tobiassvn/bundler.el) and started diving in. I'd work through a tutorial, and every time I encountered something I didn't understand, I'd dive into the guts of Rails (bundle-open activerecord) and read the code until I understood it. As an example of going a layer deeper, I once encountered a bug in a Python script that used PySerial. There were multiple threads, and the script would hang sometimes. I read through my code and couldn't find any problems, so I dug deeper into the PySerial code. Nothing obvious in the .py file for PySerial, so I dug deeper into the C extension. In the C code, I discovered that there was one case where the GIL wasn't being properly released before doing a (sometimes) blocking call! Tada! The script worked great if the call didn't block, but hung if it did.
      - sanderjd 11y ago
        I think there's a subtle difference between what your parent said and what you're saying: they suggested that they know what's going on at every level, and you merely claim that you can figure out what's going on, if need be. (A charitable reading would be that they meant the same thing though.) I think we should all aspire to this level of having enough of a mental model for all the layers underneath us that we can go dig into them when needed. But it takes a lot of effort to get to the point you're at, so it's a pretty big ask. (Also, most of us probably can't go back to a university to learn the EE side, and it's not easy to self-learn it.) Having said all that, for Rails specifically, it's pretty easy to do exactly what you did and just open up Rails and other library code. It's almost entirely simple method definitions, and the parts that aren't can be understood if you go read about how `define_method`, `method_missing`, and `const_get` work. The "Rails is magic" meme seems to either scare people off from reading the code, or give people permission to be lazy about it.
  - Eridrus 11y ago
    > I don't understand the physics of a harddisk, or the pipelining of a CPU, or some of the low level OS functionality. I think the key difference is that you don't need to know how that works. I think there's a question of how leaky the abstraction is and how often you need to look behind the curtain.
    - goldbrick 11y ago
      Tons of people and use cases never need to delve into the implementation to get a lot of mileage out of Rails. I get a lot of work as a Rails consultant and most of the real pain I see is caused by people doing stuff like implementing their own ORM with an ActiveRecord-ish interface, or writing their own caching logic implemented as a mixin for ActiveRecord.
  - zaphar 11y ago
    I think this concern gets lost in translation sometimes. It's not that you need to understand everything but you do need to know that there is a layer underneath. And it needs to be possible to follow a trail to and through that layer to debug things. Most of the time I don't need to understand the physics of a harddisk. But I know a hard disk operates under certain pysical laws. When I encounter something happening wrong it has on occasion been useful to be able to follow the trail all the way down to that disk and debug at that level. Ruby's freewheeling philosophy however means that even when you are the author of the code some other code might have reached in and changed something out from under you. Not only do you not know there is another layer somewhere doing stuff that impacts you you can't even reliably follow a path to find that layer and debug it. As long as everyone does everything perfectly this is a wonderful world to live in. But the first time someone breaks the rules and impacts you and you lose a week or more unnecessarily you'll understand the distaste that ruby fosters in some people. It's more about being able to discover what you need to know that it is possessing full knowledge of everything you need to know.
    - mhink 11y ago
      > Most of the time I don't need to understand the physics of a harddisk. But I know a hard disk operates under certain physical laws. When I encounter something happening wrong it has on occasion been useful to be able to follow the trail all the way down to that disk and debug at that level. I'm not entirely sure how a filesystem works under the hood (let alone the physical media it's on), despite interacting heavily with one every day. A bug involving a hard disk would be incredibly opaque to debug, from my perspective. I suspect that you find it easy, because you've spent the time developing an understanding of the system. > Not only do you not know there is another layer somewhere doing stuff that impacts you you can't even reliably follow a path to find that layer and debug it. And this is where our roles are reversed! I would have little trouble following that path, all the way down into C if needed- because I've spent plenty of time understanding the system. The problems you describe are problems anyone would have with an unfamiliar system, and it's not Ruby's fault.
      - bpchaps 11y ago
  - jldugger 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. There's probably a SE paper somewhere stating this formally, but I figure well done implementations on top of abstractions only need to reference one layer down. It might be okay to inspect the state the layer below for performance reasons, but no further. That means that a well done Rails app might want to inquire about the state of HTTP, but shouldn't inquire about IP addresses. And it might want to know about indexes on its databases, but not disk caching policies or i/o schedulers. So the case of "too much magic" is not to become used to the discomfort of not understanding how underlying abstractions work, nor is it to stop using them. Instead you want to choose dependencies with well documented abstractions, implemented such that you can inspect if you need to. This has nothing to do with Rails specifically. I see plenty of coworkers who dislike Django's large set of features, as too much bloat, or too much magic they don't understand. Instead of reading documentation, and becoming expert in Django's abstractions, they spin up Flask apps, slowly reinventing the wheels, but maybe not quite as round.
  - pbreit 11y ago
    There's a huge difference between lack of understanding being irrelevant (hard drive) and lack of understanding being a blocker (framework).
    - hueving 11y ago
      So you're saying that you have to understand all of the magic rails does before it should be adopted for anything?
      - pbreit 11y ago
        No. For example, on rails if I make a typo creating a table, I delete my whole project and start over from scratch. I have not been able to figure out how to edit the name of field. That's an impediment.
        prophetjohn 11y ago
        A very quick Google search for "rails rename column" will show that there's a method called "rename_column" You can even search for "rails typo in migration" and the first result is a stack overflow post suggesting and explaining how to roll back the migration so you can edit it
        pbreit 11y ago
        I did a lot of Googling and tried a few things and still seemed to find it easier to start over.
        amalag 11y ago
        I can see a lot of faults in Rails, but this critcism is silly. The documentation is excellent at that level. http://edgeguides.rubyonrails.org/active_record_migrations.html http://edgeguides.rubyonrails.org/active_record_migrations.h...
        testerbot 11y ago
  - hvidgaard 11y ago
    Sort of, but I'd rephrase it. I don't need to understand how a harddrive or SSD actually works, I just need a consistent and well documented abstraction.
    - spoiler 11y ago
      But Rails (and Ruby) do offer that. I agree that there's a lot of it, but it is there. Its abstractions are consistent, and Rails is generally well documented.
      - hvidgaard 11y ago
        I don't know Rails enough to really comment on that, but if it takes 1 years to learn it all, I'd say it fails my definition of concise and comprehensible. It should fit in a single volume book that I can read in the evening over the course of a week. That said, I don't have a problem with frameworks that are larger. Hell, I'm a .Net dev by day myself and that certainly doesn't meet that requirement. I just don't find it elegant.
- mmanfrin 11y ago
  You understand the underlying stuff after working with rails -- the complaint of Magic comes from (I believe) the fact that Rails is very easy to approach compared to other languages, so many people are able to create a lot with comparatively less understanding of the framework, so when things work or break, they are less likely to know the root cause/reason and blame it on 'magic'.
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".
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).
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.
    - true_religion 11y ago
      Yet isn't the time saved by using Rails, the same thing that every other framework offers---without using large amounts of meta-programming? I mean I like Django. I think its saves me a lot of time. I love the ecosystem, that lets me pick up someone else's apps and use it directly or use it as template to write my own. Django makes different choices when it comes to what level of metaprogramming to afford, and how to display that to the user. Now when I first started with MVC on the web (I'd known about it via Smalltalk, but it has a whole different feel there), I used Symfony PHP with its scaffolding and at then point active-record style generators. I liked it, and it helped me understand the core of MVC. After that, I became opinionated and as my opinions didn't align with that of Symfony or Rails, I chose Python and Django. It was a breath of fresh air because when everything is explicitly defined, it becomes imminently simple to swap out and rewrite things for your given use case. In fact, the only thing that's pretty difficult to change in Django is the request/response cycle since that's too deeply backed into all the middleware and top level binding to the server.
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

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.
      - jshen 11y ago
        What is the claim exactly? Ruby/Rails is bad because ... too much magic. I think this is a false claim because. 1. Rails is easier to learn than most of the things mentioned above, so not magic 2. It's perfectly reasonable, and good, to build on top of and leverage things that you haven't taken the time to learn intimately.
        jacquesm 11y ago
        > What is the claim exactly? Ruby/Rails is bad because ... too much magic. No, that wasn't the claim. > 1. Rails is easier to learn than most of the things mentioned above, so not magic Ignoring the strawman component: that's a matter of opinion, for some those electronic bits and pieces are actually simpler to understand than software. > 2. It's perfectly reasonable, and good, to build on top of and leverage things that you haven't taken the time to learn intimately. Yes, absolutely. Just like we don't require everybody that uses the highways to be car mechanics or road construction workers. Society would grind to a very rapid halt if we had to have an intimate understanding of everything we use everyday.
  - tonyarkles 11y ago
    I'm with you on this; I can't reply to the sibling comment, but I'll elaborate on what this means in my own professional practice. I did a dual-major in CS and EE, and then an MSc in CS. While I'm a little fuzzy on the specific details of the current transistor geometries (14nm?! that's wild!), I do pretty much understand the entire stack upwards from there. I could design a fully-functional computer from the logic gate level, although it likely would be slow as hell and be exceptionally boring. It's not my strong point, but I understand enough about what's going on. Honestly, most of my electronic design work these days is analog circuits slung onto the side of a microcontroller, with code written in C. I'll do schematic design and capture, and board layout without too much difficulty. Going up from there, I've written my own (toy) operating system from scratch. I've written Linux kernel drivers for both off-the-shelf devices and for custom devices implemented in FPGAs. High-bandwidth/low-latency TCP servers written in C. My own (toy) programming language. I've written C extensions for PHP and Python, and have done pretty intense profiling work on them; this requires a pretty deep understanding of how the internals of the interpreter work (part of my MSc coursework). And I've done web apps in PHP, Python, Ruby, and Elixir. The whole point of this is that I'm totally comfortable going as deep into the stack of abstractions as necessary to solve whatever problem I'm facing. When I started learning Rails, I was mystified by all of the "magic". I'd never even really used Ruby, let alone all the extra stuff Rails does. But I set up the emacs-bundler library (https://github.com/tobiassvn/bundler.el https://github.com/tobiassvn/bundler.el) and started diving in. I'd work through a tutorial, and every time I encountered something I didn't understand, I'd dive into the guts of Rails (bundle-open activerecord) and read the code until I understood it. As an example of going a layer deeper, I once encountered a bug in a Python script that used PySerial. There were multiple threads, and the script would hang sometimes. I read through my code and couldn't find any problems, so I dug deeper into the PySerial code. Nothing obvious in the .py file for PySerial, so I dug deeper into the C extension. In the C code, I discovered that there was one case where the GIL wasn't being properly released before doing a (sometimes) blocking call! Tada! The script worked great if the call didn't block, but hung if it did.
    - sanderjd 11y ago
      I think there's a subtle difference between what your parent said and what you're saying: they suggested that they know what's going on at every level, and you merely claim that you can figure out what's going on, if need be. (A charitable reading would be that they meant the same thing though.) I think we should all aspire to this level of having enough of a mental model for all the layers underneath us that we can go dig into them when needed. But it takes a lot of effort to get to the point you're at, so it's a pretty big ask. (Also, most of us probably can't go back to a university to learn the EE side, and it's not easy to self-learn it.) Having said all that, for Rails specifically, it's pretty easy to do exactly what you did and just open up Rails and other library code. It's almost entirely simple method definitions, and the parts that aren't can be understood if you go read about how `define_method`, `method_missing`, and `const_get` work. The "Rails is magic" meme seems to either scare people off from reading the code, or give people permission to be lazy about it.
- Eridrus 11y ago
  > I don't understand the physics of a harddisk, or the pipelining of a CPU, or some of the low level OS functionality. I think the key difference is that you don't need to know how that works. I think there's a question of how leaky the abstraction is and how often you need to look behind the curtain.
  - goldbrick 11y ago
    Tons of people and use cases never need to delve into the implementation to get a lot of mileage out of Rails. I get a lot of work as a Rails consultant and most of the real pain I see is caused by people doing stuff like implementing their own ORM with an ActiveRecord-ish interface, or writing their own caching logic implemented as a mixin for ActiveRecord.
- zaphar 11y ago
  I think this concern gets lost in translation sometimes. It's not that you need to understand everything but you do need to know that there is a layer underneath. And it needs to be possible to follow a trail to and through that layer to debug things. Most of the time I don't need to understand the physics of a harddisk. But I know a hard disk operates under certain pysical laws. When I encounter something happening wrong it has on occasion been useful to be able to follow the trail all the way down to that disk and debug at that level. Ruby's freewheeling philosophy however means that even when you are the author of the code some other code might have reached in and changed something out from under you. Not only do you not know there is another layer somewhere doing stuff that impacts you you can't even reliably follow a path to find that layer and debug it. As long as everyone does everything perfectly this is a wonderful world to live in. But the first time someone breaks the rules and impacts you and you lose a week or more unnecessarily you'll understand the distaste that ruby fosters in some people. It's more about being able to discover what you need to know that it is possessing full knowledge of everything you need to know.
  - mhink 11y ago
    > Most of the time I don't need to understand the physics of a harddisk. But I know a hard disk operates under certain physical laws. When I encounter something happening wrong it has on occasion been useful to be able to follow the trail all the way down to that disk and debug at that level. I'm not entirely sure how a filesystem works under the hood (let alone the physical media it's on), despite interacting heavily with one every day. A bug involving a hard disk would be incredibly opaque to debug, from my perspective. I suspect that you find it easy, because you've spent the time developing an understanding of the system. > Not only do you not know there is another layer somewhere doing stuff that impacts you you can't even reliably follow a path to find that layer and debug it. And this is where our roles are reversed! I would have little trouble following that path, all the way down into C if needed- because I've spent plenty of time understanding the system. The problems you describe are problems anyone would have with an unfamiliar system, and it's not Ruby's fault.
    - bpchaps 11y ago
- jldugger 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. There's probably a SE paper somewhere stating this formally, but I figure well done implementations on top of abstractions only need to reference one layer down. It might be okay to inspect the state the layer below for performance reasons, but no further. That means that a well done Rails app might want to inquire about the state of HTTP, but shouldn't inquire about IP addresses. And it might want to know about indexes on its databases, but not disk caching policies or i/o schedulers. So the case of "too much magic" is not to become used to the discomfort of not understanding how underlying abstractions work, nor is it to stop using them. Instead you want to choose dependencies with well documented abstractions, implemented such that you can inspect if you need to. This has nothing to do with Rails specifically. I see plenty of coworkers who dislike Django's large set of features, as too much bloat, or too much magic they don't understand. Instead of reading documentation, and becoming expert in Django's abstractions, they spin up Flask apps, slowly reinventing the wheels, but maybe not quite as round.
- pbreit 11y ago
  There's a huge difference between lack of understanding being irrelevant (hard drive) and lack of understanding being a blocker (framework).
  - hueving 11y ago
    So you're saying that you have to understand all of the magic rails does before it should be adopted for anything?
    - pbreit 11y ago
      No. For example, on rails if I make a typo creating a table, I delete my whole project and start over from scratch. I have not been able to figure out how to edit the name of field. That's an impediment.
      - prophetjohn 11y ago
        A very quick Google search for "rails rename column" will show that there's a method called "rename_column" You can even search for "rails typo in migration" and the first result is a stack overflow post suggesting and explaining how to roll back the migration so you can edit it
        pbreit 11y ago
        I did a lot of Googling and tried a few things and still seemed to find it easier to start over.
        amalag 11y ago
        I can see a lot of faults in Rails, but this critcism is silly. The documentation is excellent at that level. http://edgeguides.rubyonrails.org/active_record_migrations.html http://edgeguides.rubyonrails.org/active_record_migrations.h...
        testerbot 11y ago
- hvidgaard 11y ago
  Sort of, but I'd rephrase it. I don't need to understand how a harddrive or SSD actually works, I just need a consistent and well documented abstraction.
  - spoiler 11y ago
    But Rails (and Ruby) do offer that. I agree that there's a lot of it, but it is there. Its abstractions are consistent, and Rails is generally well documented.
    - hvidgaard 11y ago
      I don't know Rails enough to really comment on that, but if it takes 1 years to learn it all, I'd say it fails my definition of concise and comprehensible. It should fit in a single volume book that I can read in the evening over the course of a week. That said, I don't have a problem with frameworks that are larger. Hell, I'm a .Net dev by day myself and that certainly doesn't meet that requirement. I just don't find it elegant.
mmanfrin 11y ago
You understand the underlying stuff after working with rails -- the complaint of Magic comes from (I believe) the fact that Rails is very easy to approach compared to other languages, so many people are able to create a lot with comparatively less understanding of the framework, so when things work or break, they are less likely to know the root cause/reason and blame it on 'magic'.

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".

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).

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.
  - true_religion 11y ago
    Yet isn't the time saved by using Rails, the same thing that every other framework offers---without using large amounts of meta-programming? I mean I like Django. I think its saves me a lot of time. I love the ecosystem, that lets me pick up someone else's apps and use it directly or use it as template to write my own. Django makes different choices when it comes to what level of metaprogramming to afford, and how to display that to the user. Now when I first started with MVC on the web (I'd known about it via Smalltalk, but it has a whole different feel there), I used Symfony PHP with its scaffolding and at then point active-record style generators. I liked it, and it helped me understand the core of MVC. After that, I became opinionated and as my opinions didn't align with that of Symfony or Rails, I chose Python and Django. It was a breath of fresh air because when everything is explicitly defined, it becomes imminently simple to swap out and rewrite things for your given use case. In fact, the only thing that's pretty difficult to change in Django is the request/response cycle since that's too deeply backed into all the middleware and top level binding to the server.

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.