Slashdot Log In
What's the Secret Sauce in Ruby on Rails?
Posted by
CmdrTaco
on Sun May 14, 2006 10:25 AM
from the having-a-hard-time-caring dept.
from the having-a-hard-time-caring dept.
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
It's Ruby (Score:3, Insightful)
Re:It's Ruby (Score:3, Funny)
I guess you will love LISP macros.
Lisp, Smalltalk, and...Tcl! (Score:3, Informative)
Changing subjects, one of *my* favorite "cheap Lisp imitations" (it's Lisp, not LISP) is Tcl:
http://antirez.com/articoli/tclmisunderstood.html [antirez.com]
which is in some ways more flexible th
Re:It's Ruby (Score:3, Informative)
Re:It's Ruby (Score:3, Interesting)
Actually, Java has considerably more features than C++, including garbage collection, runtime safety, well-defined dynamic loading, full reflection, and runtime code generation.
With a tool like Ruby, someone has created these "library" routines for him.
Ruby's libraries are poor compared to Perl's or Python's, so if it all were up to library code, Ruby wouldn't be popular.
so, what innovation did C/C++ give us? General Purpose tools. The fact that
Relentlessly applying best practices (Score:5, Informative)
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.
Re:Relentlessly applying best practices (Score:3, Interesting)
Am I the only one who was reminded of Ajax at this point? Old technologies put together, lots of hype...
Re:Relentlessly applying best practices (Score:4, Interesting)
AJAX is based on technologies with extremely poor design and implementation, such as browsers, JavaScript, and HTML (poorly designed for this application, perfectly ok for marking up documents). Rails takes lessons learned from a decade of server-side Web development, as well as the catastrophe that has become J2EE through over-engineering, and simplifies it to the essential mechanisms. Built on top of Ruby, which is itself a pretty thin simplification wrapper over C++, it combines the simplification of Web site development best practices (MVC, proper tiers, etc.) with the power of an high level development language overlaid directly on top of a low level near-assembly language, with the ability to perforate the abstraction layer (first through modifying Rails source in Ruby, then through C extensions) if needed for performance or other reasons.
Short, brutal version: AJAX built on crap by script kiddies, Rails on bedrock by software engineers.
Parent
Re:Relentlessly applying best practices (Score:5, Insightful)
The only part of that I'll give you is the poor IE implementation of CSS. Browsers' main problem lies in their non-compliance with standards. Solution: test in multiple browsers. WOW, THAT WAS HARD. Next up: JavaScript. Poor design? I was shocked at how powerful the language is when I finally started digging into it after years of avoidance. Poor imlpementation? Not really - just many different implementations. Of course, this can and has already been worked around with libs that abstract the differences away for you. HTML? It still is used as a basic markup language, with all the heavy lifting being pushed into the CSS. Now, CSS is nowhere near perfect, but it does function admirably in the scope of AJAX (when not using IE's broken ass implementation).
Rails takes lessons learned from a decade of server-side Web development, as well as the catastrophe that has become J2EE through over-engineering, and simplifies it to the essential mechanisms.
I half-agree. You imply a minimalism that isn't present. The framework is quite complicated in places and does a lot of tricky things. You see, programming with just the essential mechanisms sucks; you've gone back to CGI.pm. What Rails does is provide a massive lever with which to move your problem. The Actual Work Done Per Line of Code metric exceeds any other framework I have used before. Code efficiency is the watchword, not simplicity.
Built on top of Ruby, which is itself a pretty thin simplification wrapper over C++,
No it isn't. Ruby's implementation is a big, slow VM that doesn't act much like C++ at all. Really, the poor performance is the only thing I dont like about the language.
it combines the simplification of Web site development best practices (MVC, proper tiers, etc.) with the power of an high level development language overlaid directly on top of a low level near-assembly language, with the ability to perforate the abstraction layer (first through modifying Rails source in Ruby, then through C extensions) if needed for performance or other reasons.
That sounds like marketroid speak, and is about 3/4ths BS. Perforate the abstraction layer? Jesus. And just who is running around writing C++ extensions for web apps? Almost nobody. Takes too damn long, and isn't as safe as running through the VM.
Short, brutal version: AJAX built on crap by script kiddies, Rails on bedrock by software engineers.
DHH is something closer to a hacker, not to mention the fact that rails utilizes AJAX and, more generally, javascript all over the place. Does that make AJAX apps built on top Rails rock? Or does all that terrible, awful AJAX stuff diminish Rails? Maybe they, I don't know, utilise the same foundation technologies and standards and complement each other quite nicely? Maybe you are an idiot?
Parent
Re:Relentlessly applying best practices (Score:5, Interesting)
No, it really doesn't, and to claim it does is to ignore the wide range of uses of object persistence. What it has is a great design for getting web interfaces up and running quickly on databases. It has a very poor design for long-term maintenance and growth of applications.
The ActiveRecord pattern is of limited use, especially as implemented in Rails. Your code is not isolated from major changes in the schema, and the dynamic nature of Ruby means that the consequences of such changes can't be tracked by compilation or refactoring tools; especially as the model classes don't even exist as code. Tests are a good way to help with this, but try and design tests to deal with potential schema changes for a large application that may have transactions involving thousands of records...
To see what a good persistence system should be like, take a look at Kodo or Xcalia - very high performance persistence system that allow exactly the same code and queries (which are automatically highly optimised for the particular database - not some minimal portable subset of SQL as in Rails) to be run on small embedded databases and high-end clustered systems. Unlike Rails, these systems can handle transactions of hundreds of thousands of records (something that is not that uncommon for commercial work) without thrashing disk or memory. You can also use the same code to persist and read to XML, LDAP and many other types of store. And yes, these systems also have 'convention over configuration' like Rails - they got there first, and had it years before RoR.
RoR has some great ideas, and definitely has its uses, but to claim it has near perfect design is way out, and sorry, but best practise in data model design in object oriented languages like Ruby does not involve basing things on non-OOP relational tables!
Parent
What Java can learn from RoR (Score:3, Interesting)
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.
Re:What Java can learn from RoR (Score:4, Interesting)
Parent
The secret sauce is ... (Score:3, Interesting)
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.
Rabid IP Hoarders and their Sauces (Score:4, Insightful)
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.
Podcast with Author Bruce Tate (Score:3, Interesting)
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 [rubyonrails.com]
Special sauce? (Score:5, Funny)
[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.
Hidden reasons why ROR works so well... (Score:5, Informative)
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.
Re:Hidden reasons why ROR works so well... (Score:4, Interesting)
What's great about Ruby? Community, community, community. The ruby community seems to be adopting the mantra of DRY (don't repeat yourself). If any project comes along and it shows superiority then the whole community gets behind it and it quickly becomes a de-facto standard. That's what happened with rails even though there were/are competing frameworks. Same thing with Mutt for example.
Lastly the Ruby community early on were not afraid to take great ideas from the ecosystem. Gems for example is the ruby version of CPAN (the best thing about perl is CPAN). The python guys still haven't figured out why CPAN and gem are important. Ruby community doesn't seem to suffer from the not invented here syndrome.
Parent
Still no Unicode (Score:5, Informative)
So, for now, it's Java or Python, and associated frameworks for me. But not RoR.
Re:Still no Unicode (Score:5, Interesting)
-Dom
Parent
RoR hype == good product + good marketing. Period. (Score:5, Interesting)
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.
Re:RoR hype == good product + good marketing. Peri (Score:3, Interesting)
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
Ruby is slow (Score:4, Insightful)
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
Re:A question... (Score:3, Insightful)
Re:A question... (Score:5, Informative)
Fact is that Rails template (rhtml files, the views) are scripted directly using Ruby (there is no specific view/template language). This means that they can be abused, not that they should.
When used well, Rails views are actually quite clean due to the high readability of Ruby itself and the ability to rapidly create so-called Helpers (Ruby methods that you can call from your views, to build specific HTML structures from generic datum, since you come from JSP land think Taglibs, but much simpler to define & use)
Seems like DHH found Ruby simple enough to just use it as a templating language (and it works quite well), that's his choice, other frameworks in other languages picked a different one (Python's Django has a template-specific language for example, much simpler and less powerful than full blown Ruby but much less prone to abuse either)
Parent
Re:A question... (Score:3, Interesting)
As to your sig, I can't say I have any love for VB (especially after being forced to use it), but after trying to deal with the MFC and doing GUI aps in C++ on a windows machine, I
Re:Rails zealots aren't hammers, they're just tool (Score:4, Interesting)
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.
Parent
Zealotry, or simply inexperience? (Score:4, Informative)
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.
Parent
That or TurboGears. (Score:5, Insightful)
(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.
Parent
Re:i thought Ruby on Rails (Score:3, Insightful)
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.
Re:i thought Ruby on Rails (Score:3, Insightful)
Re:i thought Ruby on Rails (Score:4, Funny)
-matthew
Parent
Re:i thought Ruby on Rails (Score:3, Informative)
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
Re:Nice Summary. (Score:4, Funny)
Parent
Re:Nice Summary. (Score:3, Insightful)
Re:Nice Summary. (Score:3, Insightful)
Re:My problem Ruby on Rails (Score:3, Informative)
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 [sgtpepper.net] unstable/
deb-src http://www.sgtpepper.net/hyspro/deb [sgtpepper.net] 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 "
Re:Liberal license (Score:5, Interesting)
Parent
Re:Liberal license (Score:3, Insightful)
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 h
Re:Liberal license (Score:3, Insightful)
Re:Yes, but can Ruby do this? (Score:3, Informative)
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.
Re:It's multiparadigm. (Score:3, Interesting)
Uhh, dude... that is Smalltalk. Smalltalk was specifically designed to meld OO development methodologies with the power of functional languages like LISP. Why do you think that blocks and functions are first class objects in Smalltalk? Or that it has proper lexical closures?
In fact, every time I look at Ruby, all I see is a pale reflection of Smalltalk. I've yet to see anything new it brings to the table
Re:It's multiparadigm. (Score:5, Insightful)
Deliverable packaging. Extracting a Smalltalk program from the development environment for distribution is, to be generous, annoying. Which is one of the reasons why Smalltalk works so well in an academic environment, but never caught on for commercial work. Ruby, on the other hand, is about as tough for someone else to deploy as Perl (it isn't).
This is one of the places where Java really changed things and is IMHO, the big reason for why Java has become so popular.
Regards,
Ross
Parent
Re:Yes, Ruby's semantics are sweet. (Score:3)
$_
Perl vs. Ruby: sigils (Score:3, Informative)
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,
Re:Posted on IBM (Score:3, Insightful)
-matthew
Re:Rails is nice, but definitely limited... (Score:3, Insightful)
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, mayb
Re:What's the Secret Sauce in Ruby on Rails? (Score:3, Insightful)
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 missin
Re:CRUD screen secrets - Data Dictionaries (Score:3, Insightful)
In ROR the database IS your DD.
Re:What about PHP? (Score:3, Insightful)
phpGroupware? You've got to be kidding! There is just no comparison.
One reason why I have so much imped