Rails / Philosophy/opinion

From WhyNotWiki

Philosophy behind Rails, applicability of Rails, etc.

Contents 1 Code reuse 1.1 DHH on "Why engines and components are not evil but distracting" 2 Philosophy 3 It's not about the scaffolding! 4 Does it scale?

[edit] Code reuse

http://www.loudthinking.com/arc/000407.html The case against high-level components

One of the clear goals for Rails from the start was to stay at the infrastructure layer. I didn't want Rails to succumb to the lure of high-level components like login systems, forums, content management, and the likes.

...

On the surface, the dream of components sounds great and cursory overviews of new projects also appear to be "a perfect fit". But they never are. Reuse is hard. Parameterized reuse is even harder. And in the end, you're left with all the complexity of a swiss army knife that does everything for no one at great cost and pain.

http://article.gmane.org/gmane.comp.lang.ruby.rails/29166

Engines have not recieved the blessing of the RoR core team, and I

wouldn't expect any different, because it would be madness to include them in the core Rails. It's a mechanism far too easily [ab]used for things it's not actually suitable for. I did speak to Jamis (cc'd to DHH) about them quite some time ago, before plugins existed in a released form. Their advice was to reimplement our mechanism as a plugin, and if anything we were doing could not be achieved in this way, they would re-examine their plugin mechanism to see what could be adapted.

As it turns out, we can do everything we need within their plugins

architecture, so we have a happy coexistance - Rails stays clean, but is flexibly enough to support our (hopefully not too outlandish) needs. It's not like we're forking the project or taking digging our heels in and taking a stand against anything.

http://rails-engines.org/faq/oh-god-what-have-we-done/#extended

Engines aren’t any more evil than generators are or ever were. The LoginEngine doesn’t claim or try to be a one-solution-fits-all high-level component. If anything, it’s easier to hack than the old generators. And easier to replace when you want to drop the “login scaffolding” it provides for something more comprehensively tailored to your needs.

Engines are not evil. It’s possible to write inappropriate Engines in as much as it’s possible to write inappropriate generators, or inappropriate controllers, or inappropriate Rails applications. Engines are not high level components any more than generators are. Engines are plugins which include default views. Every part of an engine is simple to override.

[edit] DHH on "Why engines and components are not evil but distracting"

http://weblog.rubyonrails.com/2005/11/11/why-engines-and-components-are-not-evil-but-distracting

I’ve been following the enthusiasm for engines, components, and bigger plugins from the sidelines for a while now. It’s a subject of very mixed emotions. On the one hand, I’m really glad to see that people get so excited and start dreaming of bigger and better things. That’s passion in the works and its great.

On the other hand, I think these developments are basically another name for high-level components. And you all know how I feel about those. The short summary is that high-level components are a mirage: By the time they become interesting, their fitting will require more work than creating something from scratch.

But I start getting really high eyebrows when I hear of “engines that depend on other engines that can be swapped out with yet another engine”. Even plugin dependencies are dangerously close to something I would consider unfit for Rails. Simply because it encourages a style of development that I find unhealthy.

So this is not a slam against the technical merits or implementation of either engines or anything else in the same boat. It’s a concern that they will distract people, that they will appear as needed, and in turn, that they will take the debacle that was Salted Hash Login to a new standardized level.

Rails is all about making the simple things so easy that you need not abstract them. It’s about making the creation of logins, of access control, of content management, of all these business logic components so very easy that you will treasure the application-specific solutions of your own rather than long for The One True Login System.

So what am I saying? That engines should be stopped? Of course not. But I am saying that Rails will continue to send a signal with what’s included in the core that this is a sideshow project. It satisfies some needs for some people and that’s great. But the goal of Rails is to create a world where they are neither needed or strongly desired. Obviously, we are not quite there yet.

One way of getting there is to do a better job of educating new comers in common patterns. Answer the question “if engines and components are not the way, then show me how!”. So this is a call to all those experts out there. Help us spread the good patterns. Make videos, write tutorials, help newbies on #rubyonrails, answer requests on the mailing list.

And if you have a great idea for an engine, or a high-level component in general, think about this: Is there a way I could abstract a smaller slice of functionality as an independent plugin and then release that alongside a pattern that described how to use it like the component would have done all in software? More often than not, I think you could find this to be true.

I think it's worth re-stating this, because it is a very well-said statement about Rails' goals:

Rails is all about making the simple things so easy that you need not abstract them. It’s about making the creation of logins, of access control, of content management, of all these business logic components so very easy that you will treasure the application-specific solutions of your own rather than long for The One True Login System.

http://weblog.rubyonrails.com/2005/11/11/why-engines-and-components-are-not-evil-but-distracting Matt, 2005-11-11 13:10:

I just spent the last two days trying to integrate ModelSecurity (and the SaltedHash login system that comes bolted to it by default) into my application. I took me a good 6 hours just to figure out how the whole thing fit together. The rest of the time was spent trying to figure out how to divest it of the features I didn’t need or wanted to do differently (non-HTTP-AUTH logins, for one.)

http://weblog.rubyonrails.com/2005/11/11/why-engines-and-components-are-not-evil-but-distracting Gabe da Silveira, 2005-11-11 13:46:

This is a serious philosophical debate. I’m glad to hear David’s stance, because it encourages self-sufficiency / roll-your-own behaviour which is rarely encouraged amongst programmers. Why reinvent the wheel? Because you can get one that does exactly what you want and no more.

The pitfall is that most programmers will not be great programmers, especially as RoR moves into the mainstream. Of course standardized engines and frameworks will be necessary, but I’m glad to see that Rails will continue to be focused around core development processes and not providing a library of components.

http://weblog.rubyonrails.com/2005/11/11/why-engines-and-components-are-not-evil-but-distracting jankowski , 2005-11-11 15:22:

I get the same uneasy feeling when people start to talk about building generic CMS tools and photo galleries and groupware and whatnot on the mailing list. Sure, maybe those things are needed in places, but trying to build them in some abstract general-case ways only winds up providing a solution to some very non-specific problems that no one in particular has.

Much better to build a solution to YOUR problems, and then as you optimize and generalize w/in your application you can extract any bits that might be usable elsewhere and get them into either the rails distribution itself, or a plugin/engine/whathaveyou.

http://weblog.rubyonrails.com/2005/11/11/why-engines-and-components-are-not-evil-but-distracting Forrest, 2005-11-11 15:40:

I too needed a login system, saw the reference in the book to the Salted Hash stuff, and started figuring out how to incorporate it. . . about 3 hours later I flushed everything in frustration with an “svn revert”. After another 4 hours I had written the whole thing myself, complete with email verification, salts, forgotten password email messages, and the works-and it was exactly the way I wanted it. In other words: as David said, the mechanisms are already in Rails to make login systems easy (really easy) to do--so easy that it ended up taking less time to write it from scratch than it was going to take me just to learn to use someone else’s, and then coerce my application to work with their way of doing things—-and even then it wouldn’t have worked the way I really wanted it to.

The philosophy of providing the tools to make it easy to build high-level functions, rather than generic functional modules themselves, really does work.

http://weblog.rubyonrails.com/2005/11/11/why-engines-and-components-are-not-evil-but-distracting James Adam, 2005-11-11 23:28:

I think there’s a huge confusion here between ‘generic’ and ‘simple’. The login engine has never tried to be generic. It’s ridiculously simple, that’s all. It’s very opinionated, too. Almost none of its behaviour is dictated by configuration. Engines are only “plug `n’ play” as much as Generators are “script/generate `n’ play”.

...

“supposedly plug ‘n’ play solutions for everybody” – why does everyone think this? It’s no more true than saying the same thing about the SHLG, and who believes that? I’d encourage you to look at what ‘flexibility’ actually means in terms of engines. It’s not configuration, and it never has been.

http://weblog.rubyonrails.com/2005/11/11/why-engines-and-components-are-not-evil-but-distracting David Heinemeier Hansson, 2005-11-12 00:05:

What I’m arguing against is thinking that because you could make logins work generically for your own applications, that it’ll make a great fit for everyone else.

I’ve found that abstraction at an API level is successful for infrastructure-level pieces. Higher abstractions than that are called applications.

[edit] Philosophy

http://notrocketsurgery.com/articles/2006/06/24/getting-rails-backwards

What makes Rails special isn’t that it’s a thing for making websites more easily; that is just an ancillary side-effect of what makes Rails a truly stunning achievement. What so many people seem to be missing here at RailsConf is that the achievements of Rails ''aren’t primarily technical; they are aesthetic.

DHH rightly calls Rails opinionated software. DHH understands that the key to productivity as a programmer is happiness. Rails imposes well-thought-out conventions in order to create a framework that is simple and that results in beautiful code and elegant solutions.

Using Rails is joyful precisely because the core team has had the restraint to say no by default. The core team have maintained DHH’s singular vision for convention over configuration and simplicity and in so doing has bought a tremendous amount of productivity, beauty, and happiness in the process. As Thucydides reminds us, “of all manifestations of power, restraint impresses men most.”

http://www.37signals.com/svn/archives/000887.php

Steve Jobs says: "It comes from saying no to 1,000 things to make sure we don’t get on the wrong track or try to do too much. [...] It’s only by saying no that you can concentrate on the things that are really important.

Jason Fried says: "Always say no default. Make features and ideas beg to be made, beg to be included, beg to be pursued. You’ll know when they need to be."

Erik Kastner said at http://notrocketsurgery.com/articles/2006/06/24/getting-rails-backwards :

"... the overarching goal of making the framework disappear until you truly only work on the business rules that are interesting"

Paul Krill (May 21, 2007). InfoWorld: Rails creator doubts Silverlight can win converts (http://www.infoworld.com/archives/emailPrint.jsp?R=printThis&A=/article/07/05/21/hansson-qa_1.html). Retrieved on 2007-05-11 11:18.

...

Hansson: The summer of 2003 was when I originally got into Ruby, and I had been doing PHP and some Java for about four or five years ahead of that. But I was getting fed up and tired with those environments and wanted to give something new a chance, so I stumbled over Ruby and started playing around with it. And within about a week of playing around with it, I knew there was no way I could go back to either PHP or Java or anything else I'd been doing before.

InfoWorld: Why is that?

Hansson: Ruby just felt like such a great fit for my mind. So many things that I was frustrated about in previous environments I'd worked with just seemed to be solved incredibly beautifully in Ruby. And that was really one of the first things that I noticed that I intensely liked about Ruby, it was the aesthetics of the language. Ruby code is just inherently beautiful. Sure, you can write ugly code, but you can write incredibly beautiful code too.

InfoWorld: How did Rails come about?

Hansson: It started out not wanting to be Rails. It started out just me wanting to implement Basecamp [...]. [...] So around December 2003, I kind of got into the mode that, hey, I want to release this. I want to wrap this stuff up, these tools I'm doing, put it into a box and let others enjoy themselves with it. Because I was thinking, Ruby is kind of a hidden gem right now. And it's really a shame. There are so many Web developments out right now that are, in my mind, stuck in PHP or Java, which is what I was thinking about at the time. And if I could have so much fun as I was having with Ruby right now, it'd be a travesty if I just kept all that to myself. So around December of 2003, I made the decision to really make a framework out of it, but it wasn't until six months later that Rails was actually released for the first time. We released it I think June 24 of 2004, the release of Rails 0.5.

InfoWorld: [...] Why are developers so excited about Ruby and Ruby on Rails? [...]

Hansson: Sure. I think a lot of developers are excited about Ruby on Rails because it allows them to focus and think about something as simple as the joy of programming. That's not just a side effect of working on real enterprise production systems, it's at the forefront of development [of] Ruby on Rails. We really want developers to be happy about the programs they're working on, the tools that they're working with, and the environment they're living in as programmers. And I think that [we are] explicitly choosing to make that the center of development of how we go about developing Rails, making sure that the aesthetics are just right. It's not the traditional computer science attributes we're trying to optimize for like memory usage or performance. We naturally care about those things because if it's not fast enough, it's not going to make us happy. But primarily, we care about getting beautiful code and getting a development environment where people are just happy about their work. And there are plenty of things in most traditional development environment that make people miserable. We tried to find those pain spots and remove them.

InfoWorld: Could you just name a couple of them?

Hansson: One of the things, for example, is how you configure your applications. A lot of environments, especially before Rails came around, had a notion that you basically started with a blank sheet of paper every single time. Everything had to be configured from scratch. How do I talk to the database? How do I map these fields between objects and records and rows and so on and so forth? You had to configure that explicitly every time, even though you might be doing the same thing over and over and over again. Like Groundhog Day, everything just started over and over and over again. So with Rails, we decided it's not going to be Groundhog Day. We're going to make some decisions and we're going to make them once. And once we've made those decisions, we're going to turn them into conventions, and we're going to teach you those conventions. And once you've learned them, it's done. Like we're no longer going to talk about what the primary key field in database tables are going to be called. They're going to be called ID, that's it. Now, [it's] done. Let's move on to the next decision. And like that we progressed through a ton of standard configuration points and literally removed them. We replaced them with conventions that said if you're just doing what most developers are doing the same [way] most of the time, you're going to get it for free. So they're going to be called ID. You don't care about that anyway. You shouldn't be caring about what the primary key fields are called, and if you can lift yourself above that and not care about it, you can get all this configuration stuff for free. So I think that's probably the biggest contribution we've made to thinking about frameworks. How can we get less configuration? How can we replace it with conventions instead? And how can we get a lot of productivity out of that?

InfoWorld: How does Ruby on Rails compare to Java framework like Spring?

Hansson: I think one of the big differentiators is definitely that notion of convention over configuration. Java frameworks in particular have been peculiarly fond of XML for wiring pretty much everything together, and in some sense, it sounds great. You get ultimate flexibility, you get the opportunity to wire everything together exactly like you want it, but most people don't really care. That amount of flexibility is not worth the tradeoff. And I think that's the fallacy of a lot of frameworks, especially in Java, they thought flexibility was free. Flexibility is not free. It's overrated. And if you trade that flexibility in for some constraints, you get a lot of complexity removed from the equation, you get a lot of productivity back from all the stuff you don't have to do. So that's one of the reasons that Rails is different from something like Spring or Struts and so on. Another thing is just the aspects of something like Ruby. The Ruby programming language is just an amazing programming language to be able to work with, and we choose to employ it across the stack. So everything is written in Ruby. We write the views in Ruby, we write the models in Ruby, we write the controllers in Ruby. We try to keep everything as Ruby as we can instead of mixing something up with XML this or configuration files that.

...

Hansson: I think now that we're here at RailsConf, I'm really just immensely impressed about how far we've gotten in such a short period of time. Rails really took about a year to get going. The first year it was only über geeks getting involved and getting excited about it. The first book didn't come out until a year after. And so the first book is even just two years old. Today we have more than 20 titles, I believe, and we have a conference with 1,600 people showing up. It's fantastic to me to see the kind of impact that a grassroots initiative can have on the software industry in general. And that's not just my contributions, it's the contributions of everybody who's been involved with the Ruby on Rails project. There are so many people who have contributed to it, so many people who have evangelized it.

[edit] It's not about the scaffolding!

http://notrocketsurgery.com/articles/2006/06/24/getting-rails-backwards

But scaffolding is not and never was intended to be central the the Rails development process. It’s literally a way to save you some typing when getting your application up and going, so you can start poking around with data early on. It’s not supposed to build the application for you. Only you know your business logic, and scaffolding isn’t going to help you with it.

[edit] Does it scale?

RubyEnRails2007 - Dr Nic Williams - Keynote » SlideShare (http://www.slideshare.net/drnic/rubyenrails2007-dr-nic-williams-keynote/). Retrieved on 2007-05-11 11:18.

Everyone worries about requests per second; but I think its more important to worry about the cost per new feature. Rails is structured to make it easy to design and implement new stuff.