
The Rails Doctrine - robin_reala
http://rubyonrails.org/doctrine
======
sauere
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.

~~~
lectrick
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
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.

~~~
bphogan
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.

~~~
cookiecaper
Those assumptions that "optimize for developer happiness" 95% of the time make
the developer's life hell the other 5% of the time. It happens often enough
that "explicit is better than implicit", within reasonable constraints like
dynamic typing, is one of Python's core values, and experienced developers
usually come to appreciate it.

It's best to design an API that makes what's happening clear without being
overly verbose or esoteric, and without making assumptions, especially not
dangerous assumptions that may cause you to lose data (exit may close the REPL
and cause you to lose your session when you forget that exit is a special word
in REPL mode). My personal feelings are that Python has done a better job at
this than any other major language. I have major projects in both Ruby and
Python and I enjoy the Python ones 100x more because of this.

This document partially explains why; DHH is normalizing shortcuts because it
helps him gain new users, even though working around those same shortcuts
becomes a major PITA when you need to go a little bit off the beaten path,
which happens in one way or another in most real software. There is a way to
make these things explicit with only marginally more typing/"effort" (for
example, requiring parens to call functions with no arguments, making it
explicit and obvious when someone is referencing a variable vs. when they're
calling a function), thus avoiding the complexity down the road.

~~~
bphogan
> and experienced developers usually come to appreciate it.

I find statements like this a bit condescending. It's like when Java
developers say 'Oh, that's nice, but I work on _big_ applications." "Obviously
you don't get it because you're not experienced. _Experienced_ developers get
it."

I'm sure that wasn't your intent. But it still irks me a bit.

I've been writing software for a very long time, in many languages and
paradigms over the years. I believe that qualifies me as an experienced
developer. My years of experience tell me that if I only experience pain 5% of
the time, then the 95% of the time I _don 't_ experience the tools I use
making me do extra work more than makes up for it. :)

~~~
cookiecaper
>I'm sure that wasn't your intent. But it still irks me a bit.

Correct. I meant it inclusively, like most of the Python community is either
experienced developers who've worked in a lot of languages and have sought
refuge in the sanity of Python or the apprentices of such developers. Python
doesn't have a figure like DHH to give it sex appeal, so not many new people
use it.

There are definitely experienced developers who have not yet had occasion to
seriously enjoy and appreciate Python.

>My years of experience tell me that if I only experience pain 5% of the time,
then the 95% of the time I don't experience the tools I use making me do extra
work more than makes up for it. :)

I meant this as a count of the number of issues, not the amount of time it
takes to resolve them. That 5% of problems caused by non-obvious implicit
magical behavior usually take an inordinate amount of time to debug and solve,
and then the workarounds are usually disgustingly ugly because the framework
had never conceived that someone might have a valid reason to circumvent their
magic. Even worse, this locked-down, "looking inside will void your warranty"
attitude (which Rails often calls "convention over configuration") frequently
means that the workaround must be somewhat pervasive and ugly up your code not
just in one place, but in several places to really resolve the problem.

Experienced developers may not encounter this often if they don't use a lot of
magical APIs that promote the systemic ambiguity of "do what I mean".

~~~
bphogan
> Even worse, this locked-down, "looking inside will void your warranty"
> attitude (which Rails often calls "convention over configuration")
> frequently means that the workaround must be somewhat pervasive and ugly up
> your code not just in one place, but in several places to really resolve the
> problem.

In 2005, when nobody used Rails, as a complete beginner to Ruby, I was able to
write a patch to improve the Oracle database adapter. Somehow, despite all the
magic, it took me very little time to find what to change and submit a patch.
As a complete newbie to the language and platform.

Rails 2 and below revolved around a lot of hacks. Rails 3 removed many of
those. Rails 4 even more so. Check out the book "Crafting Rails 4
Applications" to see how easy it is to hook into places in the framework to
get what you need. (Disclosure: I'm the editor of that book.)

The argument you make about "voiding the warranty" is an argument I hear from
people who have touched Rails for a project and hated it for one reason or
another. It's not a sensible argument.

Remember, for centuries, people used "magic" to explain away something they
didn't understand. :)

~~~
cookiecaper
>In 2005, when nobody used Rails, as a complete beginner to Ruby, I was able
to write a patch to improve the Oracle database adapter. Somehow, despite all
the magic, it took me very little time to find what to change and submit a
patch. As a complete newbie to the language and platform.

One part of the system not being obfuscated doesn't mean that many other
important parts aren't.

>Rails 2 and below revolved around a lot of hacks. Rails 3 removed many of
those. Rails 4 even more so. Check out the book "Crafting Rails 4
Applications" to see how easy it is to hook into places in the framework to
get what you need. (Disclosure: I'm the editor of that book.)

I currently maintain both Rail 2.3 and Rails 4 applications. I totally agree
that Rails 4 is a much smoother experience. There are still hacks around the
magic that I've had to implement. The one most immediately on the top of my
head is one of the form generators ignoring the method argument in some
circumstances because it _knows better_ and forcing me to jury rig them into
obeying the command anyway (with a bit of JavaScript that alters the method
on-page IIRC).

>The argument you make about "voiding the warranty" is an argument I hear from
people who have touched Rails for a project and hated it for one reason or
another. It's not a sensible argument.

Of course it's a sensible argument. Frameworks shouldn't be causing those
feelings in people -- the magic isn't magical if it's getting in the way. If
people are coming away with the impression that the system will blow up or
otherwise misbehave when they try to peel back the covers, it's ignorance to
just blame them for feeling wrong. One should try to at least understand the
problem; then, you can decide if it's a problem that needs correction or if
you're just OK with people who want some flexibility and cooperation from the
framework not using your stuff and be honest about that so that they don't
have to waste their time.

>Remember, for centuries, people used "magic" to explain away something they
didn't understand. :)

And, also for centuries, people used "magic" to hoodwink gullible people.

------
vinceguidry
I submit that anyone who takes the time to really learn Rails and how it works
and the problems it solves will never want to use another web framework except
for toy projects. It really is that good, and just keeps getting better every
year.

It does one thing, web applications, and does it really, really well for the
type of coder / team it was designed for.

People that belittle it by saying it has too much magic or whatever have never
seriously tried to maintain a huge web application all by themselves. Web apps
are ridiculously, mind-bogglingly complex, Rails conventions have been baking
for well over a decade now.

If you're Twitter, maybe you have the resources to maintain a serious web
presence without Rails. Everyone else is just handicapping themselves.

~~~
staticint
Having used Rails seriously since it was originally made available as an open
source project, I find myself agreeing with you less and less. It has really
failed to stand the test of time, in my opinion.

I agree that it nailed the needs of web applications in 2004. If you are still
building web applications like they did then, perhaps it is still the best
tool. In the circles I find myself in, there is a push for much more
Javascript heavy applications and Rails starts to become a large hinderance
more than a help in that environment, when compared to other tools.

We've built a log of great software together over the years, but I can
honestly say that I'm not going to rush into using it in future projects.

~~~
enraged_camel
This is a bizarre comment. Rails failed to stand the test of time because it
doesn't play very nicely with monolithic JavaScript frameworks? Are you
asserting that such frameworks are the future?

~~~
gedy
I think they are referring to most UI logic being on the client, not on
server. That architecture does not require a monolithic JS framework, nor does
Rails offer anything special in that case.

~~~
enraged_camel
"Doesn't offer anything special" is quite different than "starts to become a
large hindrance."

------
attilagyorffy
I've been a Rails developer for 10 years now and I have to say it is still my
favourite tool of choice (yes even in 2016). There are other interesting tools
and frameworks out there (I'd love to put my hands on Phoenix and Elixir if I
had the time) but for now I have to be honest: When I start a new client
project I have to consider a few things:

* Using a well-known framework is favourable over new shiny toys in a commercial system

* An ecosystem that has good 'defaults' is essential. A single web framework won't do everything for you. You need stuff around that for testing, deployments, etc.

For mainly the reasons above Rails is still my primary tool of choice. Yes, it
has pinpoints but the reasons above far outweigh the new and shiny.

------
equalarrow
Couldn't agree with DHH more.

I found Rails during the 0.9 releases. Coming from the horrific world of Java
web frameworks like Spring and Tapestry, it was a revelation to see how fun
and productive web programming could be again.

When I saw things like 2.times, 1.day.ago, and ActiveRecord, I knew I was done
with Java web development. This isn't a knock against Java per se, but I just
spent so much time in the trenches having to do busywork and configuration
that isn't necessary if authors of those frameworks put programmer
productivity and enjoyment first.

Thank you DHH!

~~~
cballard
> 1.day.ago

So apparently .day multiplies the number of seconds in a day by the receiver,
then .ago subtracts that from the current date[0].

However, not all days contain the same number of seconds. This is where
"friendly" APIs like this lose me - they're vague and sometimes incorrect.

In Foundation, which I consider to have a decently designed date API, "dates"
are doubles of seconds all since a reference date, and "date components" are
used to express the concept of days, months, and years - which also require a
time zone and a calendar to even make sense.

[0] [https://stackoverflow.com/questions/21392065/how-do-you-
impl...](https://stackoverflow.com/questions/21392065/how-do-you-
implement-1-day-ago-in-ruby)

~~~
danielvf
That StackOverflow answer is wrong.

Rails does correctly handle `1.day.ago`, taking into account the number of
seconds in a day.

`1.day.ago` is a perfect example of what DHH was saying, in that it looks
beautiful, but requires a bit of work under the hood. `1.day` creates a
duration. This isn't just a number of seconds, but is represented by hash,
more like `{:days=>1}`. When it's time to do the actual math, Rails looks at
the :days number, and actually moves the day part of the date forwards and
backwards.

Source here:
[https://github.com/rails/rails/blob/master/activesupport/lib...](https://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext/date/calculations.rb#L113)

------
edwinnathaniel
I recently wrestled with the idea of using NodeJS for any side projects. I
touched Ruby/Rails in the past for a few times (on-off between small works)
and never really felt excited or see it as something "beautiful" because at
the end of the day, we, developer, still have to debug our own buggy code.

After a few strings of drama in the NodeJS land, a few chat with friends who
used NodeJS in production, and seeing the pattern of BigCo who use NodeJS only
for glue/front-end/gateway appserver, I'm pretty close to settle with Rails.

I admire DHH for his dedication to the framework for so long (since 2004). You
don't see that type of dedication in the NodeJS land. Yes, NodeJS is still
new, but a few BDFL/leaders of important NodeJS projects had left the boat
already. One of the premier NodeJS vendors, StrongLoop, always mired with
controversy (I happened to know a few people who worked for a company that was
acquired by StrongLoop).

Building long-term side-project requires a stable platform because of the time
limit (outside office hour + other responsibilities). Dealing with unstable
but "sexy" technology is not a good choice.

------
jaredcwhite
I think DHH has realized that Rails has a bit of an "image" problem when it
comes to new web app development, and this is a way to lay out why Rails
remains relevant and even desirable. No doubt some will take exception to some
or most of his points, but that's OK. For the rest of us who thrive in
continuing to build with and evolve the Rails ecosystem, it feels good to see
a renewed focus on communicating just what makes Rails (and Ruby) special and
vital.

------
bcardarella
For those that are interested in a more performant and scalable Rails-like
experience I encourage you to check out Phoenix:
[http://phoenixframework.org](http://phoenixframework.org)

We have been working with Elixir (the language Phoenix is built on) for over a
year. It is an incredibly satisfying language and its toolset is surprising
advanced for its age. Phoenix has been a very easy mental jump for our
developers who were already trained on Rails.

~~~
flashm
To add another side to this coin, having recently used Phoenix to write an api
after hearing good things, I found Elixir clunky, and Phoenix poorly
documented. It tries to be too much like Rails (I realise this is the point,
though), and is currently failing spectacularly in my opinion. YMMV obviously.

~~~
chrismccord
In the spirit of making our docs better, what did you find poorly documented?
We go to great lengths to have extensive, comprehensive docs. Pick any module
in our source, and you'll find extensive documentation on usage, APIs, etc.
All docs are extracted to hexdocs.com as well
[http://hexdocs.pm/phoenix/Phoenix.html](http://hexdocs.pm/phoenix/Phoenix.html)

This is in addition to our separate online guides focused more on getting up
and running through the basics. Where did we lose you?

~~~
themgt
I think the Phoenix/Elixir docs in general are quite good, it's just the lack
of years of blogs and stackoverflow q&a that makes it harder to jump in.
Switching from Ruby's OO/functional to Elixir's purely
functional/immutable/actor-based would be easier with more of other people's
code to read and learn from.

I'm a complete n00b and was just trying to get a pool of TCP client workers to
monitor servers and update a DB and display the results in a Phoenix app, and
I kept coming across the same 4-6 blog posts and docs, maybe 60% of which were
for pre-1.0 Elixir and no longer quite worked.

I see a huge amount of promise with Elixir/Phoenix as well; currently it makes
some hard things easy but also many easy things hard. With a few years of
library/community growth I could see it wiping the floor with Rails for a lot
of projects.

~~~
jdalbert
An Elixir/Phoenix "Railscasts" would be great too

~~~
remi
[http://elixirsips.com/](http://elixirsips.com/)

------
criddell
Now that Rails isn't the cool new thing anymore, is it still a good choice for
new projects?

For the new year, I'm thinking about the programming landscape and
contemplating what I want to learn next. I've tinkered with Ruby on Rails in
the past and think DHH is on to something with the doctrine he has laid out.
I've only scratched the surface of Rails, but it still seems pretty neat to
me. A deeper dive would be fun.

On the other end of the spectrum, Dart + Angular is appealing in part because
I'm a fan of some of the Google developers working on Dart. While Rails feels
like it is entering a comfortable middle age (or at least adulthood), Dart
feels a little like a car being assembled as it cruises down the interstate.
It's new and maybe a bit dangerous.

Both projects are super-appealing to me. Unfortunately time constraints
prohibit me from chasing both and I'm interested in opinions especially of
Rails people. Are you still excited about it?

~~~
chrisseaton
> Now that Rails isn't the cool new thing anymore

But why does that have an impact on what tech you use?

~~~
criddell
It's a good question and it's really what I'm asking about.

The only web-stuff I've worked on in a commercial settings was a long time ago
using Java and Tomcat. At the time, it was the cool new thing. I think that
some of the pain points of languages and frameworks from that era are what
prompted DHH to develop Rails (I'm specifically thinking about convention-
over-configuration and admit I could be totally wrong here).

So today, I probably wouldn't pick Java and Tomcat for a personal project just
because I know it won't be as fun and I won't be as productive as I would be
with different technology. Has Rails been eclipsed in a similar way?

~~~
edwinnathaniel
I'll pick Java, SpringMVC, Maven, JUnit+DBUnit, and FlyWay (DB migration) and
any appserver (jetty, tomcat, TomEE, glassfish) thrown at me except from the
BigCos (WebLogic, WebSphere).

Those tools are pretty close to what Rails give you (notice the View/UI is
open for anything... Rails View is slightly nicer as it has better templating
capabilities but ... not a deal breaker for me).

It's not sexy, it gets the job done, and I know it'll run for at least 5-7
years with minimum hassle.

Plus it's easy to be productive on Java project...

~~~
jazzyk
Upvoted. I am tired of getting the "uncool old fart" looks every time I
propose similar stack. You CAN do cool stuff with established tech plus have a
peace of mind that you will not run into any "surprises".

~~~
criddell
It makes total sense to mitigate risk on a commercial project by going with
established (well supported, well understood) technology. No argument. But for
a personal toy project where you _want_ to be surprised, would you choose
something like Ruby on Rails?

------
rileymat2
About picking the "Best" tool for the job. One annoying thing about Stack
Overflow is that they aggressively stop those types of questions with their
mod system. Just understanding the Pros and Cons of the major options is very
valuable, but not allowed.

~~~
aikah
About SO, it's just that this isn't the goal of SO. The goal of SO is asking a
precise question and getting a specific result, it's not a place for debate or
opinion.

Quora could have been that place, for some reason and because of some odd UX
choices ( mandatory signup to browser the site ) , it isn't , which is too
bad.

~~~
briandear
So it would destroy SO if, in the context of programming, there was a best of
question? Are they really that tight-assed? Do they not have the bandwidth?
Really, I'm curious how those questions would hurt the site. And Quora? Why
would SO prefer users to actually go somewhere else? Debate and opinion,
despite what the moderators think, is a valuable part of coding. It isn't all
"solve for x."

Because the interesting thing about the 'ask a specific question' concept is
that some questions are closed because they're too specific. I pretty much
abandoned SO. The anal retentive pendants moderating things have turned me off
to spending any time contributing.

~~~
leohutson
It's just subjective and unproductive noise.

The strict moderation and categorization is what makes stack exchange useful
in general. Why not use a free-form forum like Reddit for that kind of
question? Because you know the answers are going to bullshit opinions and holy
wars, mostly by people that are trying to solve different problems than you,
or are actually less knowledgeable than you.

Given the fact that Reddit and similar forums suck for finding solutions to
specific problems, why should a Q/A site that is good for finding solutions
for specific problems try to emulate it?

Quora and Yahoo answers also suck because the questions are almost entirely
anecdote and opinion based, and it seems to be acceptable to cite "experience"
as a source for bullshit opinions. "Being a pilot with 10 years of experience"
is not an adequate reference for a response to a question about the safety of
using a cellphone radio on a commercial flight, nor does "being a veteran"
count as original research into Iraqi popular support for the 2003 invasion.

Of the good "answers" from Quora that I've seen shared, all are basically long
form blog posts that have found a "close enough" question to answer, rather
than been motivated by the question, and I would have actually preferred to
read them on medium or some other blog site. However interesting they are,
they aren't answers.

I think projects like Rosetta code are useful for comparisons of programming
languages, because they keep it concrete. You can also look at big high-
quality projects on github or whatever and directly judge the subjective
qualities of a language for yourself, based on how readable the code looks to
you.

------
elliotec
I was just singing praises to Rails last night for these reasons.

At my corporate job, we use Java with Spring, and a hellish mess of node
packages/libraries/whatever we're calling them now. It's not good.

So when I do side projects or consulting gigs, I always run to Rails which is
what got me into development. It's very refreshing.

Reminds me of the jQuery post the other day. Rails is just a little older than
jQuery. Rails with some jQuery sprinkled in is as close to development
perfection as I've ever seen.

Also re: "too much magic" \- Why is magic a bad thing? Creating layers of
abstraction to ease building is what programming is really about, right? Why
would we want to go backwards to configure everything under the claim of "I
need to know how EVERYTHING works!"?

~~~
rudolf0
Sometimes (performant) SPAs provide a better user experience than regular
views strung together with Ajax/jQuery. But otherwise, I agree. Rails and
jQuery were probably the first truly "nice" APIs I've used in programming, and
I still get quite a bit of enjoyment from using them, to this day.

~~~
elliotec
I've seen a few examples of performant SPAs providing a better user
experience, but I can only think of a couple. One example would be the Timbuk2
bag customizer: [http://www.timbuk2.com/customizer#/product/15-custom-
commute...](http://www.timbuk2.com/customizer#/product/15-custom-commute-
laptop-messenger-bag/size/4/customize)

But even this seems possible without committing to an SPA architecture. If I
recall correctly they are using Ember for this.

But yeah, you're right.

~~~
rudolf0
Check out [http://ask.fm](http://ask.fm)

This is actually a SPA _and_ a bunch of strung together jQuery. But things
subjectively feel "faster" compared to what the site was like before they
upgraded to this model.

------
batiste
There is great stuff to say Ruby and RoR. But I have yet not experienced the
"smile" that DHH is describing. Especially when I have to read and understand
the code written by colleagues (or myself mind you). To do my job I had first
to become a master in grep to find where stuff come from and deciphering half
assed documentation. Mostly because exploring objects with hundreds of methods
is not my cup of tea. I also enjoy understanding my tools, and RoR is, in my
experience, not particularly easy to understand. This doesn't put a smile on
my face.

~~~
jasonjei
batiste, I think what you are describing is that the culture around Ruby
doesn't put a smile on your face, rather than just Rails.

Ruby's philosophy is quite a bit different from Python, Smalltalk, Perl, Java,
and PHP. Ruby is roughly described as "batteries included." Some people don't
prefer this, as it encourages meta-programming and introspection rather than
explicit instructions.

A lot of libraries and tools around Ruby use meta-magic; some libraries have
been attempting to strike a middle ground with meta magic, such as Datamapper
(explicit) vs ActiveRecord (implicit). But the bias is definitely towards
implicit; or as what DHH calls "omakase."

------
cballard
> Where Java championed forcefully protecting programmers from themselves,
> Ruby included a hanging rope in the welcome kit.

I don't think this is something to be admired in a language. Java is a bad
language to work in because it's not expressive, not because it protects
programmers (which it _doesn 't_).

Thankfully, we are seeing this shift the other way with the growing popularity
of languages like Rust and Swift.

~~~
kyllo
_Java is a bad language to work in because it 's not expressive, not because
it protects programmers (which it doesn't)._

Compared to C/C++, yes it does. Java protects you from out-of-bounds array
access, uninitialized access, buffer overflows, use-after-free, double-free,
etc etc.

~~~
kazagistar
Memory safety is a protective feature as much as sending texts is a smartphone
feature. Sure, it is nice and very useful, but almost all languages provide
it, so it does not count for much these days.

~~~
MrBuddyCasino
Thats how it should be, but the frequency of C/C++ threads on HN and the
discussions about memory safety that will inevitably follow unfortunately
paint a different picture.

God I hope Rust will shoot C++ in the backyard and put it out of its misery.

------
ronnier
>Optimize for programmer happiness

I've never been more unhappy programming than when I touch Rails. I'll take
python or Java any day of the week.

>Convention over Configuration

Discoverability is totally gone. Walking into a brand new RoR app and it's
next to impossible to figure out what's going on. Not having a good IDE
doesn't help.

>Exalt beautiful code

Write simple easy to read code. Don't be clever.

~~~
jcsnv
>I've never been more unhappy programming than when I touch Rails. I'll take
python or Java any day of the week.

Try PHP

------
ianamartin
My background is Python, C#, and SQL, and it shows because those languages
have affected the way I think about programming.

I strongly disagree with DHH's points 2,3,4, and 6. But I think I'm going to
learn the language anyway and use it for some projects because I think it's
important to not get in a rut. Using different languages changes the way you
think about code, and if you are not constantly updating the way you think
about code, you are falling behind.

Besides, I really like the way DHH writes. His language is persuasive even
when I quite certainly disagree with him.

Still going to learn a functional language first probably. But then
Ruby/Rails.

~~~
hardwaresofton
A tad bit off topic, but for your functional language I'd recommend Haskell.
It's given my mind the most trouble out of any of the other functional
languages I've tried (which is a good thing). I find it's syntax reasonable,
and resources plentiful.

Excellent lecture series on functional programming (language used is Haskell):

[https://channel9.msdn.com/Series/C9-Lectures-Erik-Meijer-
Fun...](https://channel9.msdn.com/Series/C9-Lectures-Erik-Meijer-Functional-
Programming-Fundamentals/)

When you get to trying to understand monads, DON'T look up monad tutorials,
look for functor -> applicative functor -> monad tutorials, like this one:

[http://adit.io/posts/2013-04-17-functors,_applicatives,_and_...](http://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html)

~~~
ianamartin
Thank you for this. Much appreciated. I have a copy of learn you a Haskell for
great good and have been slowly working my way through it in my occasional
spare time.

Also interested in F# these days now that Microsoft seems to be open-sourcing
. . . pretty much everything.

~~~
suls
There's only one way to learn Haskell: you have to use it!

Both links below show how friendly the Haskell community is for people willing
to learn:

[https://github.com/NICTA/course/blob/master/README.markdown](https://github.com/NICTA/course/blob/master/README.markdown)

[https://github.com/bitemyapp/learnhaskell/blob/master/README...](https://github.com/bitemyapp/learnhaskell/blob/master/README.md)

Good luck on your journey!

------
Luyt
I transcribed an interview with DHH [0] in which he also explains his
motivations for choosing Ruby (instead of PHP or Java, for example), and where
he explains some design principles for Rails.

[0] [http://www.transcribed-interview.com/dhh-rails-david-
heineme...](http://www.transcribed-interview.com/dhh-rails-david-heinemeier-
hansson-interview-randal-schwartz-floss.html)

 _" One example I always pull out is “what you gonna call the primary key in
your tables?” When I was working with PHP and Java, every single shop, almost
every single application, would have its own naming scheme. Some would say
they have the ‘Products’ table and then they'd have ‘productid’, others would
have ‘product_id’, some people would have ‘prod_id’ or ‘p_id’ or ‘P_id’, and
every time somebody made a new design decision it meant configuration. You now
have to tell your models, your objects, how they're going to talk to this
database table. Because it needs to know what the hell you called the freaking
primary key column, and it just doesn't matter! Who cares what the primary key
column is called? It just doesn't matter. It's going to have zero impact on
the usefulness of your application."_

and

 _" ‘Dont repeat yourself’ is all about not having the same intentions spread
out in multiple places. Don't have one configuration. If you're calling
something, let's again take the example of the primary key. If you're calling
that for ‘id’ you shouldn't have to configure that in three different places
that all have to work together and all have to be changed together. You should
just pick one authoritative place to have that information stored. And then
you can make changes from there. It also goes with the the whole Ruby idiom:
we don't want those Java boilerplate ten line things: that's repeating
yourself. If you have the same idiom, if you have the same intentions, that
should really be exceedingly a short expression. And that goes up throughout
the entire framework. Just keep one place to change those things, and keep the
idioms very short."_

~~~
edwinnathaniel
That sounds like the pre-ORM days.

These days ORM would map member variable id to database table id.

~~~
Luyt
The interview is from July 2009. I think Rails already had its ORM then. DHH
says:

 _" The model part in an MVC application is where all the business logic is
kept. Those are all the classes like ‘Post’ and ‘Category’ and ‘Author’ and
all those things –say if you're making a weblog– you'd keep all that stuff in
the Model. And you'd have all the logic about whether the author is allowed to
make a post and how the relationship between posts and comments work together.
Those are all sitting in the model, so that's all the business logic, very
often backed by a database in some sense, not always, but most of the time.
And that's where in Rails we're using something called ‘ActiveRecord’. Which
is this way of mapping database tables to objects, and then decorating those
objects with logic."_

~~~
edwinnathaniel
I was referring to:

> When I was working with PHP and Java, every single shop, almost every single
> application, ...

------
jerguismi
It is funny how small things affect your future. I did a lot of stuff with
rails back in 2007 or so. However I really got fed up with it because some
things were so slow. So for the next project I decided to pick up django, and
I've been using django since then.

Would it have made much difference if I had staid with ruby/rails instead of
python/django? I dunno. Many of my friends have careers with rails, and they
have nice careers. I have nice career as well, as do many other friends with
django. In the end they are not that different, I guess.

------
qertoip
If you like the Rails Doctrine, check out Phoenix Framework and Elixir
language by the former Rails Core Developer Jose Valim. You'll get hooked as
you did with Rails 10 years ago.

------
resca79
I like ruby and rails, not just for the framework itself, but for what it was
and it is for many developers.

I want to say thanks to DHH for his way to maintain the framework simple,
despite to many PRs that try to make rails more complex.

Thanks to this document, I'd like to read also some document about the
standard in big rails app.

------
jaequery
Sigh, it's hard to take any of these comments seriously without first
understanding how much real-world experience they actually have in the
industry.

~~~
brianolson
You could probably post that comment verbatim on half the threads in HN and
get upvoted.

------
TheMagicHorsey
Mature Ruby projects are very difficult for a new Ruby programmer to parse and
understand. In contrast, Go projects are quite easy to understand.

DSLs are part of the reason for this.

Naturally there is a tradeoff. People that have been working with a particular
DSL in Ruby for a long time can achieve amazing things in a short amount of
time. Equivalent productivity is not really possible in Go (at least not yet,
in my experience).

Having said that, I think it is easier to onboard new (and newbie) programmers
onto a Go project than a mature Ruby project.

------
AKifer
Having been working with Rails for a long time, now I wonder what could be the
next cool thing looks like. The only improvement I'd like to see is about
performances, and Elixir and Crystal are a good candidates to replace ruby in
this direction. But until now, I don't see any other framework equaling the
elegance of Rails, great job David and all the community, let's continue to
keep Rails weird.

------
ryan-allen
I personally prefer ASP.NET MVC, it has all the core parts of early Rails
(back when it was nice and simple), and it's statically typed to boot.

The most magic thing in .NET MVC is Entity Framework, and all it's magic is
either a bunch of strongly typed convention classes (of which you can create
your own), or LINQ queries, which work pretty well.

If I'm building stuff for Adults with Money I'll choose static typing any day.

------
euphemize

      This is easily described with a contrast to Python. [...] Ruby accepts both exit and quit to accommodate the programmer’s obvious desire to quit its interactive console. Python, on the other hand, pedantically instructs the programmer how to properly do what’s requested, even though it obviously know what is meant (since it’s displaying the error message).
    

When you're trying to convince me that your programming language is great
because another one is so much shitter in comparison, you're on the defensive
and basically telling me you don't trust your own stuff. Especially when this
is at the top of your article.

By the way, python handles your example very gracefully in comparison to other
REPLs (for instance, node spits out a cryptic, but expected traceback on
exit/quit)

~~~
brightball
He didn't say Python was bad in comparison. He just highlighted a simple
example of coding to spoken language expectation even if it means aliasing.
It's a minor example of trying to make the development experience more
enjoyable, nothing more.

~~~
euphemize
Did you read the quote? He very exactly says that python is bad in comparison
- by using a concrete python vs ruby example.

If this was a passing mention on some blog post, I'd be inclined to believe
you, but this post is not like any other. It's a descriptive update of the
current rails "doctrine". When I ask you "why is your X so great" and you tell
me immediately "look at how bad Y does", I'm inclined to think you're not
feeling very secure about X.

~~~
brightball
Here is the exact quote from the article:

> Anyway, what did this mean for Rails and how does this principle continue to
> guide its evolution? To answer that, I think it’s instructive to look at
> another principle that was often used to describe Ruby in the early days:
> The Principle of Least Surprise. Ruby should behave how you’d expect it to.
> This is easily described with a contrast to Python:

> _code snippet_

> Ruby accepts both exit and quit to accommodate the programmer’s obvious
> desire to quit its interactive console. Python, on the other hand,
> pedantically instructs the programmer how to properly do what’s requested,
> even though it obviously know what is meant (since it’s displaying the error
> message). That’s a pretty clear-cut, albeit small, example of PoLS.

Nowhere in the above is he calling Python bad. He's using an example of how
Python handles a thing to illustrate how Ruby handles that exact situation
differently inline with his philosophy "Principle of Least Surprise". I'm not
trying to get into a semantic argument here, just pointing out that he's
making an illustration with a minor detail.

Calling Python "bad" would make no sense, because Python is wonderful. This is
just a way to highlight how Ruby does things differently than others have
chosen to do them.

~~~
euphemize
Unfortunately it seems like the argument is mainly semantic then - I find it
reasonable to think that "pedantically instructs the programmer how to
properly do what’s requested, even though it obviously know what is meant" is
pretty much a detour to say it's not good, it's _implied_.

I just don't see why DHH needs to do this - ruby has so many things that make
it stand on its own.

~~~
brightball
That's fair. Sometimes to put decisions in context you need to be able to
compare it to something else, but I do understand where you're coming from.

------
jesstaa
9\. Monkey patching instead of good design 10\. Don't worry about data
integrity

------
miseg
I know PHP-bashing is oldschool, and I love what I've been able to do with
PHP.

After a decade of me in PHP, his love for Ruby is a lovely selling point for
trying out that language.

------
bliti
Bit off-topic here:

How is the Rails market these days? It seems (personal perception of outsider)
that it has been replaced by Python/JS work.

~~~
nik736
There is still enough work and projects being built using Rails. Of course
NodeJS stole a lot of thunder from Ruby/Rails, but everyone who has been smart
either went back to Ruby/Rails or moved on to Go (if performance was an
issue). I don't think Python is an issue, it's always have been that people
went from Ruby -> Python and vice versa.

~~~
bliti
The change from Rails to Go must be quite shocking. Going from such a
completely framework to a barebones language is a huge step. I write Go and
went from Python -> Go and it still was a bit of a jump. :)

------
sadiqmmm
DHH is amazing.... Thank you for creating RAILS.

------
norswap
I was hit hard by the cognitive dissonance at the start of section 2.

Just after waxing in section 1 on how Rails is designed to his own happiness
(including adding quirky methods like 'fifth'), he says "One of the early
productivity mottos of Rails went: “You’re not a beautiful and unique
snowflake”"

------
windor
I think this should be post here:
[https://dockyard.com/blog/2015/11/18/phoenix-is-not-
rails](https://dockyard.com/blog/2015/11/18/phoenix-is-not-rails)

It's very interesting to see such different philosophies.

------
Ologn
> Progress over stability

> We have to dare occasionally break and change how things are to evolve and
> grow.

> ...harder to swallow in practice. Especially when it’s your application that
> breaks from a backwards-incompatible change in a major version of Rails.
> It’s at those times we need to remember this value, that we cherish progress
> over stability...

I encountered this doctrine first hand. A division of a company I worked at
had its division's website rewritten in RoR by some outside consultants. Even
brand new, it was a mess of Ruby gems of conflicting dependencies which was
undeployable. The build system was a train wreck as well. Some of the main web
pages of their web sites like rubygems.org were not available - the web site
had "progressed" and when you clicked on a link, the page explaining anything
had disappeared. I mean hell, go to rubyforge.org this minute (1:15 PM EST) -
it is down, of course. The blog of the author of the Ruby gem that then was
the main gem that handled web serving did not inspire confidence.

As I would have to maintain it (as a sysadmin, not programmer), I refused to
deploy the system, since it was an unreproducable mess of conflicting gems and
gem versions and kludges. They decided to pay the RoR consultants additional
money, despite them having never delivered a working system. By the time I
left, it still was never deployed. The division closed dozens of offices soon
after, and then the division shut down - perhaps not completely related, but
probably somewhat related to this project.

Meanwhile, the company's other divisions had decent programmers programming
for Java application servers, and that code and those servers were much more
solid. Builds rolled out easily (and could easily be rolled back if need be).
It was really night and day. It makes sense this contempt for stability is
explicitly part of their doctrine.

~~~
bdcravens
DHH's is talking about the doctrine of the framework, not random apps built
atop the framework.

rubyforge.org has been offline for over a year and a half, as announced over 2
years ago.

You describe a Rails application written by outside consultants that was
undeployable, and compare it to apps written by internal Java developers. I
believe the quality of the developers had more to do with the deployability
than the languages of choice. You could just as easily have a Java application
written by consultants, with undocumented JARs, magical PATHs, mystical
server.xml's to make things work just right, and crazy ant scripts.

~~~
Ologn
> rubyforge.org has been offline for over a year and a half, as announced over
> 2 years ago.

To those not drinking the RoR kool aid, this is toward my point. Two years ago
rubyforge.org was a central repository of Ruby gems. Now it is a web page that
says "RubyForge Could Not Connect to Database:". Of course, in the minds of
some, this does not reflect poorly on _RoR_ but me - I am supposed to know
that two years ago they decided to transform this central hub of Ruby gems to
a web page that says "RubyForge Could Not Connect to Database:".

This kind of thing is par for the course with Ruby. I know that the
[http://perl.org/cpan](http://perl.org/cpan) page I used twenty years ago is
still redirecting somewhere sane, but rubyforge.org ? "RubyForge Could Not
Connect to Database:" \- and the fool is _me_ for not knowing why. This is
typical of the kind of thing you deal with in RoR world.

Insofar as projects - a Java project can be junk just like an RoR project can,
yes. The thing though is that relatively, the core Java infrastructure,
community, API etc. has been much more stable over the past twenty years.

Hearing that rubyforge.org disappeared eighteen months ago to be replaced by
this cryptic message makes me more down on RoR-world than if it was just their
website being down for a few hours. It's the kind of thing you deal with in
RoR-world all the time.

~~~
steveklabnik
Rubyforge.org was a 'central repository of gems' in name only. The transition
to gemcutter, which turned into today's rubygems, happened in 2009:
[http://www.rubyinside.com/gemcutter-is-the-new-official-
defa...](http://www.rubyinside.com/gemcutter-is-the-new-official-default-
rubygem-host-2659.html)

------
tim333
I like the philosophy of optimizing for programer happiness even if it's
imperfectly implemented. I think those kind of ideas have more power than they
are commonly credited with.

------
reaction
Can someone describe their experience with using rails as a back-end JSON API
for javascript apps (flux/react or with angular/ember)?

~~~
awj
We've been happily doing Rails/Ember for about a year now. When we started
Ember Data wasn't as stable or as customizable as it is now, so I don't have
experience working with that.

In general, we've been happy with it. We ended up writing our own serializer
system (similar to ActiveModel::Serializers) to provide legacy clients with
the option to use XML without losing our minds. Rails has a lot of view-level
niceties that we're not using under this scheme, but the rest of the framework
is still very useful for this task.

------
tarikjn
My tool of choice today is Clojure, but I have to thank RoR for teaching me a
lot of sensible conventions that I use in Clojure nowadays.

------
runjake
I think I can boil down all the debates in the comments:

Some people prefer the Rails way of doing things. Others prefer something
else. Nobody is wrong.

------
aikah
> 7.Progress over stability

No real ecosystem can be built on rails since its apis keep on breaking.

That's why in my experience, most people give up on rails.

Stop breaking apis, introduce stability and maybe the framework will be
successful again. People don't give up on rails because of ruby, or because
it's bloated or slow, but because it became an unmaintainable, non upgradable
mess as time passed.

~~~
hawleyal
Show me an integrated framework that is easier to upgrade than Rails.

------
keredson
one thing i hate about rails is writing the database migrations. (i thought:
"why not just define what the schema should be, and let a diff-like tool
figure out update statements?") so that's what i wrote:

[https://github.com/keredson/ruby-db-evolve](https://github.com/keredson/ruby-
db-evolve)

been using it in production for ~1y now.

~~~
morokhovets
I may be wrong but it looks that you just misunderstood what migrations offer
and their usage patterns. What if you have to remove one column and split its
data into two new ones? I can provide dozens of similar examples from my
production code. In short, migrations are not only about schema metadata.

It would make more sense if your gem would generate migrations from schema.rb
changes.

Also, that rant at the end of README kinda shows that you're hating the tool
you're trying to use. Why not use another? You are not tied to ActiveRecord.

I'm not trying to say that migrations are flawless as a tool. I've faced at
least one major problem with them. But still.

~~~
keredson
True, this doesn't do data migrations, and we still write the occasional(1)
data migration when needed. But those are no more difficult to write, and the
much more common non-data migrations are an order of magnitude easier. So net
win.

(1) If your data migrations are not "occasional" (and I mean very occasional)
that's a sign you're doing a poor job at modeling your data. Splitting one
column into two is almost always an example of someone really f-ing up the
original schema.

Think of it this way: how do you switch branches? Do you look up the most
recent ancestor, check it out, migrate down to it, then back up the new
branch? It's so hard I don't know any rails devs who actually do it. But with
a my tool it's a one-line command. PRs w/ schema changes actually get tested
now, not just eyeballed.

Also, did you even read the "rant"? Do you seriously like the proposed version
control tool modeled after rail's migrations? ;)

~~~
morokhovets
I was under impression that you suggest not to use migrations at all. That
"hybrid" approach you just described seems to make sense :) Still not sure if
I'm going to try it in production.

As of occasional (or not) data migrations, it depends on project and its
history. If project is live, rapidly developed and has faced couple of pivots,
migration history will reflect it.

~~~
keredson
Just to clarify, to me "data migration" is just a fancy name for a one-off
script that you run during (or after) a deployment. We don't actually use the
rails migration for it. (Mostly because it would overwrite our schema.rb
IIRC.) But in general, yep.

~~~
morokhovets
So how do you manage these scripts? When deployment is multistaged and
automated you won't just run them by hand. You need system that runs them
automatically and exactly one time at each stage. I can't see why you have to
create a system to manage these scripts if there is good enough built-in
system for that purpose?

If automated deployment is not your case I strongly recommend it. Since I
first time managed autodeploy to work properly I've never looked back. It is
SO convenient.

I may be wrong again about your processes and configuration :)

~~~
keredson
we do auto-deploy, but they aren't required to be run during the deploy
process, so we just run them sometime after the deploy. but honestly i can
count on one hand the number of these we do a year - i haven't put much effort
into streamlining the process. whereas schema changes are quite regular. just
had one tonight in fact. output from the deploy log a few mins ago:

    
    
      Executing in 3...2...1...
    
      BEGIN TRANSACTION
    
      -- column changes for table products
      ALTER TABLE "products" ADD COLUMN "dont_email_on_purchase" boolean
    
      -- column changes for table searches
      ALTER TABLE "searches" ADD COLUMN "tag_only" boolean DEFAULT 'f'
    
      COMMIT
    
      --==[ COMPLETED ]==--
    

from the one line code change that triggered it:

    
    
      1  db/schema.rb
       @@ -543,6 +543,7 @@
      
          create_table "searches", :force => true do |t|
            t.text     "query"
       +    t.boolean  "tag_only",         :default => false
            t.datetime "searched_at"
            t.integer  "user_id"
            t.integer  "page_id"
    

(well, there were two commits obviously)

------
tomphoolery
whoa what the hell is ApplicationRecord?

~~~
thirdsun
The replacement for ActiveRecord::Base in Rails 5. All your models will
inherit from ApplicationRecord. See
[http://nithinbekal.com/posts/rails-5-features/](http://nithinbekal.com/posts/rails-5-features/)

------
of
s/so its only fitting/so it's only fitting/

------
of
Push up a big tent? David Oscarmeyer Heineken is gross! :P

------
xyzzy4
The main problem with Rails is that other developers you work with have strong
opinions about coding style, and they hammer you on code reviews if you don't
code their way.

~~~
shampine
I'm not sure I agree that makes it a Rails problem, more of a developers who
happen to use this tool problem.

~~~
xyzzy4
It's partly a Rails problem because there's a ton of different ways to
implement something, so people will always find reasons to disagree with what
you did. And the Rails community seems particularly over-opinionated about
these things. There's a lot of cargo cult thinking going on when your stuff
gets code reviewed.

~~~
halostatue
…which is not a Rails problem, but an inexperienced developer problem.

------
kaonashi
The worst thing about rails these days is ruby itself. If I'm going to use a
non type-safe language, I may as well use the one that's on the client side as
well (and has first class functions).

~~~
mattmcknight
Ruby procs are first class.

~~~
jrometty
very functional

------
vudu
Everyone who has created their own open source framework which supports a
multi-million-dollar business that now supports your hobby of driving million
dollar race cars, please feel free to cast stones at what rails is and has
become.

~~~
sanderjd
This is a terrible form of argument. Success does not mean you're correct.
Many successful people and things deserve criticism. I don't think DHH or
Rails is among them, but that isn't _because_ they're successful.

~~~
vinceguidry
> Success does not mean you're correct.

Err, yes, it does. That's precisely what success means. If you are successful
at something, that means you did something right. What that something is is
certainly up for debate, but you can't ignore success as an argument.

~~~
blakeyrat
Right; for example if you're a successful pharma CEO you might be able to
afford the one and only copy of a Wu-Tang Clan album.

Unless you define "success" as "being rich", no, I'm sorry, it's not true.
It's actually quite easy to become rich by being a complete scumbag with no
consideration for other people.

~~~
sanderjd
I think a much better, more relatable, and currently very striking example of
this fallacious "rich and famous people must know what they're talking about"
line of reasoning is the current U.S. Republican presidential primary front-
runner.

