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."
It's clearly Unicode support.
Ruby on Rails seems to be a lightning rod for controversy. At the heart of most of the controversy lies amazing productivity claims. Crossing Borders author Bruce Tate has come to understand that 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. Then it looks at Rails-inspired ideas that should get more attention within the Java(TM) community.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
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.
Very strange, a web developement tool story shows up as "story currently under construction" with a red title bar. I click on the readmore link and the story goes blue. Then reloading the main page it is green.
Is this standard procedure for all new stories or is this some kind of gimick/pun on web developement stories?
-- The morphemes of your disquisition are ascertainable, but they have eschewed an ambit of transpicuous exposition.
I heard it was Kraft Thousand Island dressing.
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.
What about the fact that Rails is licenced under the "MIT License" while Java is (semi-)propietary?
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.
"Take this jar of mayonaise and leave it in the sun".
Blank until
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.
Python programmers can get the same kind of experience without learning a new languge with Django. Yes there are differences to RoR but the productivity gains are there. Django gives you database/object linkage, templates, views and all that, and a free and very very usable database interface generated from your model spec.
Oh, of course there's a big backlash against web frameworks these days isn't there?
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.
Actually, it can be said that the MIT license is in fact a very conservative license. It truly harkens back to the days of the Founding Fathers, when freedom was the utmost concern.
.NET), instead letting people focus on developing software.
It places very minimal restrictions upon users, while promoting free use of the software. I must repeat, with the MIT license, the emphasis is placed on freedom and liberty. It avoids the corporate shenaniganery we have come to associate with corporate software (such as Java, or
You don't need to be a lawyer to understand its terms. They're written so eloquently and comprehensibly that it is nearly impossible to not understand its terms.
In short, the MIT license is all about essential freedom, the kind America was initially built upon.
Porn, and the consequences thereof, is the 'secret sauce' of Ruby on Rails.
Those crazy open source programmers.
Would you kindly mod me +1 insightful?
I thought Ruby on Rails sounded cool, until I saw that it automatically pluralizes person to people. any computer language that does that, in my opinion is just to unpredictable to use.
Intron: the portion of DNA which expresses nothing useful.
QFT
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.
Could it be that case that I have not found it yet but it exixts? Point me to the URL.
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.
There are obvious borrowings from Smalltalk, LISP, Python, and Perl. There's a lot to like about Ruby's semantics; I just can't get past the syntax (which, in my opinion, borrowed quite a bit too much from Perl).
On Linux you just need to install ruby1.8 then download the gems package from online, install it, then do "gem install --remote rails". After that it's easy to keep things up-to-date and install more Ruby add-ons. I've never had any trouble.
Umm, what are you running? Everything installs via apt-get without a hitch on my Debian Sarge servers and similarly with urpmi on my Mandriva 2006 desktop. Do you have a very strange configuration, or a system that doesn't auto-meet dependencies? If you're on Debian or Mandriva feel free to email me and I'll try to help you out.
U.S. War Crimes blog. Email for free Mandriva support.
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.
Lighttpd embeds lua for use as a front end cache. There's also been a few attempts at a mod_lua for Apache. Lua is cool, one of my favorite languages and I much prefer it to ruby or python. If you haven't already, check out luajit and of course there's nekovm (& mod_neko) that looks like it's ready to deliver on some of parrots promises.
Rails just takes the best practices of "Web MVC" and factors them out so you can write code that's mostly YOUR logic instead of the MVC logic.
Ruby is an awesome language that makes this just a little easier.
Most web programmers who 1) know what they are doing and 2) are using a language like Ruby would already have their libraries laid out in a similar way. In fact, I'm sure a lot of good developers have their own "Rails-like" framework that they use to give themselves a competitive advantage.
Ask any seasoned LISP programmer how to write a program and they'll tell you: create a domain-specific language for the problem domain and implement your program in it. That's what Rails basically is.. a domain-specific language for Web MVC. Ruby isn't quite as powerful as LISP, but I think it gives people a taste of what that kind of programming can be like.. just because YOU don't use all that dynamic stuff, doesn't mean it's useless.
The one weakness in Rails is that the entire community apparently doesn't care about basic data management fundamentals. In fact, based on posts on his blog, I don't think DHH even ever studied the relational model. I don't think Rails and ActiveRecord encourages good database design, and in fact is a small step backwards. I would encourage people who care about this stuff to just ignore the "worst practices" offered by AR if you can.
For instance, where is the "logical DBMS" in an AR design? According to DHH and others, it's accessed via the AR classes. However, that is a network model, which is obviously not as general as a relational model. Or, where is the "logical model" of your business rules? Well, again, DHH claims it exists soley in the Ruby code, but that's obvious nonsense, it is split between the SQL database and the Ruby code, which is fairly sloppy. I like to see that clearly delineated in one place.
A relational DB with a Ruby-compatible type system would really blow the doors off Rails but I doubt I'll ever see that. I'd love to see that though! Imagine how Rails could simply derive the associations between entities by studying your relational design, and even derive error messages, forms, etc. Oh well.
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
It is Rails which does the pluralisation, this is not an inbuild Ruby feature! ;-)
Ruby istelf, being japanese, doesn't care about plural!
[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.
There's controversy about Rails? Since when? I've never heard anyone say anything bad about it -- but maybe I'm too skewed in what I read. Maybe I'm listening to the programming equivalent of Fox News. =:-O
I, for one, welcome our new Antichrist overlord.
OMFG! If this "notion" that learning about technology is a Good Thing has to be "advanced", something is seriously messed up at least in the Java[TM] community, but more probably in this whole "profession" of self-appointed Software Engineers.
Now please excuse me while I quietly cry.
So, for now, it's Java or Python, and associated frameworks for me. But not RoR.
1) Just like in any language, whether a programmer actually follows the MVC structure is mostly up to the programmer. I mean, I suppose you could specify a templating language which is less powerful in order to more strictly enforce things, but that takes language development time, programmer memory to remember two sets of syntax/conventions, and might be an unhelpful restriction for RAD/prototyping, which Rails is often used for. But rails generates models, controllers, and views, so you can hardly blame Rails for people who put app logic in their views. Or did you just think it was app logic because it was written in Ruby and you are used to single-purpose templating languages?
2) Well-written Ruby which uses the C database bindings just isn't slow. My web app, Kiko, has been Slashdotted 3 times now, with up to 20,000 log ons an hour on a single processor box with 512mb of RAM -- and not only didn't go down, it never even got slow for our regular users. Erins.de gets millions of hits per day on just a couple of boxes. It has to be set up properly to take that kind of abuse, but it most definitely does. As for search, there's just no reason to implement full-text search in the scripting language. MySQL has full text search, PostgreSQL has tsearch2 (a set of C libraries), and presumably other mature databases have their own solutions. All Ruby/Rails has to do is call the C code and format the results. This is a textbook case of using the right library for the right job--if you're doing image processing in Python, do you write your own image processor or do you call ImageMagick just like you would in Rails? Seems to me that full text search on a database is the same kind of well-defined problem set, and should be treated the same way.
U.S. War Crimes blog. Email for free Mandriva support.
The reality is RoR is terribly raw. You want to make a AJAX CRUD or a blog or something, it's one of a handful of technologies (django, seaside, php, zope, are others) that will allow you to do it very quickly.
If you want to build a real web application, it's terribly lacking. Don't believe me? Who is doing it? For real? Are there 500 RoR apps out there?
It's slick, I'll give it that but it's far from as complete as a lot of things. It's certainly not enterprise grade. No SOA support. No threading. No cache at the DB tier. You don't need that for your blog but you do if you're doing serious webapps.
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.
The secret sauce is ... a super secret Perl 6 / Parrot interface!
I have started a new web project and looked at RoR. Having done an app with Tapestry/Spring/Hibernate, I was sick of all the work one has to do to bring up a bunch of views in a browser and then persist results. I love RoR and Ruby for all the reasons mentioned in TFA. Note - I don't like the pluralisation default, but one can easily turn it off by setting the following in config/environment.rb:
. tss?l=RailsHibernate). The Data Mapper Pattern is almost certainly more efficient when implemented well (as Hibernate does). The coolest thing about Hibernate is that it is much more efficient than I am without a big effort on the persistence side, and I am concerned that Active Record will not be nearly as good. However, what are the odds that someone (or some group of people) will work on implementing a persistence solution within Rails that uses the Data Mapper Pattern? Pretty good, I would say. Once again, it probably won't be as good as Gavin King's work, but it will be "good enough". And if someone else does not do it, maybe I will start the project.
# Include your application configuration below
ActiveRecord::Base.pluralize_table_names = false
There were two scalability concerns I had about RoR:
(1) Ruby is interpreted and 'slow' - however, the JRuby team (http://headius.blogspot.com/) is working on running Ruby within a JVM (currently interpreted, but they are starting on a compiler). When they get to 1.0, the compiler won't be as good as Sun's, but it will probably be "good enough"
(2) RoR uses the Active Record Pattern and Hibernate uses the Data Mapper Pattern (http://www.theserverside.com/tt/articles/article
Given the above and the speed with which one can develop in RoR, the choice was obvious, to go with Ruby and Rails.
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.
So which "cheap imitation" camp is Forth in then with its dictionary?
"I put the blame for this squarely on the shoulders of modern computer science degree schemes."
Guess all those self-educated CS'ers are immune.
"People graduate thinking languages like Java and C are the state of the art, and then go on to re-invent concepts from the '70s believing that they are novel."
And yet Prolog is still in the closet.
InstantRails is your friend:
http://instantrails.rubyforge.org/wiki/wiki.pl
Reality is the ultimate Rorschach.
i recommend getting the 2nd edition of agile web development with rails.
/etc/profiles
here's how i did it on simply mepis... a debian distribution.
Ruby On Rails Install
1.Check to see if Ruby is installed. open shell and type "ruby -v". My result was "ruby 1.8.4", which is the latest version of Ruby.
2.libyaml-ruby and libzlib-ruby need to be installed on debian (in addition to its base Ruby install). install libzlib-ruby and not libzlib-ruby1.6. After all, you are running 1.8.x.
3.Go to http://docs.rubygems.org/read/chapter/3 (rubygems is like apt for RoR).
4.Download rubygems-0.8.11.tgz here: http://rubyforge.org/frs/?group_id=126
5.right click, extract -> extract here (should extract to its own folder).
6.navigate to rubygems-0.8.11 diretory, switch to root and run ruby setup.rb.
7.Update system by typing: gem update -system
8.add export UBYOPT=rubygems to
9.Synaptic irb.
10.Install PGSQL 8.1
11.Synaptic postgresql-8.1, libpgsql-ruby1.8 (pgsql adapter) and pgadmin3
btw, my php programming has improved by reading the agile web dev book. it is good - even if you don't end up going to it as a dev platform. if you are guru status, it won't be as helpful, but you could probably still pick up some good principles.
good luck.
As a programmer with a couple decades of experience, and having used a wide variety of languages, I don't see why people complain about VB. Can you give me some examples of why you think it's retarded?
There was no need to add that special case because in Perl, "0.0" does the exact same thing as "0 but true". Perl has a lot of such useless special cases - for instance the string "ignore" will not generate a warning in void context.
But Ruby, unlike Perl, has real booleans. So 0 is true. And "" is true. Thereby avoiding a very common source of Perl bugs. (Really, how many people religiously check defined in Perl? Not enough, else the need for "err" and "//" would have been apparent a long time ago.)
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
"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."
DSL's do even better without the "stuck in scriptland" effect. That's why things like Lisp and CLOS work so well because one can fit the language to the problem domain, rather than the other way around.
Sweet land of liberty, of thee I sing...
(weeps)
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'
Like it was pointed out in here other frameworks are older and more advanced then RoR.
Still RoR managed to break the mindset barrier of a typical US java programmer - and the sheer amount of people with such profile is so overwhelming that, in the end of the day, that's all that counts.
Folks ignored everything beyond J2EE for a long time. Think Zope history for example.
RoR happened at the moment java burden factor just reached some kind of a critical mass point.
The enthusiasm for RoR specifically surely is due to good marketing but I suspect typical American Japan-envy factor was as important.
Seriously, once you know the naming conventions, directory layouts, etc., it is very easy to find your way around a Rails project.
If you are working on a controller and want to mentally switch gears an modify the coresponding view, there is no doubt where to go (that is, which rhtml file to edit).
I find myself thinking about application problems and not framework problems. I am a little prejudiced right now: I am just finishing up the book "Ruby Quickly" for Manning (http://www.manning.com/watson/). I hate to admit it, but I am simply tired of developing in Java. Ruby is fun, and productive. I started a new AI project a few weeks ago, and I started all of the prototyping in Ruby. For one part of the system, Ruby is too slow, and I am replacing this bit of code with stuff written in Common Lisp. Still, for a large part of the system, Ruby is a great fit.
Can anyone give me a good, preferrably online, tutorial/introduction to RoR?
:-)
Being thorough isn't really a disadvantage; I'm not looking for a sloppy "learn RoR in 2 days" intro.
I thoroughly enjoyed e.g Bruce Eckel's free online books for C++ and Java, as a hint of what I'd be looking for.
Is there anything good out there online?
Beware: In C++, your friends can see your privates!
You could install it from Cygwin: http://www.cygwin.com/
When I first heard about Ruby, I just popped open a bash shell and typed "ruby". There it was! Cygwin has tons of utilities that you'll find when you really need them.
Since we're being pedantic: it wasn't a politics "discussion" until you joined in. :-P
all that stuff is lifted directly from Smalltalk
Well now I know RoR is bull because any article that is 90% about trying to debunk hype and talk about philosophy must be hiding something. You can easly find 10 Java programmers but if you're an expert in something that offers 10 to 1 productivity then you're going to be popular. My guess this is just another guy trying to drum up some business for himself. Not that there's anything wrong with that but you have to technical content to backup your claims. Let's see that "three lines of code to render a table".
Actually, Java developers ARE concerned about opening Java up. Here are some recent news articles from Googling "open java":
1 955870,00.aspu n-needs-turnaround-plan-that-/2006/04/26/1611586.h tm
http://www.thechannelinsider.com/article2/0,1895,
http://opensource.sys-con.com/read/216731.htm
http://www.tmcnet.com/usubmit/-analysis-new-ceo-s
http://www.technewsworld.com/story/50449.html
To all of which, Gosling has responded, "Nope", much to the chagrin of Java developers. If you haven't heard them, it's because you've been too busy complaining on Slashdot about Slashdotters using Slashdot to Slashdot.
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.
If catwalk (TG's automatic DB front-end) had been working when I was exploring web frameworks a few months ago I probably would have gone with TurboGears.
The docs say its 'slated for 0.9'...
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.
... by design. Thus, I presume, the use of the word 'Rails'.
:p)
You want a DB-driven site that hooks into a single DB for all its tables? You got it.
You want a site that hooks/controls multiple DBs, or want to stray too far from the paradigm? Not so much.
If your project is contained mostly or entirely within the Rails Venn diagram, you'll be happy. Otherwise, not so much.
(I looked into it for a site that would manage large #s of XML files, and found that going outside the one-DB-per-site model was very unfriendly, but then again, IANARP..
Unfortunately, Rails is limited by a couple of limitations that are really Ruby's limitations: most importantly the total Lack of Unicode support. I like most of the design of the Ruby language, but to not support Unicode in 2006 makes it essentially unusable for most projects where I would need it, including practically all Rails applications. Ruby is also not particularily fast, in some respects quite slow which also impacts Rails.
Zope has a seriously bad reputation from their 1.x and 2.x days. I don't know if they've reformed enough with 3.x, but Zope is "enterprise-grade" in a very real sense -- huge and complicated.
:)
I do appreciate RoR's marketing skills. They're really reaching out to Java and PHP users -- who I suppose are somewhat easy targets, considering how terrible web programming can be in those languages -- which I don't think the Perl or Python communities really tried to do. Since I'm a Python fan and Python is somewhat of a middle-ground between the looseness of Ruby and the solidness of Java, I'm hoping the Rails marketing brings some people our way
Try Lua's Kepler project; it can be deployed standalone, with Apache, or on Tomcat (throug JavaLua)!
Rails code I looked at looked very much like JSP/ASP/PHP gone bad. All sorts of code in HTML land.
How is that the fault of Ruby on Rails? You're supposed to move code out into helpers for MVC reasons, readability reasons, and re-usability reasons.
"Sufferin' succotash."
The best CRUD (edit/search/report screens) technologies I've seen involve data dictionaries (field tables) who's values/behaviors can be overridden as needed. The use of DD's turns app design into mostly data entry so that one does not have to code a bunch of attributes via zillions of set/get's. And, one can do relational operations on the DD's to search, modify, or copy them. The real secret sauce to fast CRUD includes:
* Data dictionaries
* Overridable event options as needed for stuff DD's don't do well or nitty exceptions to the rule.
* A good table browser to edit the DD's (something lacking in current web UI stuff).
I'll pit such against R-Rails any day. It is a lot quicker to fill out a table and inspect a table than to type in and verify code (at least for me). Coding nitty attributes is for people who like wrist injuries.
Table-ized A.I.
Will there be no end to this Noah's Ark of web languages? Must I be expected to learn every new web language some one trots out?
Allow me to list the animals in the Web Ark thus far:
After learning (either directly or about, and in order during my career)
C/C++
Perl
Java
Python
PHP
I am now reading about Ruby/RoR, I have been asked if I knew Rebol by one prospective employer, and I have also read on the web an article expounding the virtues of Lisp for rapid web development. Every one has been touted as the killer language for the web, every one has been "improved upon", every single one has been a requirement for some project or another. I have attempted to become familure with all of them, but come on! If I have to learn one more new web programming language in the next 6 months I'm going to blow a gasket.
So many frameworks, so little time...
I would love a comparison between Rails and perls Maypole and Catalyst or Phythons TurboGears and Django or php's cakePHP and smart3
Hard to find Ruby programmers, and their are more commonly known languages with comparable frameworks, some of which have been around longer (like maypole). Then again, Ruby fanatics are generally cream of the crop programmers and one wouldn't have to worry about PHP n00bs who can't really code or perl programmers who write line noise or the overhead of Java and it's seemingly required department of architects
Seems other languages are just as good, just harder to manage, but if you have top notch PHP programmers and Perl programmers who work well together to write maintainable code , I wonder how they would compare then?
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.
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. 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.
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.
Thank goodness.
They're really reaching out to Java and PHP users -- who I suppose are somewhat easy targets, considering how terrible web programming can be in those languages
And they're doing so from a position of strength and knowledge. Why, they even use PHP for the official Ruby on Rails site! Presumably to make sure they really know how their product stacks up against the competition.
Nice to see someone making some sense around here.
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!
I've spent the last month experimenting with RoR and Django. Although I prefer Python as a language, I found RoR much more exciting to use. Everything is nestled into a nice package. I understand why it appeals to .NET and J2EE developers who are used to rigid environments. Despite all this, I don't think RoR is going to save your life. Get over it fan boys!
Here are some things I noticed about RoR:
- The RoR community is full of obnoxious zealots (similar to the those who idolize Steve Jobs). Many tutorials are filled with chit-chatty authors who believe programming is a whimsical ride. I don't want to hear your cute jokes. Get to the point and tell me how to use the tool.
- PHP is installed on almost every *nix host out there. I can cook something up in PHP and deploy it just about anywhere. This is not the case with RoR. You have to find a RoR-friendly host or have your own server.
- Lack of Ruby programmers. This is likely to change with time though.
- What's wrong with PHP? It's is great for rapid development and not every site fits into the MVC paradigm.
So why choose one language over the other when they both excel at different things? People didn't stop using telephones when the Internet was invented. You're better off using both tools and knowing when to use them. People get obsessed with this stuff, and take it too seriously. Why are you programming in the first place? To be cool?
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
... or you could use http://www.catalystframework.org/, which has utf8 and internationalization support built in and tested from the core upwards and due to being written in perl can talk to pretty much anything you can find a CPAN module for (and via Inline::Java, ::Python etc. pretty much anything you can't, too).
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/
You're thinking of the Founding Fathers relative to Europe. Yes, they were liberal in that case. However, at the moment we're discussing America. So while they may have been liberal in Europe, today their beliefs form the true basis of conservatism in America.
That is evidently correct according to your definitions, as well. The traditions we're talking about in this case are those of the Founding Fathers. So anyone who follows their traditions of freedom, liberty and justice is indeed a conservative.
Remember, 'American conservatism' is all about freedom. From an American political standpoint, the only fairly mainstream party truly following such conservative traditions is the Libertarian Party. Most Republicans these days are best classifed as neoconservatives, who basically have nothing in common with the true conservatives. And of course the Democrats today are basically the same as the Republicans.
It is quite correct to state that a license like the MIT license, which aims to maximize freedom for all parties (even those who wish to proprietarize a piece of MIT licensed software), is indeed conservative from an American viewpoint.
they even use PHP for the official Ruby on Rails site!
Nope
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
Um, aparently they do:
/index.php (common basename)
http://www.rubyonrails.org/INDEX
----
Multiple Choices
The document name you requested (/INDEX) could not be found on this server. However, we found documents with names similar to the one you requested.
Available documents:
*
----
Though perhaps they're just slapping on PHP extensions, but I don't know why they would.
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.
Ruby is sorely lacking unicode (not that other languages do so hot). Otherwise Ruby is great.
...is that you'd have to be tripping to use Ruby on Rails? Sounds about right.
What I would think would be really cool is a Lua plugin for Apache.
Google for "mod_lua".
Alliteration. Ruby on Rails: it just _sounds_ good.
What it actually _is_, I don't know. I know approximately what Ruby is, although not intimately, but I have no idea what the rails signifiy in technical terms, although they presumably connote rapidity of some sort. If I were a Ruby programmer, I'd certainly want to know what this Rails thing is all about.
Whether it sounds good enough to make me (as a Ruby outsider) want to learn the language is another question. Frankly if I were to learn Ruby it would probably be more due to the good things I have heard about it from sources like perl6-language, than due to Rails, because whatever other tools you use the quality of the core language is critical to their usefulness, so as a programmer it's the style of the language I want to know about first. (This is part of why I never picked up Java: the GUI libraries it comes with are supposed to be really great, but nobody with similar tastes in languages to mine ever has many attractive things to say about the design of the language itself; Ruby, OTOH, does regularly get positive comments from people whose opinions on language design I respect greatly.) Nonetheless, if I *did* take the time to learn Ruby, and if I found that I liked it as a language, Rails would definitely go on my to-learn list then, *despite* that I don't actually know what it does. Because, you know, it just sounds good. Probably looks good on a resume too.
Cut that out, or I will ship you to Norilsk in a box.
...the gayest name EVER?!
"This means it already overcame the greatest hurdle of any web-development framework from day one"
.NET, hell, even Objective-C frameworks manage it. It's a solved problem; bragging about it just makes you look clueless.
You give Rails far too much credit.
First, among popular development environments, anecdotal evidence strongly suggests that Rails is _hardest_ to scale in the sense of "serving lots of pages really fast," mostly due to Ruby itself being pretty damn slow. I'm not a J2EE snob trolling here: it really is. For small sites this doesn't matter because your glue language is much less of a factor than hitting your database, but as you start caching appropriately and so forth Ruby really does become a liability.
Now, Rails does make it easy to scale in the sense of "if I throw more hardware at the problem, throughput improves." But this is not a difficult problem. Arguing that "[m]ost Scheme/Lisp frameworks, for instance, still haven't achieved [that] level of scalabilty" is silly and probably false, but I'm not enough of a Lisp weenie to know. I _do_ know that Python, PHP, Java, TCL,
I'm reading more and more about how ROR as a web app scales very well for large scale sites. For yself I'm learning how to do some advanced things with it, here is my HOWTO speed up ruby-on-rails with memcached:
y -on-rails-with-memcached
http://fak3r.com/articles/2006/05/11/speed-up-rub
fak3r.com
Hah, that's pretty funny. Apparently they *do* use PHP for parts of their site, as the creator admits.
There is no special sauce. It's just the latest hyped toolkit that will be gone next week. Look for Jarva or D++ or whatever trendy new thing pops up in software next week that does absolutely nothing.
Listen kids, there is no silver bullet. For all you folks that dropped out of college/high school who generate the ad clickthroughs that make these stories submittable: Fred Brooks, The Mythical Man-Month. Read it.
ROR is just a tool. like all tools, it's good for certain things and some people find it useful. It's no magic bullet, but the ROR crowd feels like they have a magic sauce. The sauce is herione from crack addicts like Bruce Tate who feels a need to sell more books and call himself smart, a thought leader or what ever bullshit title he thinks is appropriate.
Actually there's only one ruby lucene port, ferret, which is now written in c.
It's running plenty fast for me.
I don't understand the advantage of a pre-designed framework, MVC really
isn't that difficult to implement.
I find that, rolling my own MVC results in exactly what I need, nothing more. Simple and very easy to follow.
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.
Ruby programs run in an interpreter written in C/yacc. The interpreter is slow and problematic (threads, unicode, it's all been said). Since ruby is defined by this one interpreter implementation (there's no written standard and the only way to create one would be by _fully_ understanding the interpreter), this tends to form a ceiling on Ruby's scalability.
Whence? Hence. Whither? Thither.
I think most of the attention ROR is getting is just hype and secondary hype. The first wave of hype drew a lot of PHP developers (90% without any real clue about programming) to evaluate ROR. And of course, compared to PHP ROR is like a gift from heaven.
After the hype around it persisted I tried it out myself. My impression was that it is nice but nothing worth that much hype -- plus I don't really like Ruby that much, its syntax seems to make too many things different just for the sake of it.
The good thing about ROR is that it belongs to a new current breed of web development framework putting emphasis on rapid, easy development. I like the pythonic Turbogears very much (especially the upcoming 0.9 release).
while (!asleep()) sheep++
1. Hierrarchical structures and hash tables are not related in any way. The advantage of easy declaration comes from syntax and not from hash tables. A language with syntax that allows easy declaration of hierrarchical structures has the advantage over a language that does not offer such a functionality, but overall this has nothing to do with hash tables. You could do the same thing in LISP and in a much better way.
2. Declaring members within methods is a bad practice: it makes maintenance more difficult. Suppose you want to change a member's name from @foo to @bar; the compiler\interpreter will not inform you that you did not change all references of @foo; now your object will have two members @foo and @bar.
3. The VM does a loopup in a map or a table. If the relevant entry in null, the method is declared as missing. But changing methods of a class at run-time is not good, because it allows the programmer to easily violate the contracts of the class. Not only you have destructive update in Ruby (please search online why destructive update is the root of all problems), but you can also change methods on the fly. Furthermore, LISP's 'defmacro' has nothing to do with methods: the 'defmacro' function introduces a new function which is to be invoked at compile time (thus a 'macro').
4. Scalability is not a factor of language, but of framework. Don't you think that J2EE scales well?
5. A web development system is not a messy undertaking; in fact it is very easy to build a web framework, since a web application is nothing more than a message-driven application. There are various frameworks in the market which make web development very easy in all languages (even C++ with FastCGI is a good solution).
6. There are Java frameworks that do not have a "pre-processor", like Echo, for example: all you have to do is write a web application as a desktop one, replacing Swing views with Web Views. I agree it is a bad idea to write Java within HTML, but you are presenting Java as if it is not capable of having a "language only" framework, i.e. a framework without XML/HTML, which is totally wrong.
I followed the instructions here http://www.rubyonrails.org/down on Windows XP and it worked straight away.
I tagged this one as sauce. Nobody else did. Tagging ROCKS! :D
8 of 13 people found this answer helpful. Did you?
Why, they even use PHP for the official Ruby on Rails site!
That's because it's a website not a web application. The strength of PHP is for a little dynamic code here and there as you need it. The strength of Ruby on Rails is developing web applications.
Hey guys I am a student and I have been working with ruby on rails for the past 4 months. I have to say taht I dont like it. I find that it is a pain to learn a new programming language just to use it. Instead of HTML ruby on rails uses RHTML. This is a pretty easy code to learn and use but I still dont enjoy it. However I am impressed at how quickly you are able to set up a web site. I havnt been able to make a very good looking website but i was still able to make it quickly. Over all I think that RoR is not as great as I thought it would be and I prefer the old way of making web sites with DreamWeaver and Photoshop. I know that RoR is all free software which is good but I think that the price is the only good thing about RoR.
TurboGears is similar to Rails, but in Python. I don't believe it was inspired by Rails, but the TG people are using the Rails momentum to guide development (in terms of what's working for Rails and what isn't) as well as borrowing a few marketing ideas. (For example, the 20-Minute Wiki tutorial.)
I'm neither a RoR or TurboGears guru by any stretch, but near as I can tell, these are the main differences between Rails and TurboGears (real gurus are welcome to correct/add to this list):
1. No need to learn a new language (if you already know Python). Relatively few developers knew anything about Ruby before RoR became a hit, while lots of people know Python.
2. TurboGears comes with less magic built-in. Which is actually a boon for most people because a few that I've talked to thought that all of the magic in Rails ended up making non-trivial applications hard to both develop and debug. TurboGears is much more verbose. Sure, you have to write a few more lines of code for many typical tasks, but you also have a much better idea of what's going on in your application and can debug it quickly when it breaks.
3. TurboGears ties together several pre-existing projects into one framework rather than rolling their own. This offers a couple of nice benefits. First, it's less work that the TG developers have to do. They neither had to write nor have to maintain much of the code that TG rests upon. Second, it's possible that one sub-project can be substituted for another later on down the road. (I understand that they're already using this feature and are in the process of migrating SQLObject out and bringing SQLAlchemy in.)
4. Better documentation. Python is already exceedingly well documented and the TG folks are going out of their way to make sure that their framework is documented just as well. By contrast, if you're just starting out with Ruby and Rails, the best documentation available right now is a Ruby book and a Rails book, both by the same publisher. Part of the reason I didn't go too far into Rails was because I couldn't afford to invest in the books at the time. (There is a TurboGears book in the works by Mark Ramm which should be out later this year.)
Of course, one potential downside to TurboGears is that you have to learn how the various sub-projects work in order to use TurboGears. But they're not all that hard and are probably about the same amount of effort to learn as all of Rails.
There are also a couple other really nifty things about TG that I'd like to mention. (I don't know if rails has these or not.)
The templating engine, Kid, allows you to draft up a template and give right to your web designer, with placeholder text and all, and have them hack on it in Dreamweaver or whatever they use. When they're done, just copy it back into TurboGears and it simply works. Kid uses real HTML tags and attributes, so web browsers can view the templates directly and HTML editors can edit them without mucking up the template-specific stuff.
CatWalk, the built-in AJAX database editor can be enabled in your TurboGears app by inserting like two lines of code. Talk about sweet.
If you don't realize the issues with putting logic into the database (never mind the performance hit) you've got some serious learning to do.
If you're looking for "advantages", I would suggest MVC architecture in general. Without that basic understanding, you will never see the benefits in Ruby/Rails.
Rails solves problems. Plain and simple. It was built from day 1 to address a specific problem, (basecamp) and now the creators have found that a lot of people have very similar problems to solve. That's it. That's why it's so good.
It does not try to solve every problem, like J2EE. It is not a solution looking for a problem, like it's many Python-based cousins. It won't solve every problem, and makes no claims to do so.
But if your problem is a web-application with a (smallish) number of variables, RoR is a godsend.
Do not associate 'secret sauce' with 'porn'. I had a Big Mac for lunch, and it brings, er, unsettling images to mind.
...when implemented well (as Hibernate does).
You're joking, right? Hibernate has so many flaws as to be almost unusable for large projects. We evaluated it for our project and found that Hibernate wasn't performant for anything beyond simple simple 1-1 domain-object-to-table mappings. We ended up going with a custom persistance solution based on code generated from Java5 annotations on our domain objects (and yes, we know that annotating model objects with persistance logic is bad practice, but it saves us so much work that we chose to do it anyways). Our generated queries are just as fast as Hibernate for simple 1-to-1 mappings and up to 4 times faster for more complex logic. Our implementation (which admittedly isn't wrapped in as nice a user interface), implements the same pattern as Hibernate and is much more flexible and performant.
Is it possible to get more performance out of Hibernate, definitely. There are experts who understand the inner workings of Hibernate that can bring it closer to our performance metrics. However, if you read the Hibernate boards, you'll see no shortage of discussions about working around bizarre Hibernate behavior. So much so that we decided it wasn't ready for prime time.
So yes, Hibernate out-performs ActiveRecord...it would be hard not to. But Hibernate is still a pretty poor implementation of the DataMapper pattern. Not that SQL Maps, EJB 3 or TopLink are/will be any better.