Slashdot Mirror
Rails and Merb Ruby Web Frameworks Merge
An anonymous reader writes "The Merb and Rails Core Teams today announced a major merger; the two projects will become one, and be released some time in Q2 of 2009 as Rails 3. This is great news for lots of folks who worried about the potential community fracture, as well as great news for all the developers who will now have an all-around better option for programming Ruby. Read more about the details in Yehuda's blog post, or at the Ruby on Rails blog."
Rails can only prosper from this (ugh, I hate how I'm phrasing this) 'merger'.
nonconformity at work
Either today is April 1st.. (Checks calendar). Nope. I guess Rails is no longer a ghetto. (Sorry Zed) The rails and merb teams collaborating on making a good project... It just brings tears to my eyes to see these boys grow up and play nice.
Blessed are the pessimists, for they have made backups.
Merb is like a lightweight RoR. Lightweight because it's more optimized and leaves more decisions up to the end user (as opposed to RoR's one size fits all). Ruby on Rails v3 will be more modular so if the shoe fits, you wear it. But everyone else can replace the parts they don't need or want.
Do you even lift?
These aren't the 'roids you're looking for.
At time of posting we have:
Either the taggers got up on the wrong side of bed today, or my general impression of Ruby is horribly wrong.
$_ = "wftedskaebjgdpjgidbsmnjgcdwatb"; tr/a-z/oh, turtleneck Phrase Jar!/; print
Ridiculously fast development time. It's insanely productive for the 80-90% cases that you run into.
Really nice schema/db migrations system built in.
Ridiculously simple to take a web app built with it using standard postbacks, and make it all super-fancy ajax, in-place-editing, and lightbox goodness.
Ridiculously easy to turn the whole thing into a REST engine for some other front-end or machine-to-machine usage.
My (un-quantified) perception is that its running about 1/3 the size (lines of code) of a similar php app, and even a smaller percentage compared against asp.net/java.
For a certain segment of app development needs, its really quite compelling.
Depending on who you ask, it's either to make good web developers more productive, or to make idiot web developers marginally productive. As an idiot web developer, I can only vouch for the latter. But I must say, I do love me some Rails.
You want the truthiness? You can't handle the truthiness!
It may be easy to write and deploy, but as a sysadmin that builds the systems that run RoR apps, it stinks.
There's little to no debugging, we've gone through four different ways to run RoR apps, and there are new versions every few weeks.
For real fun, try running a Rails app where it's deployed to an NFS filesystem and then try to run the app via CGI. You can see how well it's 'optimized'.
I agree that there are lots of gotchas in your first few deployments before you learn all the unwritten rules.
Nowadays though, its not much different than deploying a PHP app, using mod_rails/passenger.
svn up your changes (or capistrano or whatever you like), then touch tmp/restart.txt and thats it.
It's not quite to the level of simplicity of PHP, but it wont take long.
For real fun, try running a Rails app where it's deployed to an NFS filesystem and then try to run the app via CGI. You can see how well it's 'optimized'.
I'm not entirely sure what you mean here, other than you're obviously frustrated with the platform.
I've never tried to run a rails server with the app content on a network-mounted filesystem, but I have done that with assets (images, etc). And I'm not sure why you would ever run Rails via CGI, unless this was several years ago, predating mongrel.
I could see that its possible certain parts of the app folder structure may not play well with NFS, but you could keep those on a local fs (ie, everything under log/ and tmp/).
Were you running a cluster for example, with all of them mounting the same app filesystem for simplicity? If that were the case, each server would almost certainly need their own local tmp/ and log/.
This will give the Merb people a lot more momentum, and their project will have a really big community, a thriving job market, and lots of books written about it.
And it will give Rails the value of all of the good stuff that Merb brings to the table -- Rails will be more modular and less monolithic, easier to learn, and easier to move forward because people will be able to split off smaller pieces and improve them.
Yes, it has changed a lot in the past few years, but it has only been around for four years and took time to mature. Deploying it has not been that difficult for a while now in a dedicated environment, and with Passenger (mod_rails) it is ridiculously simple even in a shared environment. Running Rails apps via CGI has not made sense for quite a while, even if you were using Fast CGI, Mongrel and a load balancing proxy have performed better and been easier to set up for quite some time.
Also, I'm not sure exactly what you mean about no debugging. ruby-debug works well, you can catch exceptions and do what you want with them, there are plenty of monitoring options, etc.
It's also been lightweight in that Rails has always had everything you need, in some form. All kinds of Rails plugins that won't work with Merb. All kinds of conveniences that you get for free somewhere in ActiveSupport, like being able to type "5.seconds.ago" or, of course, Symbol#to_proc -- some might exist in Merb, some won't.
This move is good for Rails for obvious reasons, like the ones you've outlined -- even just ActiveSupport takes something like a half second to load on my machine. But it's also a good move for Merb -- probably the single biggest problem Merb had, for many people, was "it's not Rails."
Don't thank God, thank a doctor!
Python started in 1991, Ruby in 1995. Are you telling me you're still mad about that?
Or are you talking about something of substance -- like, say, frameworks? Because here, Merb has done some things that make Django developers jealous. (And vice versa, of course.) And Python still hasn't figured out how to write a decent package manager -- "easy-install" is anything but.
And your "performance" comment, as it turns out, really isn't justified. I don't know about Python, but it turns out that Merb is faster than PHP, and absurdly faster than CakePHP.
Don't thank God, thank a doctor!
For debugging, New Relic provides some awesome tools that allow introspection of delay and timing at a function dispatch level. If you're serious about Rails, New Relic is for you.
As for file-backing your Rails app, my company has had huge success with GFS. It can be a beast to maintain sometimes, but it will crank out the IOPS behind very hungry RoR apps fairly well. It also requires shared block devices, though, so it may not be for you. The S3 plugins for Merb and Rails also go a long way to scaling everything but the code itself (which should be manageable on even the surliest NFS deployment).
We've done some really good work with Rails deployment. There are a ton of ways to deploy it, but I think that is more reflective of the variance in people's deployment requirements more than anything else. Phusion's Passenger and Engine Yard's deployment work are helping to lay down best practices here, and we'd be glad to talk to you about smoothing out the deployment process.
Rails is definitely a good application for teasing out some of the pathological behavior in NFS, but that's not necessarily a bad thing about Rails. It's already used by some to test the pathological niches in new Ruby releases (e.g. "Does it pass the Rails test?").
Working with Yehuda and Ezra on a daily basis, I can safely say that you can expect to see a lot of attention to performance and refactoring some of the cruft that has inevitably popped up in Rails' large codebase. DHH has a great vision and Yehuda has great attention to detail. I don't want to imply that "Rails needs Merb" or "Merb needs Rails", but I expect some really good results from the collaboration.
I think Mauve has the most RAM. --PHB (Dilbert Comic)
Goto pragprog.com and order the Beta of the 3rd edition.
Hmmm. Merb was awesome because it was a lighter, faster, less bloated Rails. I'm not convinced that merging the two will result in anything other than dragging Merb down to Rails' level.
There's little to no debugging
Doesn't sound like a sysadmin, but I'll bite.
Yes, the debugging does kind of suck. On the other hand, Rails is pretty easy to test. I do still occasionally break out the debugger -- which does exist, and isn't actually that bad, just isn't good -- but for the most part, unit tests work well enough.
we've gone through four different ways to run RoR apps
And they do seem to be improving... Right now, Rails apps are generally run as a standalone webserver, which can (if needed) be placed behind a load-balancing proxy like nginx, making it easy to scale horizontally.
I don't really see that going away. Everyone seems to be wetting themselves about Passenger, but really, I suspect I'll be running little embedded Ruby webservers for awhile now. Rack makes them pluggable, so if you don't like Mongrel, you can use something else. It also means that they can be put behind any frontend you like, and it means you can run whatever you like on the backend, without having to think too hard.
Rubygems make it easy to maintain multiple versions of Rails -- not that you really have to care. It's not hard to bundle Rails itself with the app -- thus, the system I've described above is really more a Ruby app deployment, not just a Rails app deployment.
Don't thank God, thank a doctor!
I'll second this. Deploying a RoR app for a (reasonably large) website, I've seen all manner of issues. We're proxying to Mongrel on the backend, but it's a huge hassle.
It's been a rollercoaster ride of excitement, as each new feature, daemon, or cronjob has required not only programming by the developers, but hours of time spent by me writing shell scripts to wrap Ruby scripts because the framework either doesn't allow for something, or does it in a silly way. Rails devs/users will argue that 'You can do [x], just do [y], [z], and [q], and voila,' but I'd prefer things to be straightforward, rather than what seems to be ad-hoc design-philosophy-of-the-week.
Maybe I'm just frustrated, but it seems like the Rails devs develop in a vacuum, ignoring the practical concerns involved in actually *deploying* code. I always stumble across blogs with long explanations and tutorials on things so simple as *starting a service at boot* - and not even an arbitrary service, a common service like Ferret. It almost reminds me of qmail, famous for doing things its own way, even if that completely goes against everything else everyone else does.
Not to mention that it's easy to do something idiotic in Rails. For example:
Orders.all.each { |order| ... code goes here ... }
Simple task - iterate over each order and run code on it. In practice?
End result is that code that works fine on your test machine (with a hundred orders) fails miserably on the live DB (with several hundred thousand), crashing the server by allocating all the memory available. We also found that Rails (the framework itself, not our code using it) was leaking huge amounts of memory, upwards of 14M (yes, megabytes) per request in some instances, and the GC seemed incapable of cleaning up.
I've dealt with a lot of systems, and I hate PHP more than anyone, but Rails is just full of pitfalls, gotchas, and 'magic' (where it tries to be clever for corner cases at the expense of clarity or efficiency in all cases). It's ugly, bad, and wrong in many situations, and I look forward, honestly and truly, to the excellent Merb developers and what they can do when given their time in the spotlight.
Go guys! We're counting on you!
All kinds of conveniences that you get for free somewhere in ActiveSupport, like being able to type "5.seconds.ago" or, of course, Symbol#to_proc -- some might exist in Merb, some won't.
That's one thing that's always stuck out as unusual and unnatural to me - making object hierarchies that seem to serve only to replicate the English language in a language not designed to resemble English syntax.
It seems to me like it would be more sensible to have, on a datetime object, some simple 'within', 'before', 'after' methods that return true/false (e.g. post.date.within "5 seconds" (or something, however the syntax works).
It just comes across like Rails tries to make things convenient that were never really THAT difficult, or which could have been done in a far more sensible way, rather than with contrivances. It's as though, when designing features, special-cases are as equally valid as generalizations, which leads to a lot of what most programmers I know would call silly features.
I just have a hard time taking a language seriously that seems to overload integers to do date/time calculations. Everything seems mixed together in true spaghetti fashion, and that, more than anything, turns me off the language and framework entirely.
How is that any worse than traditional web development environments, where it's equally easy to a "select * from orders" ? It's so easy to forget a WHERE clause.
If anything, I think the presence of "all" in "Orders.all.each { |order| ... code goes here ... }" is much easier to spot than a missing SQL clause.
Not that that excuses any of Rails' other flaws that you pointed out.
OtakuBooty.com: Smart, funny, sexy nerds.
I didn't switch to Merb primarily for technical reasons; I switched to Merb because I got tired of being insulted whenever I asked for help on #rubyonrails (my very first experience there was being told to go back to Perl if I didn't understand Ruby (note, not if I didn't _like_ Ruby, if I didn't understand it), and my last was being told to 'drop the gimme gimme gimme attitude' when complaining about something that wasn't documented -- _AND OFFERING TO PROVIDE A DOCUMENTATION PATCH IF SOMEONE WOULD HELP ME UNDERSTAND IT_).
By contrast, both the Merb IRC channels and mailing list have been nothing but helpful. I'm afraid that will change when the two communities merge.
Agreed, but note that it's rails that adds the date/time functionality, not ruby. While I think it's great that it's *possible* to change the behaviour of core classes, this should be done with extreme restraint, and rails seems to have gone a bit overboard with it.
Be wary of any facts that confirm your opinion.
I always stumble across blogs with long explanations and tutorials on things so simple as *starting a service at boot* - and not even an arbitrary service, a common service like Ferret.
So what's Ferret or you inability to manage system services got to do with Rails ?
Not to mention that it's easy to do something idiotic in Rails. For example:
Orders.all.each { |order| ... code goes here ... }
With power comes responsibility - something you ought to know by now. You can do something just as stupid using _any_ other web framework + ORM; this is not a problem in Rails, it's a problem with the way you choose to solve the problem at hand.
Go guys! We're counting on you!
How about counting on yourself and getting some work done (on the Rails framework) without waiting for others to solve your problems ?
What exactly are you trying to debug? As for deploying new versions, It's dead simple to bundle rails with the application, and then all you are doing is an application deploy.
I'm trying to track down problems that the coders are having. We're not sure if the problem is in the RoR end or the Apache/mongrel end.
Why were you running as a CGI in the first place? Did you do any research before hand? I don't understand how you would do any reading about ruby without stumbling across it's relative slowness, and then you tried to add another layer to the process? And then you add NFS for good measure?
Rails is optimised for developer productivity, not for raw execution speed. As a sysadmin, you need to run it with either a pack of mongrels or phusion passenger. If you're debugging for more than 15 minutes per deployment, you need to get your developers to write some more unit tests.
Why as CGI? Like I said above, we're trying to debug problems. The response that Rails developers have to problems is pretty poor. And to add to that. mongrel isn't being developed anymore (from what I'm told), and mod_rails is the new hotness. Running separate servers for each RoR app just won't cut it - there's too much that requires interaction between the developer and sysadmin to get it working quickly.
For real fun, try running a Rails app where it's deployed to an NFS filesystem and then try to run the app via CGI. You can see how well it's 'optimized'.
Anyone running a performance-sensitive webapp over NFS as a CGI application doesn't know what they're doing. Regardless of the programming language.
We were running as CGI to debug problems between Apache and mongrel. Turned out it was the rails app causing our grief, but that led into my debugging issues. I had almost nothing in log files to tell me what was going on.
But strace was a big help when I tried to run as CGI. The problem was not log/ and tmp/, but more like rails (or ruby) doing over 20k file lookups all over the system looking for various files. On a local disk, that can be pretty quick. Over NFS, that large number of searches really bogs down. There's no reason for all those searches, especially when you should be able to set the locations as options.
I'm more frustrated over the notion that the developers keep changing their requirements. Their development time may be fast, but building the systems to handle their code isn't, especially when we have to toss out the previous 2-3 months worth of work because some new shiny shiny came out, the developers are asking for it, and it's brand new code that barely works. Then you go through the same exercise 2-3 months later.
Sure I know mongrel, but that knowledge is useless now. I don't mean to sound bitter or angry, but more seasoned (if undesirable by coders) languages like PHP/Pyhton/Perl are easily understood and work well for what they do. For us to integrate those into our hosting environment is a no-brainer. Even application servers like tomcat and jboss are easier to set up now as well.
Then again, that's why I'm a sysadmin and not a coder.
You're just wrong. Order.all is simply an alias for Order.find(:all), and as such and array of Orders - *not an associations*. (see http://api.rubyonrails.org/classes/ActiveRecord/Base.html#M001966). There's no N+1 problem here.
p.s. I just noticed the grandfather quotes code in the form Orders.find. This is clearly a sign the author isn't even used with basic Rails naming conventions.
Go read my other comments where I explain what I was doing, why, and why the performance was so terrible.
Perl CGI doesn't have this problem, nor does python.
I always stumble across blogs with long explanations and tutorials on things so simple as *starting a service at boot* - and not even an arbitrary service, a common service like Ferret.
Well, Ferret is not a "common service" anymore. Most of people already switched to Sphinx. I had horrible experience with Ferret myself, and I wouldn't say it's reliable. It's not even developed anymore. The thing that you mention Ferret in this context just confirms that you don't have much experience with Rails. It's not a standard Rails feature, it's a 3rd party addon. You don't judge framework by quality of addons, just like you don't judge operating system by quality of programs written to it.
Well the deployment of Rails is getting easier every day. It now integrates nicely in your LAMP stack thanks to Fusion Passenger.
Or if you want more scalability, spead and general coolness you can use JRuby (with Warbler) to deploy a Rails application on a J2EE application server of your choice (e.g. Glassfish, Tomcat, Websphere). This also allows you to leverage technologies such as JMS or JDBC connection pooling from your Rails application.
Deploying Rails application has been a mess since it's inception, but with Passenger and JRuby we have two very mature options.
making object hierarchies that seem to serve only to replicate the English language in a language not designed to resemble English syntax.
Not at all required, but that's one of the things I love about Ruby -- that you can do that, which makes the code extremely readable. Whether or not you like the fact that these methods exist on integers, it doesn't really hurt, and at a glance, even a non-programmer understands.
It seems to me like it would be more sensible to have, on a datetime object, some simple 'within', 'before', 'after' methods that return true/false (e.g. post.date.within "5 seconds"
So, instead of adding methods to an integer, you'd be parsing strings? I like the Rails way better.
Oh, and it's a bit more flexible than that -- because 5.seconds is actually a value of time, and 5.seconds.ago is actually a datetime.
But then, if you don't like this, you'll hate rspec...
It just comes across like Rails tries to make things convenient that were never really THAT difficult, or which could have been done in a far more sensible way
Perhaps not, but Rails is targeting the first 80% -- and while it takes some time to get used to, it's now at the point where I get quite annoyed when I can't do 5.seconds.ago, and instead have to do something like Time.at(Time.now.to_i - 5) -- and that's not even equivalent (5.seconds.ago handles usecs).
So, while it's not that difficult, it's also damned convenient, and if Rails stopped doing it, I'd find something that did, or write it myself. Hopefully Merb/Rails3 will split it out into some small time-manipulation library, so that a Rails app can be built without it, and a separate app can be built with it but without a huge pile of ActiveSupport.
I just have a hard time taking a language seriously that seems to overload integers to do date/time calculations.
You'll hate the Inflections library, then.
Everything seems mixed together in true spaghetti fashion, and that, more than anything, turns me off the language and framework entirely.
I really don't see the connection to this, though. What's spaghetti about having a convenient way to create and manipulate time durations?
Don't thank God, thank a doctor!
Ruby on Rails has a great community, but the only ones (with few exceptions) hanging out on #rubyonrails are newbies and/or fanbois.
It was long ago that the pros left the places where newbies also could hang out and ask questions. There are a couple of half-anonymous invite-only communities where hundreds of already semiprofessional Railsers (including core developers of Rails, major sites and plugins) hang out and help each others and life there is great and very friendly and helpful.
Unfortunately that also means that there aren't very many seasoned devs left to help the newbies, only people who are newbies themselves, and annoying loudmouths who think that platform choice is a war or something.
This is the curse of being hyped.
My other account has a 3-digit UID.
I can manage intelligently-designed services, but services that are designed with no regard for sane UNIX behaviour become tricky. I can work around them, but people shouldn't have to do extra work every time they deploy something if this could be solved by sane design considerations in the first place.
Likewise, I'm not going to 'fix' rails because I'm not a Ruby developer, I'm a sysadmin. My job is to get Rails running on test and production servers, and in that regard Rails is a huge hassle, far more than it ever should be.
I'm not saying it can't be done or that I can't do it, I'm saying that there's no reason, other than laziness or cluelessness, that Rails should require such hoops to be jumped through.
The spaghetti part is that the integer class handles date/time functions as well. That's inherently messy and conceptually ugly. Maybe I'm too much of a purist, but clearly-defined modules with clear delineation points between them makes it easy to conceptualize the code.
In Python for example, if I want date/time manipulation, I import the requisite module. Same with threads, process manipulation, file path handling, and so on. In Ruby, it seems as though I get date/time manipulation just by virtue of having integers (which I presume I always have), which makes me wonder what else is being brought in whether I know about it or not.
I think that, more than anything, is what unsettles me about the whole affair, but then I guess not knowing what's going on under the hood is part and parcel if you're using a giant framework like Rails.
Ruby does not stick date/time functionality into integers (or Fixnums, in Ruby lingo). Rails has extended Ruby's Fixnum class to provide methods that convert and operate on dates. It's also added methods to convert 1.thousand into 1000. Since you deal with and compare datetimes SO often when building database-modeled GUI applications, this is a Good Thing in that context. When I write rails code, it's convenient. When I write Ruby code outside of rails, I almost always don't want that.
The amount of ugly, spaghetti-like "meta-programming" needed to make Rails code look as simple and pretty as it does makes me want to scream sometimes. But I must admit, when I resign myself to doing things the Rails way, I can get things done quickly, and reliably.
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
Oh, I failed to mention that we had looked at mod_rails (Passenger) and it looks completely awesome in the context of Rails websites that are capable of running on a single machine. Unfortunately, our site is such that more machines are required, at which point it's actually easier to run multiple machines with multiple Mongrel processes than to run multiple machines with multiple Apache processes, ironically enough.
It may actually be more sensible to rearrange our architecture to attempt to take advantage of mod_rails, as preliminary benchmarks seemed to indicate an anecdotal increase in pages served per second by about 5-12% depending on the page. Unfortunately, without more benchmarks, more hardware, and more time before Christmas crunch season, we didn't have sufficient time to test it.
Regardless, mod_rails is yonks ahead of anything else I've seen and if you know how to manage Apache, or at least know how to copy-and-paste, everyone should be using it in every possible situation.
The spaghetti part is that the integer class handles date/time functions as well. That's inherently messy and conceptually ugly.
If you say so -- keep in mind that not much has to be done within the integer class, other than creating and referring to objects of more appropriate classes. I am not sure if this is actually what Rails does, but it would make sense.
And in that sense, I don't see 5.seconds as being uglier than seconds(5) -- after all, it is unlikely that anyone would create a "seconds" method on integers except for that purpose. Beyond that, I'm sure you will agree, methods like 'ago' or 'from_now' make sense.
There are Time, Date, and DateTime classes in Ruby, and they work more or less the way you expect. Time is available out of the box, and Date/DateTime is available in the standard library. This is just a convenient interface for dealing with them -- 5.seconds.ago will, in fact, return a Time object.
And if you really don't like it, just don't use Rails. Ruby itself has nothing related to dates in its Integer class. Rails (specifically, ActiveSupport) adds them.
In Python for example, if I want date/time manipulation, I import the requisite module.
And that is still true -- here, if you want to manipulate dates and times in this way, you require activesupport, which requires date and a few other things. The good news about Merb is, it's likely that you won't need all of activesupport to make that happen.
In Ruby, it seems as though I get date/time manipulation just by virtue of having integers (which I presume I always have), which makes me wonder what else is being brought in whether I know about it or not.
This is not the case -- you're confusing Ruby and Rails. If you have an environment set up, you can easily compare by running a simple irb, which will give you a bare Ruby, versus opening a Rails project and running script/console, or requiring activesupport in another irb.
More importantly, why would it bother you? What possible disadvantage could there be to having methods like seconds, minutes, and hours on integers, other than seeming conceptually odd?
not knowing what's going on under the hood is part and parcel if you're using a giant framework like Rails.
Perhaps. I found Rails code needlessly long and complex, but it was readable, and open source. So it's not actually that difficult to figure out what's going on, especially if you know Ruby well.
And we haven't really touched on symbols. One trick adopted by Rails, which is actually built into Ruby 1.9, is Symbol#to_proc. I don't have an example offhand, but I'll try to explain what it does:
Symbols are, effectively, frozen strings which are faster to compare. That's oversimplifying, but it's enough to give you an idea.
Procs are chunks of executable code, much like an anonymous function. Ruby methods often take procs as arguments. Contrived example:
That each method, on that array, is taking the do..end block as proc argument, and calling it once for each duck in the array. Rails changes the Symbol class like this:
send, in this case, means "send this message to this object" -- effectively, "foo.send :bar" is equivalent to "foo.bar". So now, I can actually do this hack:
That ampersand effectively means, turn this into a proc. So, the result of :quack!.to_proc is passed to ducks.each. More compact, more readable once you've seen it used.
It takes a bit to
Don't thank God, thank a doctor!
The amount of ugly, spaghetti-like "meta-programming" needed to make Rails code look as simple and pretty as it does makes me want to scream sometimes.
That's not metaprogramming, that's Rails, or at least, Rails 2. Check out Merb for a counterexample.
Better yet, learn how it works, and then see if you can do better. I remember digging into ActionMailer, and being frustrated at the sheer bloat, but when I wrote something similar (wrote to the database, rather than to SMTP), it was much smaller.
Don't thank God, thank a doctor!
Wrong. That would only happen if email would be an association (i.e. another table), not an attribute of customer (a field in the orders table).
You should also see better memory management if you're using Enterprise Ruby (from the same developers as Passenger: http://www.rubyenterpriseedition.com/). Also if your application fits the 'share-nothing' paradigm you could try to put a load balancer in front of multiple machines running mod_rails. Anyway, Rails deployment has come a long way from FCGI to Mongrel then Passenger. I think things look good for the future.
I consider code that runs when a class is inherited from another, and dynamically defines a set of methods for that class, naming them on the fly to be meta-programming. Maybe my definition is wrong. This kind of programming is ugly almost by definition; and if I wrote it, anyone else would also consider it a mess. That's just the nature of the beast.
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
Sorry, I guess I wasn't clear...
Yes, it is meta-programming. However, I don't think it's an inherent property of metaprogramming, that it has to be ugly, spaghetti, or convoluted.
My point was that yes, Rails metaprogramming is ugly. However, that's Rails. Metaprogramming can be done properly.
Don't thank God, thank a doctor!