So, I was reading the little snake that couldn't, a pessimistic post on Python web programming by Ivan Krstic. I was rather annoyed by his Frankenweb post, but never replied to it since I figured I'd just be pissy. So maybe this will be an indirect reply to that too.
First, a point of correction: I'm not developing Pylons (as was noted in a Tim O'Reilly post), but I'm working with the Pylons developers as they are using Paste quite heavily.
Like one of the commenters on that post, I also agree that Rails is good for Python. Rails is doing a good job at describing a kind of development that Python is good for -- small numbers of good programmers making a product quickly and well. And to quote Ivan: 'If Rails has its way with the web, 2006 will be dubbed "the year of the anti-enterprise."'; that's a-ok by me too. So I think I'm on the same page as the Rails guys when it comes to basic motivation and techniques.
So, insofar as Rails is convincing people that they can do projects with small teams, with simpler goals and simpler results released in smaller iterations, that's good for Python. And yes, Rails has been a much-needed kick in the butt for Python web programming, which was not being driven forward as it should have been, and not payed enough attention in the Python community. (Incidentally, Guido was just hired by Google, so hopefully we'll see some web needs given a little more attention in the core.) Python frameworks might not have the buzz that Rails has, but they didn't before Rails, and they are doing better now than they were before, so we really shouldn't complain.
Anyway, back to the post:
Point the first: if you're writing a Python web framework that will out-rail Rails, please give up now.
No problem, no one is trying to do that. Really, not a single one. Subway was in the beginning, but they stopped really trying to do that a long time ago (incidentally it looks like Subway will merge with TurboGears).
A Rails-like Python framework with best-of-breed Python components will never be mainstream, and will never be better than Rails: it'll just be different. More Pythonic.
I, for one, like "Pythonic," and not just in terms of the particulars of whitespace or punctuation. Rails isn't Pythonic, nor is Ruby. It's not the anti-Python either, but there are real differences in philosophy, and I think Python's philosophy is ultimately better.
Also, I think Rails risks some serious risks of taking a Zope-like turn, with more risk specifically because of Ruby. Zope added one Really Bad Idea (Acquisition) that killed one of Python's best features (locally understandable code and general backtrackability). There were some other bad choices (TTW, in-ZODB code, lots of mixins and subclassing); but the worst of the choices were enabled specifically because of Acquisition. If you don't know what Acquisition is, think of it as crazy attribute dynamic scoping.
Ruby doesn't have Acquisition, but it also plays loose with classes and interfaces in a way that makes code hard to understand locally. Of course nothing is inevitable, but there's risk. And the first generation of programmers is usually enthusiastic; any failure is a personal failure, so you can gloss over those things. It's the second generation that's going to be less enthused, that's going to stare in bafflement at these classes that mysteriously spawn methods, and trying to figure out what's going when there's an exception in dynamically generated code. You can monkeypatch code in Python pretty easily, but we look down on it enough that we call it "monkeypatching". In Ruby they call it "opening a class" and think it's a cool feature. I will assert: we are right, they are wrong.
That's a risk for Rails, but we can't just hang around and hope to catch people who drop from Rails. But Rails is hardly answering everyone's needs. And no, Seaside isn't answering every need that Rails isn't answering.
Python has an opportunity to do something Rails isn't trying to do, that DHH specifically doesn't want to do: create a heterogeneous web programming environment. The "Frankenweb" is a feature, and it describes the web we have, the software we have, and the future that is inevitable. The world was never all J2EE, or ASP(.NET), or PHP, and it won't be all Rails either. The Python web framework diversity is just a microcosm of that; it's not necessarily good, but neither is it necessarily bad.
There's a certain hubris to the idea that a framework should not reuse external code (something that both DHH and Adrian Holovaty basically asserted at Snakes and Rubies). Yes, you can get by without using other people's code, and often you can make it work fairly quickly and on a timescale you control, and the specific gains you get from reusing code may not match your initial expectation. But there's also a presumption that no one else is ever going to make code worth using, that you will always be the cutting edge, that you can assimilate every idea without assimilating any code. But you just can't be the cutting edge of everything; and once you aren't, people have to choose to stay or to go.
Well, people don't have to stay or go, but they will if you don't have a plan. Frameworks can fit together, but it's hard. It's hard, but it's good exercise. The project that is reusing code right now will be able to reuse code in the future.
That's one thing Python can do. Another is actually try to pick up where PHP leaves off. Rails doesn't do any of the stuff that PHP does well, it merely provides a landing spot for disaffected PHP programmers. The beauty of PHP is that they are constantly sloughing off disaffected programmers, and yet their numbers still grow. (If PHP is wrong, do we want to be right?) PHP grows because there's lots of useful applications -- some quite good, but you don't even have to be good to be useful. You install an app, you customize the app, you realize later you are a PHP programmer. There's other good features too, but anyway, we can provide useful applications that don't require an understanding of the framework to install and start customizing. The last system like that (before PHP) was Perl CGI; and they did pretty damn well for themselves during that period. Python can be the next system like that, and hell, I even have a plan. (Zope 2's growth was very similar, applications first, but Zope 3 is not at all like this. But it could be! My plan includes everyone who wants to participate! I love you all equally!)
And that's only like two ideas. Rails has a message, and it has an implementation that fulfills that message. That's not bad, it's certainly working out for them. But if you think that's it, that there's nothing left to work on, then you sorely lack imagination.
Great post. I nominate a quote of the week: "But if you think that's it, that there's nothing left to work on, then you sorely lack imagination."
Incidentally, I think the "monkey patch" term originated as follows. First it was "guerilla patch", referring to code that sneakily changes other code at runtime without any rules. In Zope 2, sometimes these patches engage in battle with each other. This term went around Zope Corporation for a while. People heard it as "gorilla patch", though, since the two words sound very much alike, and the word gorilla is heard more often. So, when someone created a guerilla patch very carefully and tried to avoid any battles, they tried to make it sound less forceful by calling it a monkey patch. The term stuck.
Great post; seconded. +1.
Python and Rails are so much better than Perl and Java, in so many ways, that I'd be ecstatic to see them both continue their growth.
They're both open source. They're both easy to read and easy to write. They both have good support for OOP and functional programming ideas. They are both easy to learn, especially if you are already a programmer.
Why does everyone feel the needs to treat this like an either/or proposition?
I've worked with Python for 5 years, am teaching myself Ruby (and Rails) and plan to incorporate both into my toolset.
If I was starting a program from scratch, what language would I use? It depends on the problem I'm solving -- and that should always be the answer.
I think the battle is over your last sentence, because the appearance is that there is this huge class of problems people are solving that are all "the need to build a database-driven website". And python people freaked out by Rails are seeing an apparently large number of people facing that problem statement evaluating the tools and choosing Ruby/Rails over Python/X, which apparently calls into question the freaked-out person's own choice of Python/X for their own specific website-building problem. In many cases it's valid for them to doubt their own choice (just because it's a herd doesn't mean it's not also a great tool), however painful that realization.
But it's also probably the case that the problem statement is too broad and too short-termed, and in my opinion it is almost certainly the case that neither Django or Rails with their "complete self-maintained stack" mentality are likely to hold onto the title of best tool as long as they might have otherwise.
BTW, Django is including PyDispatcher (maybe replaced with louie for setuptools goodness), and is soon to include Dojo. My position is that reuse is good if the code you are reusing is good, and fits into your existing way of doing things. But unlike some TG advocates seem to, I don't think that reuse alone will save the world.
Brilliant as always. Open classes turned me away from Ruby as well, but I never had a concise shorthand for that violation of locality and readability. Monkeypatching - just so.
# John Dell'Aquila
Do you not still see lack of "commodity" hosting as a hurdle? That's always struck me as one of the biggest reasons for first Perl CGI, then especially PHP's rise to ubiquity.
This general case that web app development with python/ruby/(non-CGI)perl and friends has and still for the most part requires dedicated resources (mod_perl, FCGI, SCGI, etc.) has seemed to me to put them in the "non-trivial to deploy" category along with Java (and MS stuff(?)) ["deploy" in the find or config and setup a server and hosting and so on].
I'm guessing the plan is based around paste and wsgi and similar, which seems a good way of handling/building the ecosystem of pluggable apps and so forth, but what do you think about the deployment issue? A non-issue? At first I thought like many you're thinking more of those who can run their own servers, but since you specifically mention PHP I think this is a key point that would need to be addressed, no? Some ISPs are starting to offer FCGI and other options, but I'd say it's still pretty experimental based on the problems many have been having. Just wondering if and what you've thought of this area in your plan of attack...
Do you not still see lack of "commodity" hosting as a hurdle? That's always struck me as one of the biggest reasons for first Perl CGI, then especially PHP's rise to ubiquity.Absolutely; that's part of my plan! Perl CGI was one step; PHP was a different step (notable mod_perl is vaguely similar to mod_php, but the results are much different -- mod_php feels like Perl CGI in important ways). I think the next step will look similar to the app servers we have, but feel like PHP.
I'm guessing the plan is based around paste and wsgi and similar, which seems a good way of handling/building the ecosystem of pluggable apps and so forth, but what do you think about the deployment issue?I have some ideas, written about here and elsewhere, and I'll try to actually follow through on describing the full plan after Christmas. But yes, deployment definitely matters, and I think there's several tools (most of which exist already) that can work together to make this work well. A lot of them aren't even Python specific. The recent Zope TTW discussions have some important ideas in them as well... the plan shouldn't just be plug-and-play, but plug-play-fiddle-plug-fiddle-play, or something like that. We have to invite users into the development process like PHP (and Zope TTW development) does, but also help teach them about basic development methodology.
# Ian Bicking
Todd,
I absolutely agree on this commodity hosting issue. Many "mainstream ISPs" for example don't support mod_python. And those that do are often more expensive. For many hobbyist programmers this is a clear advantage of PHP.
Regards, Roman
# Roman
"For many hobbyist programmers this is a clear advantage of PHP."
Hmmm... a think a hobbyist is someone who does something for fun. I don't think PHP is fun at all. On the other hand, Python is a lot of fun.
Todd,
I absolutely agree on this commodity hosting issue. Many "mainstream ISPs" for example don't support mod_python. And those that do are often more expensive. For many hobbyist programmers this is a clear advantage of PHP.
Regards, Roman
# Roman
Isn't the problem with mod_python that python modules are writable? That makes shared hosting infeasible, since hosters are either faced with:
- purging all modules in between requests
- running apache in a separate process for each user
In contrast, PHP's modules are not quite as dynamic, being largely c extensions.
Perhaps someone familiar with hosting Python should come forward and identify current technical barriers to wider adoption of mod_python. Once these are solved, it should be easier to deploy python-based bulletin boards et c.
I'm pretty sure you said a good amount of this when we chatted at Monk's, so I may be regurgitating more than I think, but here are the two key things from this post for me:
- First-generation vs second-generation. I feel somewhat mean-spirited always bringing up the Zope/Rails comparison, but the Acquisition example is good not just because it is a philosophical hurdle we seem to have moved beyond. When I was first introduced to Zope, every fan I talked to trumpeted Acquisition as a good thing! As you say, it is the second generation of programmers who question these things, because for the first generation things are new and wildly better than where they were. Not sure if this first vs second thing is something you sourced from elsewhere, but I'll clarify it for myself: it's not neccessarily about different sets of programmers, you can have a second-generation experience after being a first-gen adopter as soon as you inherit someone else's significant project written with a different set of assumptions from your own in the same framework.
So many other salient Zope comparisons, not all negative. I'll highlight one other as a possible future: I would not be surprised to see Ruby web development take a similar path to what we've gone through in the python world. Zope was THE web framework for Python, and brought a lot of new people to Python. Perhaps because of the second-generation issue, perhaps because of other differences of opinion, other frameworks start to gain traction and we ended up with the fractured web landscape that people are whining about today. Strangely, up until Rails it seemed like the Python community had come to accept the conclusion that a diverse set of frameworks was OK except that we obviously couldn't answer the generic question "I like python and I want to make a website". The python web world had disintegrated into a variety of tools with mildly different strengths and moreso different philosophies. Which leads to:
- Fitting together components and frameworks. Some people seem to think the solution to the fractured landscape is to build a new complete-stack system. But that's precisely the reason I expect Ruby to end up in something like our current state. Turbogears/Subway are taking the next-best step of combining components, and I think it's logical and worthwhile. I think they will be more able to adapt and incorporate new ideas than the monolithic systems, and therefore less susceptible to dissolution because they incorporate the reality of disintegration as part of their design strategy.
But I am moreso in your camp, that being able to create a mixed stack of frameworks is the third step and the only one that is wholely based on the conclusion that integrating disintegration shouldn't ignore the differing reasons that lead to that disintegration.
In conclusion, quotes from your post: "The 'Frankenweb' is a feature, and it describes the web we have, the software we have, and the future that is inevitable." And: "The project that is reusing code right now will be able to reuse code in the future."
Also, I was going to say something about Acquisition reminding me of how DRY has some nuances to it that often get left of the picture in favor of primarily avoiding any duplication of typing - fits in with the SQLObject/ActiveRecord pluralities thing too. But no time now.
Fitting together components and frameworks. Some people seem to think the solution to the fractured landscape is to build a new complete-stack system. But that's precisely the reason I expect Ruby to end up in something like our current state. Turbogears/Subway are taking the next-best step of combining components, and I think it's logical and worthwhile. I think they will be more able to adapt and incorporate new ideas than the monolithic systems, and therefore less susceptible to dissolution because they incorporate the reality of disintegration as part of their design strategy.While I agree, I should say that this doesn't somehow invalidate efforts to build good APIs and frameworks on the level that TurboGears and Django are working. That still needs to be done; this is about enabling that kind of work, not superceding it. Nor does it invalidate efforts to provide a complete development story, which is what both Django and TG are doing; it's just notable that TurboGears is doing that without having developed each piece that is part of that story.
# Ian Bicking
Good clarification.
While I want to support the idea that it should be a natural thing to integrate an existing app/sub-app or to develop a piece of your system in a different framework/language because it is by far the better tool for that purpose, you're also right that having a complete story is preferrable in a large number of situations. The reaction I'm having is because Rails and Django (and at a only somewhat different level, TG) so far don't seem to be considering (or are rejecting) the heterogenous reality you refer to.
But maybe I've also been ignoring the point of your plan, which is that this is all perfectly fine because we won't need to convert the philosophies of any frameworks (an effort bound to fail), we're just going to create an interoperability between frameworks (including frameworks that haven't been written yet). So there only has to be agreement on how to integrate, no agreement on how much or how little or how best to do things inside a framework. Someone looking for a complete story in a style they like can be happy there, but not have to give that up when they want to add something someone else wrote in a different framework.
Right?
Right; you shouldn't force people to reuse and share code. That's just another name for a big all-encompassing framework. Well, you do have to force it on some level, and I want to do that. But that's not about aesthetics so much as functionality. So WSGI is one of those levels; but WSGI is a well-specified API that is very closely tied in heritage to CGI, and in functionality HTTP, both good choices. Eggs are another one of those things. And I want Paste Deploy to also be part of that -- simple and relatively formal ways of indicating configuration and creating an application, as well as stronger promises about isolation than WSGI alone demands. But none of these are meant to be about APIs and aesthetics; I hope that these all can be streamlined and made easy/invisible/automatic by the complete-story framework developers.
# Ian Bicking
I feel a bit odd saying this, as I am a TurboGears fan, but this meme that TurboGears is repackaging components better than Django is ... well, a bit of our own hyping, isn't it? There were plenty of templating engines for Python before Kid came along; there were plenty of other web stacks than CherryPy --- that Kevin chose to build on these was his decision, his opinion. SQLObject definitely has an opinion of how to interface Python with an RDBMS. Everytime someone picks at Django for "rolling their own" it comes across as dissing them for having an opinion. (Especially as these conversations usually end with the caveat that "Oh, well, Django's been around long enough that they pre-date Kid and the improvements to SQLObject and blah blah blah...")
It's a bit sad, as this should be an amazing time for Python --- both Django and TurboGears providing all the parts and glue are an amazing achievement, in very little time.
# Roger Espinosa
Concerning the state of Zope, we've have a movement inside the Zope community to merge our diverse subcommunities together; we've got Zope 2, Zope 2 + CMF, Zope 2 + CMF + Plone, Zope 2 + CMF + CPS, Zope 2 + Silva, Zope 3, and more. I helped formulate some of the strategy and code (Five, which is Zope 3 in Zope 2) over the course of 2004, and this really gained steam and acceptance in many of our subcommunities over the course of this year. Now there's an exciting revival of development of Zope 2 (we put in pieces of Zope 3), Zope 3 is ready for prime time, and overall the situation in the Zope world is looking up in my perspective. Communities are integrating and we're working together much more. Zope 3 getting ready was of course the catalyst for all this activity.
The next obvious step on this path is to integrate Zope better into the rest of the Python community. Zope has influenced the Python community for a long time of course in many different ways (new style objects are there in Python now in part due to requirements Zope corp had, and earlier Jim was instrumental in introducing metaclass hooks), but it's time for Zope to eat the humble pie and start reusing more what others did. Philipp von Weitershausen describes how this is happening. He also mentions that nobody knows about this; developer marketing is another Zope problem that's way past time we tackle as a community.
So, because of my experience within the Zope community I have some idea of where you're coming from and where you're going. Aligning, by word and code, subcommunities to work together in their common interest can be extremely beneficial to everyone involved, so I'm happy you're around and thinking about how to do this so much. Thank you!
Ian,
Very good post. This is the type of post that keeps me coming back since quite some time.
Sometimes I wonder in all the discussions around web application frameworks be it Python based TG or Rails, etc. whether you are not constantly confronted with integration to packaged applications (like SAP) and infrastructure services like SingleSignOn, Active Directory, Archiving solutions, BPEL engines, MQ, data warehouses and all this enterprise stuff. Yes I know, this is J2EE and .Net territory, but even a smaller web applications might have to interface with quite some of those existing facilities. (and usually they don't provide REST or XML-RPC interfaces).
What's your experience and opinion on this?
Roman
(Uh oh, Ruby guy here, avert your sensitive eyes!)
Interesting thread, and I agree with the prediction that the Ruby web framework community will fracture, and history will play out, a little bit. It'll be a test of Matz' little language to see what happens from there.
I just wanted to point out a few things for those who might be observing the conversation from the outside. Rails has always been developed as an integration of several separate, isolatable components (ActiveRecord, ActionPack, ActionMailer, ActiveWebService, and possibly ActiveSupport), and while those components mesh much more closely with each other than with outsiders, they can mesh outsiders. Two examples:
- http://amrita2.rubyforge.org/Rails.html (a different template language)
- http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/137579 (a different persistence strategy)
Though, maybe I'm way off here, and should go back to my hole...
# Devin
Hi, I just wanted to add that there is another raising competitor in the web frameworks arena: http://catalyst.perl.org/. Backed by CPAN this framework does try to reuse existing modules rather than rewrite the whole stack.
Ian, I appreciate a lot what you have written lately. But let me drop my $0.02 about this post.
You write in the penultimate paragraph "Python can be the next system like that, ..." For me, this sounds like a deja vu. I heard it when the shining star of Perl CGI started to fate. I heard it again when Zope raised to relieve us all. And now again... Don't get me wrong, I love Python. But I am currently looking into rails, cause it fulfills it promises and isn't the next prophet to make a Python framework the tool of choice.
In my eyes, the most promising Python web framework is Django. Not based on its features and so on. But just because how it is developed, maintained and documented. Everything is well integrated, works fine and feels as a complete tool. TurboGears started nicely. Kevin has some great ideas. But then he entered the PJE road of release management, or better said the unfinished aX-Notation like 0.8a5. I wait for the first time, when he is heading straigt from 0.8a6 to 0.9a1 or whatever, just as the release for setuptools walk.
If I understand you correctly, you also say that it is good to integrate existing tools. Right? This is what I thought you meant, by saying that you can't develop everything on your own and can't be cutting edge if you do everything yourself. Basically, I think you are right. But then I look at my TurboGears mailing list archive and see, that you have to do two things to succeed with such a project. First, be a benevolent dictator and steer the project, steer the discussion and shield your users from the discussion about the underlying technologies. Do I care about wether SQLObject, Og, ActiveRecord, Hibernate or whatever is used? Not at all to be honest. And if I see people discussing this stuff, it makes me uncertain. Same for using Paste, WSGI (this is also a nice point, where regularly shake my head), and so on. I still think that you are basically right, but Rails and Django are proven examples why it can be good for a project, if everything is integrated well and market as a solution. This is a lesson I (the technology guy) learned from the sales guys. The second lesson I learned was, that it is also sometimes crucial to be not a benevolent dictator and stop some discussions. :)
Just for the protocol, I don't want to lower the job Kevin Dangoor has done. He has done a great job. The only problem was, that the usual prophets showed up and he didn't went backstage with them.
And for the same protocol, I agree with you that Rails is not the panacea, the holy grail and the end of development. It is an implementation of an idea. And currently the best available in my eyes. But good things will follow, and may be from the Python community. But the Python community has to get rid of its attitude to some degree to achieve this. In my eyes a lot of Javaism is showing up in the community, which is in the end not compatible with the idea Rails follows and a lot of people enjoy to follow in the future. Pragmatism is something, that (we|the) Python guys sometimes lack. And may be it could be helpful if not all people would implement there own base technology but integrate existing stuff.
You write in the penultimate paragraph "Python can be the next system like that, ..." For me, this sounds like a deja vu. I heard it when the shining star of Perl CGI started to fate. I heard it again when Zope raised to relieve us all. And now again...... and now again we should try to make it work...? That's what I read from the history, not "it didn't work before, we shouldn't try again." Zope has some good goals, ones which we shouldn't abandon even if the product wasn't manageable, and we should learn lessons from the problems Zope had.
I guess I should probably try to analyze exactly what it is that PHP is good at (and Perl CGI before it); but you can probably imagine what lots of its good features are as a platform.
Do I care about wether SQLObject, Og, ActiveRecord, Hibernate or whatever is used? Not at all to be honest.Maybe not, but I sure as hell do. And if you start using Django heavily, you will start to care when another framework comes along and uses a different ORM. And you will care what that ORM does, and you will care about URL dispatching, and all that stuff. And if you want to use that new framework, you'll care about how hard it is to maintain both alongside each other.
If you are just jumping ship and moving to an entirely new stack, these things don't matter to you. And maybe targetting those people is a perfectly good strategy -- for some stacks it's probably just as well that they are abandoned. So Rails has seen lots of PHP and Java programmers; and because previous investments in Ruby have been rather small previously, it's been able to get the Ruby programmers as well.
If you want to get people into Python the same way, that's fine. You won't get me, because that's not where I am. More than once people have asked me: why not just all use Django? Personally I don't know what the hell they think I'm going to say.
But even then, that's fine. If you had to buy into reuse to participate in the kind of WSGI-based stack I imagine, that would invalidate the inclusiveness of the stack itself.
In my eyes a lot of Javaism is showing up in the community, which is in the end not compatible with the idea Rails follows and a lot of people enjoy to follow in the future. Pragmatism is something, that (we|the) Python guys sometimes lack.There's some vague accusation underneath these comments that I dislike (ditto the Frankenweb post I reference in the article). It's using Javaishness as the same kind of blunt stick as not-Pythonic-enough.
These are practical issues. Being able to install an application easily is practical. Being able to embed other applications is practical. Introspection and uniformity at some level is practical. And yes, reuse it practical, at least if you think that anything you build matters.
Maybe you can't imagine building anything that can't be built in a few weeks today. I can imagine those things, things that I want to build in a few weeks but can't. If all we do is write and rewrite and refactor the same kinds of stacks, we can't get there. At some point we have to put pieces of the stack behind us, to make them stable (as in API-doesn't-change, as in mature and boring), to create a real foundation. That simply can't happen on the level of a typical web framework -- you still have to have a framework, at some level you have to get things done, but the framework isn't where we can build up that foundation.
I'm sorry if you don't understand the motivation or purpose of some of the things I work on or talk about. I do want to explain them better, but sometimes I don't. But labelling that confusion as though I'm therefore caught up in meaningless academic discussion is a little offensive. If you think it's too complex, say so; if you think it is unapproachable, say so; but there are deeper and more abstract ideas underneith the surface of immediate pragmatic concerns, and they do matter sometimes.
# Ian Bicking
I would like to add that all the buzz around the frameworks is often generated by people doing only web applications and not having to access other business models/logic from within. These needs to integrate, reuse the ORM coming from the business side of the application, are often simply not addressed today. So +1 for the FrankenWeb, because my web is linked to grids and software stacks that cannot be handled by a "unique" framework.
Ian, I want to apologize for initiating the confusion that you are working on Pylons. Ben Bangert corrected me shortly after I commented on the O'Reilly editor's list. We both watched as my mistake was posted on Tim's blog that night.
# Rob Orsini
You are so write. In fact Rails is not the only Ruby web framework. Have a look at the sophisticated Nitro/Og framework. Watch some example videos here:
www.nitrohq.com/view/Videos
Not to mention Wee and Borges. Seems like Ruby is well on the way to the same plethora Python "enjoys" today. Since I'm in the middle of technology path selection for my present employer, who generates many web apps and who does not want to revisit the decision for several years after it's been made, this kind of crystal-ball stuff is most of what I've been doing the last couple weeks. Hence the call to merge tg/sw - and, yeah, why not paste while you're at it?
Since I'm also looking at seaside, in my mind there are 4 drivers for productivity and maintainability in new web app frameworks:
- Continuations. Not just syntactic sugar, these enable us to apply the same factoring techniques to presentation and workflow classes that we do to model classes.
- Encapsulated Javascript for AJAX. This encapsulation should be written in the same language/framework as the server. Subway's crackajax points the way, I think, though it's speculative code ... other imperfect inspiration here is actionstep ...
- AOP. Once you've got the above, altering client-side behaviour using aspects could be done the same way you do it on the server.
- Encapsulated XHTML instead of templates. I greatly admire this in seaside
To my thinking it seems to come down to what I'd call SymmetryOfLanguage.
Disclaimer: I agree with a lot of what you said, this is just a general musing.
As we come become better programmers (we being the general we, meaning all of us) and our tools become better, the time needed to write some quantity of code to do thing X decreases, as does the time requires to integrate existing code into "our code." However, the time required to write new code decreases faster than the time needed to integrate coe (in my opinion).
The contention with Rails is that things are so much easier to write that it's actually faster to write it yourself, and it results in better code, since the downside of replicating existing work is outweighed by the upsie of writing a piece of code that does EXACTLY what you want.
That's the contention, whether it's true or not is a different story. From my experience rolling my own login code, i see elements of truth, but that's only one small data point.
# Mike
...things are so much easier to write that it's actually faster to write it yourself, and it results in better code, since the downside of replicating existing work is outweighed by the upsie of writing a piece of code that does EXACTLY what you want.Close and on the right track, but for me it goes more like this....
It oftentimes takes too long to learn a comprehensive [read that as complex] framework than to simply use simplier libraries and just get the job done. The time saved can then be put to a higher use. True, it might not be all that it could be, but unless you are writing something as complex as an amazon.com, I doubt it needs to be perfect.
# Larry
"It's hard, but it's good exercise."
That one simple statement is all that really needs to be said. I cannot understand the passion with which some demand that others stop spending their own personal time on research they clearly find interesting.
# alex dante
If you hate monkey patching then you must really hate languages that are prototype-based like Self, Io, Slate, Javascript etc because essentially the basis of these languages is monkey patching. In fact in a langauge like Io the only possible way to program is to do monkey patching. There are no classes. All you do is copy objects and then add methods to them to create new objects.
# assman
I think the above comment on prototypes is spot on.
Ruby is, for the most part, a prototype language hiding behind a little class based sugar. The sooner you realize this and make peace with it, the more sense Ruby begins to make.
I also think the post is a little disengenuine: it's assumed that when Pythonists monkey patch, they do so with solemn care, but when Rubyists do, it's all whimsy and folly. Any Ruby hacker worth his keyboard knows to take care when re-defining existing behavior.
Sitting here, I tried to think of an instance where open classes have caused me a problem.
On the other hand, I immediately thought of 3 places in my current project where they saved me considerable work.
Like most things, I believe this issue comes down to developer quality: prohibiting open classes or monkey patching isn't going to save you from the developer who would carelessly abuse these features.
Aside:
From a theory perspective, prototypes with method update actually form a very complete formal calculus. Don't be so quick to reject method update as a hack-ish convenience. They're capable of encoding everything classes do from a 'traditional' OO perspective, and with some very nice properties. They are the lambda calculus of objects so to speak. Read Cardelli and Abadi's books and papers for a detailed examination of these ideas.
Thanks for articles about Python & Ruby... Your information strongly has helped me...
Thanks for articles about Python & Ruby... Your information strongly has helped me...