

Are Rails and Django communities re-inventing the wheel? - dknight
http://intosimple.blogspot.in/2012/12/rails-in-re-inventing-wheel.html

======
andybak
Here's the comment I left on the article:

"Not everyone is solving a scaling problem.

Django and Rails solve a problem that you can argue is much more common:
writing concise yet readable code without needing reams of boilerplate to
handle common cases."

~~~
andybak
[although I will add this - I did comment on one of the Ruby articles that
sparked this debate that I feel that language communities are repeatedly
solving similar problems in isolation]

~~~
dknight
yes exactly.

It is really sad sometimes.

------
vampirechicken
> Models are intended to serve only as an abstraction to the database. > They
> are meant to be 'models of data'.

TL;DR: MVC Model is Logical model - business object (invoice) with business
logic (delete_line_item), Rails Model is Physical model - persistence layer
for RDBMS (add, update, delete, find rows).

In all but the most trivial applications, the latter assertion contradicts the
former, and the former, is just outright wrong.

In MVC, Models are meant to model the logical objects of the system. An
invoice is an object one which one acts. It is probably composed of several
other objects (header, line items, addresses, etc.) which may in turn be
composed of other objects.

Only the most trivial application have a one-to-one mapping from RDBMS rows to
objects, which is what the OP asserts.

One does not write one's Models with the persistence layer in mind, one writes
them with the business logic in mind.

So to me, this is where Rails gets the name Model wrong. The untrained, just
starting out with rails learn that business logic goes in the model, so there
is goes. But add_address() has no business living int he rails Model file for
the invoice header, because that model is meant to be dedicated to
manipulating invoice_header records in our RDBMS.

~~~
camus
mew , we all lived the Java/JEE nightmare , and pragmatic programmers got us
out of that mess, with no desire to go back to that stuff. I'll take
ruby/active record flaws over the "bloated and unecessary entreprise pattern"
code anytime.

~~~
dknight
It might not be wise to go back to bloated JEE. However, it would certainly be
unwise to leave the knowledge behind. People working in Rails and Django
applications need to learn those important lessons. It can save them from a
lot of common pitfalls. I have seen people using a large number of servers for
Rails applications while similar load is handled by less half their number of
servers using Java.

------
ilaksh
I think that the most important idea may be in the title.

Yes, every new platform or framework reinvents the wheel, because they are
almost all designed to do basically the same things, like CRUD.

I think the only way to avoid reinventing the wheel is to to adopt a common
machine-processable abstraction that is at a higher level than the language
and domain and use that to build the language and platform. Some type of
knowledge representation maybe. Of course I'm not suggesting that is an easy
thing to do.

[http://en.wikipedia.org/wiki/Knowledge_representation_and_re...](http://en.wikipedia.org/wiki/Knowledge_representation_and_reasoning)

------
SiliconAlley
"Models are intended to serve only as an abstraction to the database"

I'm really tired of hearing this unqualified argument. Fat models is not a
creed. It's a practical and natural design choice that we've made because it
fits real world workflows best. Do you really want to be copy/pasting your
order total calculation logic into 5 separate controller actions? Obviously
not. And fat models doesn't mean 800 line source files. On reasonably sized
Rails applications the logic gets bundled into nicely organized and
maintainable concerns.

~~~
dknight
I am not against fat models. However, the point of separating code into tiers
makes it cleaner. The author does approve of concerns. His point is models are
becoming too fat over time and people need to follow techniques like concerns
and use cases to take out business logic. Essentially something already well
known in other platforms is unknown in these communities.

------
kamau
I've been thinking the same thing recently, what with the debates about where
logic goes in Rails apps (was here on HN a few days ago), and the debates
about concerns etc. that I've seen on Rails oriented blogs and twitter
accounts. I'm a .NET developer that has always admired rails (and dabbled in
it a bit myself), but I have to say in .NET land these are all solved
problems, and everybody just gets on with building their apps.

------
benhoskins
Seems to be missing the obvious; ruby and python (with some framework sugar)
will mostly allow you there quicker than writing java with its framework
sugar. I guess the trade off is rather quick to write as opposed to quick to
execute. Interestingly, i also hear my colleagues say this about C and Java.
Seems to be a recurring question of human understanding vs machine, no?

~~~
dknight
Wow. I am interested to know how C is reinventing the wheel. Do tell us more
about it.

~~~
spobo
I think he's saying Java is recreating what C made.I don't agree since Java
allows writing of code at a higher level. (with a garbage collector etc)

Every programming language sort of recreates the basics. They are the basics
after all. The neat programming languages/frameworks are the ones that
'reinvent' something. Do something in a completely new way. On a
programminglanguage-level it's difficult. A lot of the practices were already
invented in early languages like lisp, eifel & smalltalk.

I like Ruby because it's not ashamed of taking the great parts from other
programming languages and putting it together in an easily understandable
language.

~~~
benhoskins
Nope, i'm saying is that the more you abstract and take out of the way of the
coder, the quicker they can write code. Java did this to C type languages, and
people got quicker. Ruby and python did this to Java. But the inverse im often
told by my C colleagues is that the abstraction means you fundamentally lose
control of performance. I don't agree with this statement, but what I do agree
with is that if you want high level, human oriented lprogramming languages
that you can quickly write code in, you need to solve very similar problems

------
wriq
Possibly, but like most technology there's is a set compromises you're willing
to make. Rails and Django seem to be focused on getting something up and
running ASAP and then dealing with whatever scaling issues you're going to
have when you know exactly what they're going to be. Face it, a good amount of
webapps out there won't need to be sharded. 37Signals just threw hardware at
basecamp for a while (they still do?). Instagram made a few tweaks to django
once they started growing rapidly, same with Disqus and i'm going to assume
Pinterest did something similar as well. I would focus on the product rather
than how to scale it in the early on. Once you hit the point of "How am I
going to deliver this product to a group a users an order of magnitude high
than I am right now" you'll hopefully have good test coverage and be able to
make the right choice among sharding/read-slaves/better caching with the
metrics you're able to collect.

~~~
camus
I agree, if you dont have a product up and running at first place, how your
non existence app scales doesnt matter.

------
rbut
"Django, the most advanced Python framework for web applications is yet to
come at par with it."

In what ways is Django sub-par compared to Rails?

------
axlerunner
The latest Java/Spring/JEE platforms are much more lightweight than they were
5 years ago. Look at annotated JAX-RS and you'll be amazed. You defectors
should really give it a objective try. Nowadays us Java guys can focus on
building our applications because our frameworks and APIs are so mature.

------
EugeneOZ
"Models are intended to serve only as an abstraction to the database. They are
meant to be 'models of data'."

It's about Ruby or common? Because I'm sure Models could have 0 code of
working with database and business-logic only. It depends on architecture of
project.

~~~
dknight
Model classes in Rails inherit ActiveRecord::Base. So, you can call a class
method like update_all which is equivalent to an update statement on the
table.

'Models could have 0 code of working with database and business-logic only'
Well the business logic creeping in is one of the issues here. That is why
there are attempts to separate out the business logic as in case of the use of
/app/use_cases [refer to the link of use cases in the article].

~~~
philwelch
There's nothing forcing your model classes to inherit ActiveRecord::Base. It's
perfectly acceptable to use other ORMs or even bare Ruby classes as models. If
the only thing you want to do is database operations, ORM is a waste of time
anyway.

