Slashdot Mirror
What's the Secret Sauce in Ruby on Rails?
An anonymous reader writes "Ruby on Rails seems to be a lightning rod for controversy. At the heart of most of the controversy lies amazing productivity claims. Rails isn't a better hammer; it's a different kind of tool. This article explores the compromises and design decisions that went into making Rails so productive within its niche."
I've not seen a lot of RoR, but what I have seen reminded me a lot of ASP and JSP with lots of scriplets. Which I thought was bad form (code mixed with html). Have I just been looking at bad (or simple) examples? The article seems to hint that RoR does support MVC.
I've only used Rails a bit, but I've used Ruby a lot. It's by far the most flexible language I've ever used. It allows programmers to modify the most fundmental aspects of the language. Some argue this is a bad thing, and it may be. However, having the freedom to do that is very empowering. Don't get me wrong, other OO scripting languages are great too... Python for example. And, they share many concepts with Ruby. The things that make Ruby stand out (to me) are the ease of modification and syntax flexibility. IMO, Ruby is a wonderul toolkit that will allow one to build most anything, even more specialized tools like Rails.
Nice summary. Too bad it's stolen verbatim from TFA.
I bet noone would realize, since nobody ever reads TFA. It's a sad world, when people steal summaries from the articles they link to.
The big benefit is that it's multiparadigm. It draws the best from the OO world of Smalltalk, while also offering very solid functional features. These are the traits of languages that are suitable for high-quality, fast-turnaround software development.
We can see Ruby applications that are comparable functionality-wise (and portability-wise) to C++ programs, but written in a 1/10 of the time with 1/20 the number of lines of code. That's why Ruby-based solutions are effective and popular.
As far as I've seen, there isn't that much actually new in RoR. But it's obvious that someone has had a great idea how a whole bunch of known stuff should fit together, in a way that encourages best practices (like a lot of testing, and code reuse). It has near perfect design.
The language Ruby wasn't new; Active Record wasn't new, nor was the idea, but it fits with Ruby really well. MVC was old, but the tiny bits of boilerplate needed makes it look like magic now and then. Everybody knows testing is essential, but I hadn't seen it integrated into a web framework so well before. The idea of "sensible defaults" can't have been new, but the switch from reams of XML (in Java web programming) to near invisible config is great. The object-oriented Javascript libraries it uses weren't new, nor are template languages, but the way in which they're added together is pretty seamless. Et cetera.
No wonder every web programming language community out there is rushing to put together it's own version of Rails... but the libraries don't always fit together as seamlessly. I think that Hansson's main achievements are recognizing that all the known best practices can be put together really well, and that Ruby and its libraries were a great fit for that.
I believe posters are recognized by their sig. So I made one.
I tried Rails for a bit. Found it nice. I found the language Ruby more interesting than the Rails framework. Rails code I looked at looked very much like JSP/ASP/PHP gone bad. All sorts of code in HTML land. Then their was the compilation oddities.
I still believe that Java and PHP are better though. They also perform a hell of a lot faster and scale much better. For example, a friend was creating a site with Rails and wanted to put in integrated search. Several people attempted creating something like Apache's Lucene in Ruby but found that the Ruby's poor performance made the search incredible slow (you could time out before it finished getting your search results).
What I would think would be really cool is a Lua plugin for Apache. That would be sweet.
So what? A summary should summarize the article (duh!). If the article itself does a good job at that, why reinvent the wheel?
Amen to that. I think on-the-fly reinterpration of code is the biggest thing that Rails (or just about any other interpreted scripting language) provides that is a severe handicap for Java. I configure tomcat on my dev system to continuously rescan bytecode files for changes, but what is really needed is an easy, standardized way to make minor modifications to classes on production appserver without having to bring the whole thing down. I know some Java appservers support things like this, but I said "easy and standardized" meaning it can be done via an ant task that figures out exactly what classes have been changed, then notifies the appserver of this so that they get reloaded efficiently.
I think the introduction of annotations with Java 1.5 also does a great job of cutting back on the amount of configuration files necessary. In addition, they leverage Java's biggest advantage over competing languages*- typesafety.
*yes, C# has typesafety as well, but that's basically the same language.
Eclipse's debugger does pretty much all I need, although things do get difficult when AOP or other bytecode modification is being used.
pi = 3.141592653589793helpimtrappedinauniversefactory7
(Django has been in use on high-volume production websites longer than Rails has existed, incidentally -- something which might be worthwhile when bringing it up in this kind of context).
After evaluating Rails and Django, my company ended up going with TurboGears for some of our toolage (our main product is a Java Servlet-based application, and that's not changing). The reasons:
The opposing reasons:
Anyhow -- Rails is nifty. Django is nifty. TurboGears is nifty. Quite likely all three of them have a place; I'd just like to urge people not to get so caught up in the hype over Rails that they forego evaluating other options.
Then it's been a sad world for a very long time.
Why not fork?
thar RoR is using Ruby, a programming language that:
a. is fully object-oriented (not a hybrid like c++ or java). For example, you can have "hello".length() or 5.inspect() which means easier debugging and easy extensibility when you can ("can" != "should") add methods to any class at runtime.
b. supports mixins (flexibility of multiple inheritance without the complexity)
c. supports blocks and closures (if you've never used a language that supports blocks and closures, then you don't know what you're missing. I've coded professionally for more than a decade using assembly (intel & motorola chips), c, c++, cobol (ugh), delphi, java, python, etc. and when I discovered how to use blocks and closures in Ruby last year, I almost fainted because it makes coding so much more productive)
d. practical for both one-liners like perl and large/complex applications with a GUI interface
When I discovered Ruby last year and tried RoR for the first time this month (stayed away due to dislike of hype), it felt like I was previously chopping trees with a plastic spoon all this time instead of using a chainsaw--Ruby succeeds because it takes so many great features from other languages and combines them in a cohesive manner. RoR succeeds because it uses Ruby and provides a framework that encourages good coding (by providing MVC for example).
But there is a price for all of this. Speed. In order to provide so many productivity features, the performance will never reach that of c, c++, and many other languages. And I don't know when/if a compiler will ever be practical or available (like gcj for java producing huge binaries to print hello world).
Other drawbacks include poor release management (remember the ruby 1.8.3 fiasco) and poor support for wxWidgets (Ruby has better support for Fox toolkkit, but I use wxWidgets with C++ so this isn't ideal for me).
Anyway, I hope another new language comes along that'll blow away Ruby and another new web framework comes out that'll blow away RoR.
Blind loyalty to language/os/software/etc is for idiots who are afraid of change. Be aggressively disloyal to your products and force their developers to improve or fade away.
To enable some of the RAD Ruby will infer much information from simple syntax and naming schemes. So if you start a class naming it Person, Ruby will look at a table called People to try to figure out the different fields/properties for that class. That's why it comes with some knowledge about plurals built-in.
It's probably not that disturbing if you are used to it, and it is exactly what makes Ruby so fast for development. It's convention over configuration. In a different toolset, you might have to make a mapping from class to table using XML for instance.
It really is tiresome to see people constantly ask "what's the special sauce" when in many instances it is clearly "nothing".
Sometimes good people use good methods to build well conceived applications that work precisely as their audience expects they should. Because these well-formed applications do not fail randomly, scale well and are easily supported marketing and business types presume that there absolutely must be something patentable in the mix.
One of the reasons I loath the term "Web 2.0" is because people presume there is some new wave of innovation occuring in application development when every Slashdot reader know's this isn't true.
Technologies mature, standards mature and hopefully people mature. The result is better software, not an abundance of new and novel special sauces.
I interviewed the article's author, Bruce Tate, for the Ruby on Rails Podcast. He's a brilliant thinker and has taken bold steps to embrace Ruby inspite of his fame in the Java community.
Rails Podcast with Bruce Tate
[Everyone gasps.]
Hermes: No!
Fry: Ah, so the real gift Spargle gave you was confidence. The confidence to be your best.
Farnsworth: Yes, ordinary water.... Laced with nothing more than a few spoonfuls of LSD.
Shop as usual. And avoid panic buying.
1. It's easy to build hash tables in Ruby- At any level of a hierarchical structure like HTML you can have an arbitrary number of child elements or attributes, all identified by a type tag. This happens to map perfectly onto ruby's hash tables, so to create an HTML link you can say:
:id => 'add user', :class => 'shiny button', :action => 'add_user'
link_to
2. Lack of superfluous syntax It is very elegant how every programming idea in ruby seems to require only a single syntax concept at a single location to put it into practice- For instance, if you need a class member variable, you just create a name starting with "@" (like @firstname) without having to declare the variable in a separate location in the file. This is taken advantage of very cleanly by the ROR system, so that programming web pages has a very "WYSIWYG-ish" feel- Every concept in you web site has a clear, understandable equivalent embodiment in the Ruby code
3. Dynamically detects missing methods- I don't know exactly how it works, but ruby classes are able to know when a method on an object is called at runtime that doesn't exist- So you can essentially enhance the functions an object supports at runtime... this allows Ruby toolkits, such as Rails, to essentially shoehorn their own custom language ideas into ruby (not quite at the level of Lisp's "defmacro", of course)
4. It was scalable from day one- Right from the start, ROR was designed to scale- In fact, it was already part of a commercial app before it even existed as a stand-alone product. This means it already overcame the greatest hurdle of any web-development framework from day one- Most Scheme/Lisp frameworks, for instance, still haven't achieved the level of scalabilty that ROR had right from the start.
5. It has a whiff of that mystical Scandinavian software guru-ism in it that make for seriously powerful software Creating a comprehensive web development system is a messy undertaking- ROR is the product of an obsessive Northern European fanaticism that somehow manages to combine an incredible pragmaticism and also manages to handle all of the many ways that web frameworks fail with the utmost of effectiveness. It isn't brilliant because it makes it easier to do complex things, as other frameworks try to- It's brilliant because it makes things that are already easy so much easier that all the complexity, though still complex, floats to the surface of your code and isn't obscured by the many "easy" parts.
6. No pre-processor Many of the more advanced web-frameworks, as in JAVA, require pre-processing of HTML templates with embedded JAVA- The dynamicity of Ruby makes this step hidden- Explicit preprocessors are practically and cognitively difficult for programmers to deal with.
These, I think, are some of the non-obvious reasons that give ROR the edge over other web frameworks.
Nice comment. Too bad its stolen verbatim from the article AND the summary.
So, for now, it's Java or Python, and associated frameworks for me. But not RoR.
So you're not using Rails because it can pluralize "person" correctly? You'd prefer it to pluralize words incorrectly?
For those unfamiliar with Rails, the it pluralizes the name of an activerecord class to get the name of the associated table. So if your class was named "Person", it would, by default, link it to the database table called "people". This is only default behaviour and, unsurprisingly, this can be overridden. It's a feature of the Rails framework, and nothing to do with Ruby.
A reasonably up-to-date version of Rails (1.1.0) is directly installable in Debian testing and unstable; just use "apt-get install rails".
If you're using Debian stable or prefer to use Rubygems to get the most up-to-date stuff, add this to your sources.list:
deb http://www.sgtpepper.net/hyspro/deb unstable/
deb-src http://www.sgtpepper.net/hyspro/deb unstable/
Then "apt-get install rubygems".
Then "gem install rails".
Then set GEM_HOME to "/var/lib/gems/1.8" and add "/var/lib/gems/1.8/bin" to your path.
Then do "rails my_new_project" and have fun.
Reading TFA, I wouldn't use words like zealotry or fanaticism to describe either the article or the attitude of the Java programmers it seems to be aimed at. What I do see, though, is a terribly narrow-minded view of programming, and an obvious lack of broader experience. Let's take a few choice quotes.
From the About this series box, before we even get to the article itself:
Surely most of us would agree that any programmer is well-served by familiarity with a variety of languages, programming styles and tools, and by choosing the most appropriate for any given job. Which, despite the absurd claim above, has never been Java in all, or even most, cases.
From the "Hype and skepticism" section:
No-one who's looked into a wide range of programming languages (and I don't mean Java, C++, C# and Visual Basic.Net) would find those claims particularly surprising or implausible. The functional programming world has been outclassing workhorse industrial languages like C++, Delphi, Java and co. in productivity by an order of magnitude for a long time, at least for the kind of application that lends itself to a functional style. So-called scripting languages, which cut away much of the boilerplate baggage required by the workhorses, have proven to be a much more efficient tool for many kinds of project as well, often due to relatively simple features like supporting common data structures as first-class entities.
Moving on to the Rails philosophies, we see things like "Don't Repeat Yourself" being highlighted as "core opinions pervasive within Rails". Surely abstracting common code and data structures into reusable units is a basic principle of sound programming in pretty much any language?
Then we get to the "niche" for Rails:
I'd guess that's wildly optimistic, though it's certainly a common conceit among Java programmers IME. Not everything in the programming world is web-enabled, and much of it has no interest in becoming so either. Why would a high-performance scientific application, a CAD/CAM/CAE package, a FPS or the firmware in your washing machine care about database-backing and Web-enabling?
All-in-all, this seems to be an article aimed at die-hard Java programmers with little experience of the wider programming world. Its arguments support wider exposure to programming and good general programming principles, though it forgets to mention that Ruby on Rails is far from the only way of achieving those ends.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
exactly, this improves the amount of the article that most /.'ers will read by 100%
Insightful? Good grief; someone misunderstands a word, turns it into a politics discussion, and gets modded insightful. Amazing. I especially like how he thinks the founding fathers were conservative. Haven't heard one like *that* in a while.
First point: "liberal" has more meanings than just "Democrat". It's use in the grandparent post was to refer to the fairly liberal (generous, ample, unlimited (see http://answers.com/liberal) qualities of the MIT license. A conservative license is more like a corporate license; "conservative" means "restrained; cautious, moderate; favoring traditional values; preservative" (see http://answers.com/conservative). A restrained license? doesn't sound very like liberty to me.
Second point: The founding fathers were conservative? Please describe for me how they were cautious? Or restrained? They certainly didn't favor traditional values; no, they were revolutionaries, who rebelled strongly and bravely against the traditional governments of Kings and Lords. They favored ":maximizing each individuals rights and minimizing the role of the state" in their lives. They "believed in free will", and the fundamental right of a person to have the opportunity to create their own place in history. This, by definition (see http://answers.com/libertarian) makes them libertarian, not conservative or liberal.
Sorry for the off-topic second point, but not replying to things like that are impossible.
Actually, I think the vast majority of developers out there are far more interested in getting their damn job done, and couldn't care less if Sun GPL'd the Java sources. 'course, you'll never hear that because they're too busy *getting their damn job done*, instead of bitching about licenses on Slashdot.
Well with your weird example, here is what I would use (not really because it violates lots of say what you mean rules).
ruby -e 'puts 0 ? 0 : "not zero"'
Have to take out the warnings because you are doing something weird. You do know that ONLY false, 1, and nil derive to a failing condition right?
I like perl too, but your example isn't hard to come up with an equivalent. If you mean ruby can't do as many one liners from the command line, you are wrong there too.
Anyway I need food.
RoR is a good OS product that helps people solve problems that really bug them. It doesn't - contrary to lot's of other OSS projects - have a website that looks and works like crap . It's lead developers actually have social skills (and running businesses) and can talk coherently in a way that normal people actually understand them. They are tight with the blogging community and are smart enough not to be arrogant and thus convince even the most fanatic Java people to check out their toy. They started the whole webcast thing and built RoR for an actual real life business project they wanted to do (www.basecamphq.com) before going OSS.
Technology wise there is not that much new. Zope is still lightyears ahead of everything else (including RoR) but only last year did their website stop looking and acting like a total pile of doo-doo. Yet still Zope.org's Navigation is somewhat '99ish and much more intimidating and overwelming than the friendly and straightforward RoR Site.
Then there's Django. Which is very neat, partly even better than RoR (and friends with the RoR project), but went OSS a little later than RoR and thus needs to catch up on awareness a little. Symfony is PHPs late answer to the RoR induced MVC frenzy and still to new to gain awareness momentum. CakePHP and P4A seem ok but don't have the marketing stance to be of any significance anytime in the future. They're both so nineties it hurts and thus will wither and die.
Bottom line: RoR are a OSS project that isn't just good at coding or using exotic technologies, they actually have the skill to market it aswell. And they were the first in the framework camp. It's that simple.
We suffer more in our imagination than in reality. - Seneca
Wow, frankly I'm glad people like you aren't joining the Ruby community. If you even spent 1 minute looking through the Rails code, you would have found the Inflector class that does this "magic". Ruby itself doesn't do that! and you're either naive, ignorant, or both to think that it would.
You know, I'm not sure that it's really so much the langauge, but the utter crap that people write in it. It's...disappointing....to download what you think might be a cool/useful/whatever program, only to find that it's a barely functional VB nightmare that crashes if your screen resolution is set wrong.
Of course, it all depends on the programmer, in the same way that, say, carpenters can do both good work and bad. Good just takes so much longer, and is a lot more challenging.
So the source should be attributed and the text placed in quotes. Out in the real world, stealing someone's work and pretending it's your own can be illegal and also make people look down on you
Yeah, next thing you know it will try to pluralize "dog" as "dogs" or something crazy and unpredictable like that!
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
Until Sun gets bought by some "we sue people for a living" company, like SCO did. Then they'll be a big scramble to make a third party JVM (and libraries) that doesn't suck and is clean of Sun IP.
Will they pull it off in time? Who knows. It's still a huge risk to have invested years into an application that can have the rug pulled out from under it at any time.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Only Access has consistantly worse apps. All languages have some stinkers, but there is something to be said for learning curves keeping PHBs from blowing their own peckers off.
That being said you can be very productive in VB if you're not a retard.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
what in Ruby's syntax is borrowed from Perl?
$_
Guy asked me for a quarter for a cup of coffee. So I bit him.
This article is hosted at IBM, and IBM invests heavily in Java (SWT, Eclipse, etc.) So this article should be taken with a grain of salt. It's like Microsoft comparing .NET with Java (remember Microsoft's ".NET is X times faster than Java" statements?)
However it's nice to see that IBM knows that Ruby exists and knows its strong points - so that they may borrow the good stuff into Java.
It's not a particuarly useful feature when you have a complex class and still want normalised database schema, considering when I last looked, Rails didn't support Class Table Inheritance very well. Instant turn off.
Ruby on Rails - the Bush administration of web frameworks.
This is what they do. They spam their marketing materials on one forum after another, glossing over finer points like the lack of Unicode and threading support, along with quite a number of tools professionals need in their development, and then use their meat or sock puppet accounts to downmod messages they don't want to reach their target marketing audience.
After using Ruby for several years, for general purpose scripting, and various other web development frameworks in Java/Perl/PHP/C#, etc... It seems clear to me that ROR really isn't another 'kind' of tool at all. It's simply a well desgined web framework, expressing some of the philosophy of the Ruby programming language.
The programming techniques ROR promotes aren't new, they're not crazy, or magical. They're not in the least 'different'.
The article lists:
1.) Seamless integration
2.) Convention 'over' configuration.
3.) Low Repetition.
4.) Immediate Feedback.
What web-framework would not want the framework they're using to work well with the underlying language? And Convention over configuration doesn't mean a lack of configuration, it simply means that intelligent defaults are generated. It makes common things easy, and uncommon things possible. And DRY is a main goal of software engineering, of design patterns, of object oriented programming--- which all have been in practice for over twenty years.
In this article, the author points out that it's based on an underlying MVC architecture. This isn't anything new for any other web development framework, for instance Struts. And even outside of an environment which starts with this design by default, software engineers are wise to follow design patterns. It seems he views the philosophy of convention over configuration as somehow making ROR inflexable, and incapable of solving some imagined wide range of web-development programs. Sure, 50% of applications are web-based and database backed--- but ROR programs don't have to be database backed (See Rails Recipes, page 57). And, I figure if a person is using a web-development framework, the lack of configurability in the expression of the application as being web-based is acceptable (although I suppose it's possible to replace the view portion of the application as well).
It's clear, from some messages I've read here--- several people choose 'not' to adhere to MVC, and code the majority of their application in the view portion. ROR really does little to 'enforce' the user to do one thing, or another, it merely provides tools that aid a person in producing a scalable, modularized, and reuseable, web-application.
Ruby is a fully object oriented programming language, that was built from the ground up on the principle of least surprise. Language constructs aren't built directly into the syntax, as they are in perl--- it adheres very closely to the smalltalk view of a truly object oriented language being composed of objects, and messages. The script isn't being augmented with a new 'breakpoint' keyword, but instead with a breakpoint function. There's very little that's magical about what ROR does, and most everything it does can be extended upon, reused, or changed.
It's not a new 'kind' of tool, it's just a clean integration of existing tools. It's an environment that has integrated a great deal of the components that have been in wide use by other web-development platforms for years, and provides a clean way to generate a template project using those pieces.
You want a site that hooks/controls multiple DBs, or want to stray too far from the paradigm? Not so much.
This is by design, obviously. And in a way it can actually encourage good modular design. Where someone doing Java or PHP might be tempted to write one monster application that controls two DBs, the Rails developer is encouraged to write separate applications that communicate with each other trough a well defined interface. And if the two databases don't represent two differnt modules/applications, maybe they shouldn't be different databases.
That said, I agree, Rails is limited and there will always be a place for other frameworks or unstructured freeform coding such as one might do in PHP.
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
What on earth are you talking about? Sure, Rails isn't appropriate for some projects, but it certainly is appropriate for others. Rails isn't missing any critical feature that makes it useless for web development in general, and it makes good on its promise of rapid development. Rails performs well in its (sizable) niche; take it outside that niche and of course you'll have problems, but that doesn't imply that it's useless for all applications.
I think the vast majority of developers out there are far more interested in getting their damn job done, and couldn't care less if Sun GPL'd the Java sources.
Yes, I'm sure many young real-world developers think that way. Now, they should think about what happens when Sun goes out of business, or when they sell Java to Microsoft, or when they just can't afford to pour money into Java anymore, or any of a number of other possibilities. Think it can't happen?
Well, back in the day, we didn't think it would happen to companies like DEC or Symbolics, but it did. That's why real-world developers, after getting screwed by companies like Sun, decided to rely increasingly on open source software, because in the long run, it gets the job done more predictably and with less risk.
Using and contributing to open source software for most people is just business: it primarily reduces risk by ensuring long-term availability and stability of a platform, in a way that no company has ever been able to.
IBM has made JVMs in the past. I wouldn't put it past them to make them again if Sun becomes Sue.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
When it comes to Ruby, I have one wish:
.net environment. Performance comparable to C#, developer time comparable to normal Ruby, bytecode obfuscated enough to use in commercial products.
.net to do that, not to mention the programming of that insane compiler, I could write hundreds of useful Ruby programs.
Compile it. For the love of God and all that is holy, Ruby is at least as slow as JavaScript, if not slower -- at least you can compile JavaScript into Java!
Perl6 shows some promise in that area, but I have some serious doubts. Ruby, as a language, does far too many things that simply assume it's a "scripting" language. For instance, it's possible to modify any class at runtime -- thus many core libraries probably rely on that feature. Also, all names in Ruby are kept around at runtime. I'm pretty sure that it actually is doing a hash lookup every time. For instance:
irb(main):026:0> class Fixnum
irb(main):027:1> def method_missing (name, *args )
irb(main):028:2> print 'Attempt to call '
irb(main):029:2> puts name
irb(main):030:2> end
irb(main):031:1> end
=> nil
irb(main):032:0> 5.foo
Attempt to call foo
=> nil
irb(main):033:0>
I'm sure that someone will find a much simpler / more efficient way of doing the above, but the point is the same. Obviously, whenever Ruby executes code that attempts to call '5.foo', or even '5 + 5' (which becomes something like 5.+(5)), it actually stores the code for the call as a call to a given name, and then looks up that name at runtime.
Now, good OO design generally involves making lots and lots of small classes, and even the bigger classes will have lots and lots of small methods. Good programming design in general tells us to refactor mercilessly, which will, in any language, tend to reduce the amount of code per method and increase the number of method calls. And even if you go the other way, and don't use any methods at all, the simplest line in Ruby (since it's a pure OO language) will break down into 5 or 10 method calls, at the very least.
What all this means is, Ruby is back to that old argument of developer time vs. application run time, and I hate that. I really love it when we can break out of that mold -- when we find that, most of the time, a compiler will produce better code than handcoded assembly, or a language-based garbage collector can actually run as fast or faster than a hand-coded, application specific refcounting scheme. Or when we find that Java, despite being bytecode, will, once you JIT it, run as fast or faster than equivalent C++. Or when we find that mod_perl can be close enough to the speed of a C program that it's not even worth considering using C instead.
But when it comes to choosing a language, they all have their performance wrinkles. C++ probably uses more memory than C, and always seems to take far longer to compile. Perl isn't anywhere near as fast as C, so whenever we find something where we need that extra speed, we rewrite chunks of a Perl module in C. Python is the same way, though Psyco looks promising, but Psyco is also x86 only, not even amd64. Java is as fast as anything, once a program starts, which takes far longer than anything else even if you've gcj'd it -- plus, the language sucks compared to Ruby. C# is as fast as Java, and so far seems to load much faster, but the language sucks (really a rehash of Java/C++), IronPython is nowhere near done, and even IronPython isn't as nice as Ruby -- plus, the platform is controlled by Microsoft.
Ruby has absolutely awesome syntax, can be 10x faster to develop in than most other languages, but due to the language design itself, it will always be much, much slower than Perl, and that's saying something. And it's just depressing when you find you can make a chunk of your program run 10x faster by porting from Ruby to C, only it will take 50x more code.
I guess what would make me happy is an insanely intelligent compiler for Ruby, that targeted the
But that's depressing, too, because in the amount of time it would take me to learn enough about Ruby and
Don't thank God, thank a doctor!
Zope is the single largest waste of talent and innovation in the history of computer science. It's an amazingly well thought product, it solves every problem you might have when designing dynamic web sites, it solves problems you didn't even know, it comes functional out of the box, it takes seconds to install and get going, yadda yadda yadda.
Never in the history of computing science has so much innovation been so impossible to deal with. No real documentation, the simplest things are difficult, a buttload of half finished products none of which have any documentation to speak of. Most (yes MOST) zope products have no documentation other then it's name. You want to see a joke, go the zope collective on sourceforge. Now there is a crackup.
Dear Zope Community. I love the technology you have built, please make it so that I can use it. While you are at it please make it perform better then 1/10th of the speed of apache, php. You don't have to make it as fast, just don't make it like a joke.
While I am asking. Please create a sourforge or a CPAN for zope products so I can just install products without wading knee deep into dependency hell. Make it easy for me to keep my products updated. For examples of how to do this please see perl CPAN, ruby gems, apt, and yum.
Do this in time for zope3 so that the effort that went into that won't end up being a waste too.
Sorry if I am coming across a little harsh, I really love the ideas behind zope, I run a zope(plone) site, but it's much harder then it needs to be. Much harder then ROR for example.
evil is as evil does
Why not provide a couple links to a couple of projects using DDs so we can check them out.
In ROR the database IS your DD.
evil is as evil does
I read TFA expecting to learn something about why people talk so much about Ruby today. Unfortunately, there was only a comparison between RoR and Java. So, if the only reason to use Ruby is that it allows an agile development method to be used, sorry, Ruby came too late for that. I have been using PHP with phpGroupWare/eGroupware, which has every one of the advantages cited in the article, plus some more.
phpGroupware? You've got to be kidding! There is just no comparison.
One reason why I have so much impedance against Ruby is the different syntax. PHP has a C-like syntax, which makes it very easy to catch for someone who knows C and Perl.
Try Ruby for a week, seriously. I came from a mostly Perl/C/PHP syntax background and had little trouble picking up on Ruby. Once you start using code blocks, closures, true OO design, and all the Ruby nicities, you'll never want to fart around with PHP again. Here is an example of some really slick (in my opinion) ruby code. Lets say you have two arrays of objects that you want to add together, remove duplicates, and sort by an arbitrary attribute:
combined = (array1 + array2).uniq.sort_by { |obj| obj.someattribute }
What's wrong with Ruby's syntax? Well, the dangling "end", for instance. It's too FORTRAN-like for my taste. "end" what? With curly braces, there is never any doubt on the block structure if you use a modern editor, with Ruby's "end" you can never be sure of what ends where. I also prefer the curly braces instead of "begin"/"end" for the simple reason that it means less ink on paper, less clutter, easier to read listings. They say the Ruby syntax is "flexible", well so is Forth.
Of all the trivial complaints, that has to top them all.
Using Ruby instead of Java, OK, I can see why it's better. But I'm still waiting to see a good explanation why should someone use Ruby instead of PHP, or Perl, or Python, the three languages that have become so much associated with the "agile development" trend of software development.
Of the 3 you mention, only Python really matches Ruby. Perl is still king for processing text, but it is somewhat specialized in that. PHP is more or less just the lowest common denomonator among modern web programming languages. As a language it is nothing special and in many ways it is sloppy on inconsistent. I haven't used PHP 5 much, but last tiem I checked, object oriented PHP was a complete joke. Its only advantages are that it is easy to learn and runs just about anywhere.
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
Perhaps you should look at Lisp/Smalltalk/Your favorite academic language not being able to market their way out of a wet paper back:-) If they've had since the 70ies to build something that'll take off, and they haven't, they're doing something wrong, and it sure isn't the languages themselves, because they are very nice indeed.
... while, which is not part of the core language).
Changing subjects, one of *my* favorite "cheap Lisp imitations" (it's Lisp, not LISP) is Tcl:
http://antirez.com/articoli/tclmisunderstood.html
which is in some ways more flexible than Ruby - you can redefine existing control structures like if and while, or create new ones of your own (such as do
http://www.welton.it/davidw/
The heavy use of sigils is not Ruby's fault, it's yours. I've written a lot of Ruby code and have rarely used sigils.
Sigils in Perl are mandatory and define whether a variable is a $scalar, a %hash, an @array or a &block of code. Ruby's sigils define scope: local (no sigil), @instance, @@class or $global variable, which is a good approach since it let's you know instantly whether a variable is local to the block of code or comes from another scope, which is far more important than its type.
So, unless you're using a lot of global variables, you shouldn't be heavily using sigils.
Finally, I don't see anything wrong with having regular expressions as part of the language. But if you don't like that, nothing stops you from using Regexp and Match objects.
The best way to predict the future is to invent it
Windows is like decaf - it tastes like the real thing, but it won't get you through the day.
The secret sauce is "Hype". And if you lift the bun, you find that there's more secret sauce than meat.
The crux of the problem with that argument was brought up by the author of webwork, if I'm not mistaken. If you're coding so much that you really can get a 10x improvment then you're clearly not doing enough design work to be making an app that's worth shit, regardless of the tool. Rails doesn't cut down on the thought time.
DHH kind of tries to disown that comment when he's challenged on it. It's just rails marketing and hype, someone has whispered "10x faster" and they repeat it but they don't stand behind it. One thing that you can bank on, there is a lot of hype around rails, the people who make it are responsible for contributing to that hype and there is very little in the way of concrete information about these outlandish claims.
It's okay at what it does. I personally don't care for the hype and I generally distrust when all you have is hype.
Something else to consider, rails by design scales by pushing everything in to the database. They have some minimal caching at the web tier but none at the db tier. You need to render more pages, buy a bigger database, that's the quick answer and they suggest that it works because "yahoo does it that way" This is kind of an, um, interesting way to address scalability. I like how they make sure that they compare rails to what yahoo does too, it's just a quick and subtle comparison but it works and leads you to believe that you could do something yahoo like in rails, when it couldn't be further from the truth. Activerecord doesn't exactly conserve queries, some fairly simple joins seem to result in a lot of queries and it's kind of heavy. It's sales and marketing's way of saying they haven't really addressed the issue. To be pragmatic about this, why on earth are there all the elaborate caching schemes in EJB and J2EE and JDO? Surely people didn't just think it was something fun to build, I know the rails crowd seems to hate java but don't they think anyone with any real skill worked on it ever? I buy the j2ee is complex argument but I need to understand their argument for the complexity being unneeded. If you're planning to move on to a different project before it actually has to scale, that's not really an argument. From my own experience building clustered j2ee apps, scaling by just shoving everything into the db and hitting it for each page simply isn't a practical option if you have any real traffic.
I haven't used Ruby or Rails. I only read the ten minute tutorial that got posted here a while back. Actually reminds me a lot of a object wrapper I wrote for perl that built class heirarchies automatically from a DB schema. It was pretty cool if I do say so myself, and so is Ruby on Rails.
However: I don't think it matters. In my experience it doesn't matter that much what programming language or model you use. Object oriented or procedural, strongly typed or loosely typed, monolithic or microscopic, chocolate or vanilla. Everything eventually bows to the reality of inherent complexity. I've seen each style done right and wrong, and if they're done right, the differences sort of wash out over time. My prediction is that Ruby on Rails is great for prototyping, but if you ever have a large buisness project that grows and develops for years it'll end up no more productive and maintainable than any other competently written code base, and probably no less productive either.
I'm not saying none of these choices matter: they do. There are certain things I've written that are much more sensible OO than procedural and visa-versa. In the end you make decisions on how to go about a particular project, and if you've made the right ones five years later you can still carefully move at a crawl and bring new people into the codebase with only a few weeks of training. And I don't think any technology shift will notably beat that. I'm still a believer that there's no silver bullet that will make development (especially long term development) a breeze.
But what do I know? Use what makes sense to you.
Cheers.
Ah, but array_unique() only works on arrays with integers or strings for values. I looked it up. Check out the documentation on php.net for the array_unique() function and see all the ugly hacks that people have come up with to do what you could do with 1 or 2 lines of Ruby. My Ruby oneliner would work with any arbitrary object type. The reason the Ruby version is so much more powerful is because strings and integers are just objects like everything else. As long has you implement the == method for an object, it can be uniq'd or sorted (and many other operations) just as easily as an integer. In PHP you have to have special functions to do even simple things.
Sorry, I don't mean to sound like such a Ruby fanboy. I am really not. It is just that it frustrates me when people like the grand parent shut themselves out to learning something new. He says that he doesn't want to "waste a minute" on Ruby but he doesn't realize that he's probably already wasted countless hours writing PHP hacks that aren't even very reusable.
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
Indeed. Despite the touted benefits of .Net, and how it would rid us of all the system dependencies problems had with previous Microsoft technologies. Just a week ago or so I had the pleasure of running into a C# app that operated differently on 2 boxes. It was run from the same clean network directory, same version of the .Net runtime, same OS, all patched, and fetching data from an application server. There was absolutely no reason for it to behave differently, yet it did ...
...
People wonder why I like Perl so much
I've used rails for only a few months, but already have quite a good understanding of how everything works, and have even done some hacking/patching on the backend. I've also used ActiveRecord with some applications that are not web-based, all with good success. I love every convention in Rails, except for one, which I dearly hate.
ActiveRecord was designed quite obviously from the perspective of a MySQL user. The train of thought that a DB should only be a place to dump your data and nothing more is extremely prevalent with ActiveRecord. Things like referential constraints on foreign keys are completely ignored/not used, instead being defined in entirety in the model code. Perhaps my biggest aggrivation with ActiveRecord however is that it assumes I implement enumerations as varchar datatypes. I find this just plain wrong. Here's an example:
ActiveRecord way:
CREATE TABLE Users (
id integer primary key,
username varchar,
usertype varchar
);
ActiveRecord will then use its single-table inheritance logic and each subclass of User eg "Administrator" will have that name in the usertype field, stored as a string. From a data-modelling perspective, I find this so wrong. I naturally implement this using an extra table of usertypes and a foreign key in Users:
CREATE TABLE UserTypes ( id integer primary key, type varchar);
CREATE TABLE Users (
id integer primary key,
usertype integer references UserTypes(id)
);
I have managed to get ActiveRecord to play somewhat nicely with these types of constructions by redefining some class methods in ActiveRecord::Base, but I'm definately violating DRY.
This all said, and including the time I needed to spend hacking around in the ActiveRecord code, I am still more productive with Rails. Highly recommended, just with a hint of caution towards ActiveRecord paradigms and database integrity.