And based on the author's previous Django and ORM posts, I look forward to the next post in a few months when the black magic stops working and they begin to hate on Rails as a framework.
Yeah, there is a non-zero chance of that happening. However, I keep discovering more and more Rails design choices that either match or closely align with my preferences.
The three biggies comparing to Django are:
1) Powerful templates (including the convenience of "Helpers")
2) Non-declarative schema ORM with full migration support
3) Form validation and generation with Rails doesn't suck
Lastly, Rails feels battle tested and production ready. Everything from the Rake tasks, to the framework surface area, to the plugins available seems tuned for real applications. Python stacks I have tried often require a lot of hackery to handle server configurations, deployment, content builds, template helpers, ... the list goes on and on.
I think you and I both know - once you've run with something long enough, you hit a wall. Everything - every language, framework or tool hits a wall. You hit yours with Django because you fundamentally disagreed with some of the design decisions. I personally have not hit my wall (with django) but I see plenty of room for improvement.
It's awesome you built something so quickly with Rails - I have a similar experience with Django (a tiny amount of time to build a really deep application).
I personally found it amusing/bothersome that you were lauding a fairly magical and opinionated framework when you had old posts deriding Django (and it's ORM) in the past.
I like opinionated software. Especially when it matches my opinions. And if it doesn't match my opinions, it is easy to dismiss it.
It isn't the magic about Django (and it's ORM) that I didn't like. It was the design decisions that didn't match how I think (and approach of declaring the DB schema in code).
We (mostly) agree then. The non-opinionated stuff makes me 1000x more angry then something silly like lack of class-based views, or the inclusion of GIS in contrib (for Django).
I was probably overly sarcastic in my original comment, so for that I'm sorry.
Nice try; but having more flexibility can be just as damning as not enough. Me, and plenty of others, have found that we know where, say, Python's wall is and accept it or we go around it. The wall I'm talking about is the mental barrier where you either no longer want the tradeoffs involved, or find you disagree with a fundamental axiom of the thing under inspection. Drilling through it is impossible without discarding it entirely.
Having flexibility to drill through that wall just puts a bigger, harder wall someplace else. And other people find Emacs/VIM ideas perfectly workable IDEs, and find the flexibility of Emacs and VIM horribly confusing.
You have to know, and accept the wall and limitations - it's a series of tradeoffs, and you just need to know what you're getting in the trade.
In the case of frameworks, it's just a bigger set of tradeoffs as they tend to be a lot more opinionated, which means you're trading more for comfort.
Emacs is use optimized, not learning optimized. It takes lots of time -- if you don't use it for hours a day, it is probably not worth it.
Org mode in Emacs is a good example. It took embarrassing long to learn for me -- while the GUI variants (e.g. gjots2) are trivial.
But now, I can take notes and doodle with Org mode that I could only do on paper before. It is built into my fingers in a way which IDEs/GUIs failed for lots of years.
I'd argue that Emacs is without a wall for programmers. (-: As long as you don't want to do word processing with WYSIWYG. :-)
The problems will be new areas, like how will text understanding libraries (theoretical concept, not in that area) integrate with Emacs compared to others.
You could probably do the same arguments for Perl and Lisp. But I don't know any framework I'd say the same about.
Edit: Thinking back on my life, I'll yield the point re frameworks. Not libraries, for a not too large problem (a pack of collected libraries would have a wall in a bad Big-O for complexity/time).
Edit 2: You could put my argument to be that the last decades of history shows Emacs to be, for all practical [programmer] purposes, infinitely flexible -- as long as new functionality can be integrated to the normal Emacs usage. Which is a big caveat, yes. Org isn't the first generation of that kind of note taking modes in Emacs, the evolution was afaik in much how Org was used.
Emacs might be insanely flexible, sure, but at what cost? Bloat? Infinite complexity? Heck, I get frustrated with my VIM configuration sometimes because I forget the less used keybindings when I really need them, and need to go spelunking.
So sure; if you're willing to trade the up-front investment of time (not insubstantial) Emacs will go far - and the wall is way off on the horizon and someone scribbled "complexity" on it.
Up-front investment can't be underestimated; there's a reason why things like Textmate (which starts simple, and grows out well) are so popular. Low initial investment, and plenty of ramp, and it works out well until it simply doesn't.
That low initial barrier is easier to climb, and while emacs (or even VIM) might have a wall that, when compared to Textmate's, is infinitely far away, textmate will still have fantastic adoption. The wall textmate has is further off then most people are willing to worry about.
For most people, a framework, like, say, Django or even Rails offers a wall far enough out that most people don't need to worry about it, but when they hit that wall, they're going to hit it hard, and kinda be mad.
You're mostly rewriting my points. Let's leave this for half a year and discuss it again. It seems we both need to let it fes.. think about it. :-) Or at least I know I do.
What I'm trying to say, I think, is that there is a tension between flexible/pluggable frameworks and integrated ones, like with e.g. Emacs and simple IDEs. (Yeah, there are IDEs on top of Emacs; those doesn't remove complexity.)
(The main complexity problem with Emacs isn't the code which is neat with the lisp layer (imho, I'm very far from being a real Emacs hacker). The complexity is use complexity -- lots of modes, etc. More broad than deep.)
But unless some totally new idea comes along, people will use Emacs when we both have forgotten the present frameworks...
>>I get frustrated with my VIM configuration sometimes because I forget the less used keybindings
I haven't used vi for quite a few years. There is still no good search/browsing/M-x? Never mind, some really good people use vim, so I assume there is something there.
I worked with both Rails and Django and I like Django's approach better ... simply because the fields declaration is higher-level.
I.e. you don't have a "filepath varchar" field, but a "photo=ImageField(thumbnail_size=[320,200])".
I've had a good experience with South for database migrations, used it in every Django project I tried ... the only things bothering me is that the generated files are too verbose (not much of a problem, since you don't need to modify the auto-generated code), plus a migration-based system doesn't really blend if you've got multiple apps in the same project (refactoring becomes painful).
Other than that, Rails is pretty good because of its declarative APIs. Django has too much boilerplate for my taste ... but I like that for complex projects where I need to tweak things.
I can't disagree on ORM and templates (I disagree with the lack of proper method invocation in Django templates, it annoys me having to create tags for trivial things). I kind of disagree on the form validation though. Having used a number of frameworks prior to Django (including Rails for about a year), I love the way forms are handled in it - it just seems to make sense to me.
3) I don't understand how anyone can prefer another framework's form tools after using django.
Like others have said, considering your past posts, it's just a matter of time before you starting hating Rails. To each their own, but I don't see any of your points as being a valid reason to like Rails over django.
I don't want to get into a framework war or anything -- in fact, I'm a Django developer currently after several years working with Rails, and relatively happy with the switch.
That being said, both #1 and #2 above are plain wrong.
Django template tags are a PITA to write, have weird inconsistencies (largely due to the first issue causing them to be implemented in a very hack-ish way) and don't have access to any request or application state that isn't explicitly added to the template context. Rails template helpers are powerful, easy to write, and ubiquitous. Those properties also make them easy to abuse for functionality that should absolutely be in a model or view function.
South, on the other hand, is powerful, complex, and not part of the Django core. That simple fact immediately makes is less useful. Any Rails developer (and by extension, any Rails codebase) will be familiar with AR migrations. No extra dependencies, training, or versioning issues to worry about.
I mostly agree with #3, though I definitely still find some funky edge cases with Django form validation. They aren't a terribly gently introduction to the "Right Way" of doing form handling for someone more comfortable with HTML than Python, either.
You make some good points. I've always felt that if your template tags are doing too much, your front-end is getting too bloated. That kind of logic should be left to your models/views. I know there's a lot of disagreement in the community over the lack of real Python code in your templates, but it just encourages sloppy spaghetti. Forcing you to not rely on advanced logic in your templates makes you a better developer.
I do agree that migrations should be a part of core/contrib, given how common of a use case they are. I don't agree that it makes it less useful. You need plenty of gems to get Rails to satisfy many common use cases. No framework plugs all the holes, you always have to extend. Both django and Rails make getting and using those extensions hilariously easy, so there's really no barrier to entry for any developer.
> I know there's a lot of disagreement in the community over the lack of real Python code in your templates, but it would just encourages sloppy spaghetti.
You'll see a lot of this in the Rails community too; lots of people use haml over erb for exactly this reason.
Can you elaborate on the non-declarative schema point? With something like Django's South handling migrations, what problems does the declarative schema introduce that Rails side-steps?
It is a subtle, but fundamental distinction: Django expects me to declare my schema in Python. Rails (and optionally SqlAlchemy, which I like) operate via schema reflection. The declarative approach is redundant, error prone, and resistent to migrations, even with South. The reflection approach matches what you'd do with a bag of Bash scripts in the absence of any framework; as such, it works better in a real world deployment.
Having used both (though Django much more heavily) I don't see any practical differences between migrations in a non-declarative system (Rails) and a declarative one (Django). Migrations are always a bit of a pain, but database changes (at least to any field managed by a framework) will almost always require code changes -- so what are you gaining by leaving the field declaration out of the model?
I'd say that the declarative syntax is actually a bonus. It makes the code much more discoverable, and I haven't seen a real downside.
The declarative approach is only redundant if you're inheriting a project, and even then it's only redundant that first time you mirror the existing db schema in Python. How can you call a declarative method redundant and not schema reflection? They're reverse processes of the exact same thing.
The only "errors" I can think of that can arise from declarative over reflection is when someone decides to manually fuck with your database while ignoring your framework's tools. And even then, South basically handles every use case. How exactly do you think South is resistant to migrations? Updating your models.py and running two manage.py commands seems pretty damn straightforward to me.
"The reflection approach matches what you'd do with a bag of Bash scripts in the absence of any framework; as such, it works better in a real world deployment."
So, you're saying that because one way looks like what you were doing before a framework, it's somehow "better?" What kind of backwards logic is that? It's basically the definition of abstraction.
I understand the need to have the schema where it's being used but if you ever need to make modifications like custom fields (say an email field) then your schema isn't just stored in the DB any more. With Django your custom field declarations live in the same place as more mundane fields. If you port that models file to another machine and run syncdb you are going to be left with the same schema with the same restrictions.
This reply could be to the majority of comments on this post, I just chose yours because it's the first one.
I'm pretty disappointed with HN being party to the same smug, knowing, tongue-in-cheek Rails (and to a lesser extent, Ruby) hating that you constantly see on Slashdot and elsewhere. There are merits to Rails, and also drawbacks, as there are with every tool. It isn't magic, or anything close - the code is all there for you to read, and it is just Ruby, no pixie dust anywhere.
He's not 'hating' on rails, he's just indicating that there is a period when you use something new that you think 'wow, this is great' when after the shiny newness wears off you realize that there is plenty to be improved.
Calling it a honeymoon period is not too far from the truth, everything seems rosy and pretty.
Yup, also "If you cannot name at least 5 things you dislike about the tools and languages you use you're either in the honeymoon period, or irrational".
As I commented elsewhere in this thread; god knows Python/Django/Zope/Etc have plenty of things to improve and get better at.
> I'm pretty disappointed with HN being party to the same smug, knowing, tongue-in-cheek Rails (and to a lesser extent, Ruby) hating that you constantly see on Slashdot and elsewhere.
I don't code Ruby, so maybe I'm not as sensitive to these things, but I haven't noticed this here at all.
RoR allows lots of HN-types (hackers, people prototyping web business, etc.) to build products quickly. In fact, that's exactly what TFA is an example of.
I'm actually constantly surprised at the number of HN readers who seem to hate on RoR out of general principal.
A lot of the HN crowd dislikes PHP, and can point to dozens of reasons why: no consistency in the standard library re: naming conventions, order of arguments, etc; poor abstractions; up until recent versions, a lack of namespaces or late static binding, and so forth.
A lot of the HN crowd seems to dislike Rails, but I've never once seen someone post a objective reason why. Philosophical differences I can see -- maybe Rails isn't for everyone. But the majority of the anti-Rails posts are FUD at worst, and misinformed at best.
I had really quite a good one with Django, which clicked to me in a way that Rails never did.
I miss scaffolding though, as I think that was the 'killer app' to RAD, but I'm to the point where I feel like even my simpler apps feel constrained by either Rails or Django at this point (though I'm probably just not knowledgeable enough), and have started doing everything with Tornado and SQLAlchemy, which, while they're currently kicking my ass, doesn't give me any sense of constraint whatsoever.
Of course, upper bounds have always been something that bothered me, even when they were realistically well about my own limits. When I was learning to play guitar, I went out and bought a Les Paul, for the comfort of knowing that whatever else goes wrong, I can't blame the tool. In reality I know that only poor craftsmen do that, but every time I get stuck trying to remember the 'Django' way to do something, I feel like I'm in a box I want to climb out of.
This kind of attitude makes me keep looking for ways to move away from Python-land. The new "we're better than everyone else" attitude is seriously grating. I like writing Python, but it sucks seeing this kind of crap every time I go into a mailing list or just about every other public programming forum around.
What feels like aeons ago, python-land created the huge monolithic monster, the Zope framework, which was absolutely great at the time. Then people were bitten by writing classes that would unexpectedly manifest some behaviour "as if by magic." The problems became (1) determining whether you would one day out of the blue have code "act weird", (2) figuring out where this behaviour was coming from.
Save to say, many people got bit/burned/scarred. Lessons were learned. There is a fair bit of cross-polination going on; I can't think of any python framework that has not tried to learn from this, and also from the successes/challenges of others (and that includes those of Rails btw).
So when a "battle scarred veteran" makes a terse statement such as this, I don't think by any means it expresses a "better-than-thou" attitude. But you can understand why there might be (rightly or wrongly) an anticipation of pain to come.
When pythonistas look as Rails (for example) and say "hmmn, this pattern looks sort of familiar, wonder how they're going to avoid that type of pain we had", surely this is neither unfair nor over critical, it's just part of the technical dialogue that ultimately advances everyone's "state of the art."
And I don't think anybody in the python world really claims to have the "one true answer." Rather it's more the case of "there is no one true answer, only many flawed attempts; so if you think you've found nirvana, be prepared for some disappointment down the road."
Generally people acknowledge that it's a difficult problem and that we're all dealing with variations of the same issues, irrespective of language or framework. A bit like a balloon; you can squeeze it in one place to make it "thinner" there, but likely it will pop out some place else.
I probably wouldn't have had such a strong reaction if the comment hadn't started with "And based on the author's previous Django and ORM posts" as though the author is incapable of making technical decisions because he didn't like some aspect of Django previously.
Between that, and the regular stream of ridicule about Rails , Node or just about anything else not Python it just seriously rubs me the wrong way. I don't see anyone changing my opinion of that; nor am I asking them to.
I have seen (for virtually every type of interesting technology ever) two classes of people (at least):
1. People who've somewhat recently discovered it, and realized how powerful it is. Not really surprising to see that people in this category would argue their tech of choice over next to anything out there; both because they're enamoured with what they've discovered, and also because it helps validate their choice.
2. People who've gotten past stage 1 and realized that everything has limitations. These people are far more pragmatic and will tend to seek the best tool for the job. Sometimes what they say may appear to be acerbic, often this is because it attempts to express the "there is no magic bullet"-conclusion that they've reached.
Can guarantee you that Jesse does not fall into group 1.
Also, I think in the above if you substitute "tech" for "community" the same will hold true.
Ultimately these are all just tools in the toolbox and people in group 2 acknowledge this irrespective language/framework/community.
I was being sarcastic; and if you cannot name at least 5 things you dislike about the tools and languages you use you're either in the honeymoon period, or irrational.
This includes fellow python-oriented people. Myself included.
"... if you cannot name at least 5 things you dislike about the tools and languages you use you're either in the honeymoon period, or irrational."
This is one of those things that sounds true, but falls apart on further inspection. Aren't you allowed to genuinely like your language or tools?
Obviously there are tradeoffs with using any implementation of anything, but people can be completely satisfied and happy with their tools without being starry-eyed morons ...
This is one of those things that sounds true, but falls apart on further inspection. Aren't you allowed to genuinely like your language or tools?
Yes, plenty of people genuinely like their languages and tools. However every language and tool has warts. You simply cannot build something that complex without either making mistakes that you can't reverse, or else making trade-offs that aren't going to fit someone else's use case. Plus no language or tool can fit every good idea, so it is in the nature of the beast that there are good ideas that simply didn't make it in.
If you have not found those things yet, then you don't know your language and tools that well. Or else you don't know what is possible with other languages and tools. (That is the essence of the blub paradox - see http://www.paulgraham.com/avg.html for a detailed explanation.) Either way your opinion on how your language and tools compare with others is useless to more experienced people.
Heh, I understand the Blub paradox quite well. And, as I acknowledged, everything has design tradeoffs or even mistakes. Just because there are design tradeoffs or warts, doesn't mean they rise to the level of active dislike.
For instance, most implementations of Ruby are relatively slow. Do I care? Generally, no ... certainly not enough to say it's something I "dislike." It's entirely possible to build tons of web apps (for example) and never bump against any language "mistakes" or "tradeoffs" that are relevant.
"Dislikes" may be stronger than you want, but would you agree if it were changed to "recognized shortcomings"?
Let's use Ruby for an example. You discounted performance because it never matters in web development. Fine. Here are 5 more issues that do come up in web development. Not using native threads makes it easy for a poorly coded C extension (for instance a database driver) to block all threads. Common classes of errors (eg typos in variable names) can only be caught at run-time. Some widely used libraries use monkey patching, and with dependencies it is very easy to pull one in without realizing it, only to get burned later in what should be an unrelated library. By default gem does not run unit tests at installation, which makes it less likely that developers will get prompt feedback about issues like platform-specific code or unspecified dependencies. While mix-ins are convenient, they provide opportunities for conflicts and make it harder to track down the source of a method when you're trying to debug something.
I don't even use Ruby very much. If I did, I could easily come up with a much larger list. (My primary language is Perl. You should see the list of complaints I have about it! Yet I still like it. And for the record I like Ruby as well.)
Edit: I only included 4 issues initially, so I just added another.
Maybe dislike is too strong in your vocabulary - but in mine it's "things I don't like; and would not cry if they got better/changed tomorrow". I'm not talking about hate here - sure, people are able to uncompromisingly happy (as I am, when I'm working on python) but the poster above pointed it out - If you have not found those things yet, then you don't know your language and tools that well. Or else you don't know what is possible with other languages and tools.
So, attribute any emotional level you want - in my book, dislike is far from hate, and means you would actively work to change the item if question, if given the power.
I love working with Python, with Django, with Linux/OSX, VIM, Textmate, etc, etc. I love working with them, but each has it's failings, and it's important I know them. Sometimes knowing your own limitations, and those of your tools, and thinking critically about both is the most important skill a person can have.
Probably, it's really as simple as challenging your assumptions, and striving to be better, or make better things. Hell - it's what drives most entrepreneurs.
By "something" do you mean Ruby itself, or the fact that most Ruby implemenations are slow? If it was the former, then I think you're responding to the wrong statement. The statement was about "5 things you dislike about the tools and languages you use". So it wasn't about disliking Ruby itself, but rather things about Ruby.
If you were indeed saying that you don't care enough about the fact that "most implementations of Ruby are relatively slow." to raise that fact to the level of "dislike", well, I guess I find that hard to believe. I mean, sure, it generally won't matter. But even if it only matters a small portion of the time, what is there to "like" about implementations of a language being slow? Wouldn't you always dislike that fact, even when it didn't particularly matter in most cases?
Aren't you allowed to genuinely like your language or tools?
Not of that means being blind to its shortcomings. I love my girlfriend, but that doesn't mean I can't name 5 things that sometimes annoy me about her.
but people can be completely satisfied and happy with their tools
You can be satisfied and happy while still sometimes cursing at shortcomings. I love coding in Ruby, but the state of affairs concerning documentation and where to find gems is appalling.
(BTW: upvoted for having a valid opinion. People, please don't downvote below +1 just to disagree.)
If you're not saying he said that, why leave the comment in reply to him? Either you think he said that (or conveys that attitude), or your comment is blatantly off-topic.
> This kind of attitude makes me keep looking for ways to move away from Python-land. The new "we're better than everyone else" attitude is seriously grating.
Wow. That sounds exactly like you're talking about Ruby/Rails.
