Posted on by Jonathan Edwards

What is Ruby&Rails’ secret of success?

The history of programming languages is depressing. Generally worse is better. Socio-economic factors dominate. But there seems to be one giant exception: Ruby & Rails. I haven’t studied them deeply, but they look like really good work that has succeeded on its merits. Ruby is a tastefully designed language with a coherent philosophy of making programming easy and fun. Rails righteously smites the bloated complexity of the Big Java web frameworks. Gotta love it. So how did it win? This undermines my entire cynical world view. Can anyone explain how it went down?

Update: note the obstacles. Ruby had dubious performance. It was developed in Japan, doc translation from Japanese was incomplete and laggy, the dev lists were largely in Japanese. Scripting languages were not considered suitable for large-scale applications. Ruby was not used for a lot of server-side programming. Rails took away many checklist features that people thought they needed. People had already built cool web frameworks in LISP and Smalltalk without anyone much caring. What fortuitous combination of factors allowed Ruby&Rails to succeed? How important was the DHH cult of personality? I’m guessing a lot.

43 Replies to “What is Ruby&Rails’ secret of success?”

  1. That’s simple. Simple things were simple, and you could get an application out before you had really learned Ruby. People were getting things done in a day that took a week with Struts.

    Oh, and the railscasts were key. An example is a lot easier to follow in that form.

    I happen to think that a similar framework could have come out of java (and I guess others tried it later) but they didn’t fit within the community philosophy.

    1. Railscasts didn’t exist in the 0.3 beta days. Actually, I don’t think the Internet programmerazzi started using vodcasting for technology demoes until a year later…

      Back in 0.3, there were just a few people blogging about it, but they were the right people.

      Jonathan, I recommend reading Duncan Watts’ Small Worlds book.

      Apart from that, I think perl had been around long enough for people to realize it was horrible for production systems where you actually had to maintain perl. A lot of system administrators started picking it up, too. For example, Puppet blew away cfengine because the cfengine people completely misunderstood the problem domain and totally ignored repeated user requests. cfengine didn’t give a shit about packages or anything useful. Instead, it was designed by physicists who had crazy convoluted vocabulary to describe how cfengine 3 was going to work. And cfengine 3 didn’t fix the biggest complaint about cfengine’s predecessors, namely that you had to restart the daemon in order to propagate changes. With Puppet, they took advantage of Ruby’s dynamism.

      Also, I strongly disagree with Jonathan that Ruby is a well-designed language. I like Alan Kay’s quote in this regard: “A person who took the position that there are *no* good computer languages would be much closer to the actual case!”

      1. I fervently agree with Kay on that, and I have essentially dedicated my life to fixing it. But compared to other languages that actually exist, Ruby is a nice piece of work, and has its heart in the right place.

      2. Maybe Railscasts didn’t exist, but I’ve started with 0.13 and I’ve started because I’ve seen the screencast that showed how to build a blog in 15 minutes (including instalation of Ruby and Rails).

  2. I wish I knew more of the history, but this looks like a combination of high merits and delivered merits over time. I get the impression that Rails gained its foothold by addressing socio-economic factors right off the bat and before it evolved into today’s high-quality product through consistent updates and revisions, which sometimes include taking things away or breaking things temporarily. I think that we can credit Ruby’s well-founded dynamic nature (as a start) for making such refactoring possible and then thank the test-first, test-driven development mentality of its creators for making the refactoring actually happen. They have my great appreciation for sparing us all yet another crufty framework and for delivering us a lean, mean, focused web machine instead.

    2. I haven’t really studied it, but I have a feeling the reason it succeeded where previous quality programmer-friendly frameworks didn’t was the simplicity and accessibility of its message. You could watch a 10m vid and “get it” and want to learn more, then you could watch a few 10m vids and be ready to start coding. You could also learn ruby in the nice interactive web tutorial (forget the name of it now). DHH’s slides always had one simple idea on them.

      It probably didn’t succeed on it’s own merits, it succeeded on its own merits + great messaging/presentation.

  4. I was actually in the right places in 2004 to watch Rails appear out of nowhere, gain momentum, and eventually hit the covers of popular PC magazines.

    It was basically a brilliant marketing campaign, combined with technically great tools (Ruby, Mac OSX, TextMate), and useful support materials (books, screencasts, talks).

    It was a lucky convergence and hard work that made it take off.

    In detail:

    1) DHH did great soft-sell marketing.

    He started posting on the message boards and blogs of web developers who were using PHP, Python, and Java. He’d answer their Java/PHP/Python questions and be very helpful. He gained a reputation for being a nice and knowledgeable fellow.

    Then, whenever a user noticed that an operation was inherently hard in PHP/Java/Python and should be improved, he’d mention that Ruby was much more flexible, and that Rails let you do these things better.

    2) Screencasts

    I think the original Rails screencast was what got most people hooked. It was great — DHH showed that you could make a blog in 10 minutes, and it was really nice.

    He also showed off all the great tools he was using — TextMate (which DHH actually helped develop, to make it a better Ruby/Rails environment), that MySQL frontend thing, and Mac OSX.

    Which leads to the next thing…

    3) Mac fever

    Lots of web developers had started using OSX just before Rails got popular. Rails would’ve failed if web developers were using Windows, because Ruby totally blows on Windows. It’s so slow. And Rails is even worse.

    4) Friendly community

    From the get-go, there was lots of sharing. All the rails core team would blog about useful Ruby/Rails tricks they learned. People on IRC would be patient and helpful. It was a killer support ecosystem.

    5) The Books

    Pragmatic Programmers published two books that really helped Rails: A second edition of the Programming Ruby (Pickaxe) book, and Agile Web Development with Rails. Most early Rails programmers learned from these two books, and they replaced the giant mountain of Java books you’d have to learn to be able to accomplish the same tasks.

    6) The technical merits.

    Ruby’s metaprogramming capabilities plastered over enough holes in the leaky web abstraction to make a lot of the web development pain go away.

    I think that’s it.. 🙂

    1. Thanks – that’s exactly the kind of detailed analysis I was looking for. I remember how the screencast was a huge hit. That was before YouTube, and it really woke people up to the power of internet video. My original Subtext screencast was around the same time, and I got some attention from analysts noticing the trend.

      1. Hah! Man, it’s so hard to remember a time before youtube. How did we manage to surive?!

        I forgot to mention another important facet of Rails’ success:

        7) Framework designed to support a real-world application

        Rails was originally extracted from Basecamp, which DHH was developing in Ruby. All of Rails’ features were there to support a full-on, used-by-real-people program.

        Most web frameworks from that period were really half-baked (especially in the Python world, which had about 237 of them). They were built using the “Hello World”-Oriented Design philosophy, where the author would develop the framework to the point of supporting the cool examples in the README file, and then kinda just give up. 🙂

    2. A lot of the pains in Java web frameworks could be seen as trade-offs, since some performance critical systems cannot take advantage of all the reflective goodness. From that standpoint, we might say that while Ruby allows programmers to manipulate the static production rules of the language through meta-programming, it does so at run-time inefficiency.

      A lot of Java frameworks after Struts began adding similar run-time inefficiencies in exchange for developer productivity. For example, JBoss Seam, with its support for stack-based representation of a Continuation-based web server, paired with Hibernate for the DAL, and improvements to the awful JSPs by replacing them with lighter weight, easier to test code.

  5. Culture. I like to recognize the importance of culture. The post that mg links to (su-shee’s) covers the cultural difference, but I think it’s fallacious to think of it in terms of promotion alone. Culture and framework technology have a really tight feedback loop. It’s not just a unidirectional, evangelical push.

    I don’t know many serious Ruby or Rails developers who think they are cool because they use Rails. Reverse that: they use Ruby and Rails because they think (know!) they are cool.

    A programming community that self-identifies as “rockstars” is likely to embrace both lifestyle and technical choices that reinforce that self-image. Sticking It to The Man somehow; breaking with tradition, working really hard to set oneself apart … that’s rockstar stuff.

    Contrast that with “monk” or “guru” cultures, with their introspective focus, and a tendency to be exclusive rather than inviting all aboard.

    Or contrast the culture of status within the business enterprise. Most of the accomplished Microsoft and Java developers I know are professional engineers. They identify best with the title on their business card and the annual salary flowing into their bank account. They make different decisions, for different reasons, and the discussion in their culture is a different one from the Rubyists’.

    The rockstars du jour aren’t all over the moon about Rails anymore. At the rockstarry conferences — even the ones labeled Ruby____ — they’re on to node.js, rediscovering FP, metaprogramming, the HTML formerly known as 5, and ever-terser template languages and microframeworks.

    So of course the rockstar culture will continue, and I’d be shocked if the next decade doesn’t see at least one more Big Thing come out of it. It will follow the Rails Cultural Recipe: It will have charismatic and visible adherents. It will be open, so its community of advocates can expand and evolve. It will get disruptively effective results, from people of varying technical competence, with a minimum of input effort and a short learning curve. It will be good at solving problems that are important to small venture-backed startups that get a lot of press.

    Hell, the rockstars may rediscover Perl.

    I’m most encouraged, though, by the recent movement to a “craftsmanship” culture in software engineering, which hasn’t really yet defined itself fully, but seems to be what the rockstars do when they retire from the stage. And so far, it’s something I can identify with, that both describes me and most of the folks I respect the most. Singer/songwriter culture, anybody?

    1. Great insights Rob. The “monk/guru culture” precisely explains why Smalltalk and LISP never went anywhere. “the HTML formerly known as 5” 🙂 I see a lot of movement towards JavaScript everywhere. I hope those Harmony guys can fix up the language soon.

      1. Disagree. I like Bob Martin’s talk, recapitulating Ward Cunningham’s simple take on why Smalltalk failed: “It was too easy to make a mess.” Bob took that simple explanation and expanded it to an hour+ long talk.

        1. Hey, what if it was also easy to clean up the mess? That would be a helluva language right there!

          That would also be a great feature for filesystems. OLPC had an interesting take on that — they called their filesystem “The Journal”. It was a filesystem that was a bit like human memory — anything you didn’t touch in a long time would just fade away.

  6. Why I program in Ruby for my personal projects: Ruby doesn’t get in my way.
    I can come up with a complicated class hierarchy if I want. Then, if halfway through coding I realize there’s a problem with it, I can ignore that hierarchy until I’m ready to do some refactoring. Mixins and the “overload anything, I don’t care…” nature of Ruby really make it easier to think about things, for me.
    Yes, I wait in anticipation for better namespacing of overloaded/mixed-in methods, but “works for me, usually” for now.

    Meanwhile, I think the slowness of Ruby is a great advantage: Once “don’t worry about speed too much” is a necessity for using a language, then writing things in a way which makes sense can easily trump writing things in a way which performs well, until it’s time to think about performance.

    IANARP, I just use it at home.
    I like the /idea/ of Rails (or parts of Rails, at least), but I am far too much of a perfectionist to use it in practice – unless there’s a clear separation between “my code”, “generated code”, and “library code”, I don’t know where to stick what in my version control software. If it doesn’t make sense in my VCS, then I can’t make sense of it.

  7. Hello.

    I’ve written quite detailed post a while back, but then taken it down becouse I thought It was to offensive. I’ll try to sum up the points I’ve made. Just FYI I’m working with ruby and rails for over 4 years now.

    First of all you have to distinguish Rails and Ruby, both have it’s own merits, and both added to equation, but I’ll focus mainly on Rails, mentioning why Ruby helped. Truth is Rails could have happened with any language except for Java, C/C++ and PHP – I’ll try to explain why later.

    1. First and biggest: It was a solution to a problem.
    Beside two previous points, biggest advantage of Rails was that it was amazingly useful. Mostly because it was extracted from WORKING application. It was not another “let’s build awesome framework that will make everyone happy” or “let’s anticipate every possible use and write tons of XMLs to configure it”. Instead it was used by real artists (using famous Steve Job’s definition), and solved real problems that every web developer faced constantly.
    2) Lowest barrier of entry I’ve ever seen in programming.
    Several things added up to it.:
    a) Even though documentation on ruby itself was lacking, language is so expressive and “obvious” (for lack of better word) that It didn’t matter, Ruby is one of first mainstream languages that came close to being self documenting.
    b) Documentation on Rails was of great quality, and very extensive. Even early versions like 0.13 – 4 years ago had tens or houndrets of examples, and one example is often worth several paragraphs of documentations.
    c) Tutorials – Few very high quality tutorials were available, that showed how to start with both Rails AND Ruby at the same time. This was very important and quite unique. When I’ve tried to use Seaside and several other web frameworks in niche languages like OCaml, almopst all tutorials for these frameworks assume you already are expert in given language, you know how to install it, you have environment set up etc. So basically you have to follow two tutorials, or learn “raw” language to perfection without any practical example, then apply it to web programming.
    d) Screencasts – Already mentioned earlier great stuff end only enforced effect of tutorials.
    3) Green field.
    Ruby was pretty niche language before Rails. So when the Rails came, it was great place to build good community from scratch. Rails and Ruby attracted best and brightest, early adopters, hackers, gurus, people looking for new great thing to experiment with. Connect that with big growth of Open Source movement, and Linux adoption (I disagree it was Mac’s who pushed Ruby/Rails, It was Linux – becouse it served as a natural deployment platform for low budget hosting, and developers that first took interest in Rails worked on Linux anyway). All of this sparked awesome community, full of great and helpfull people (famous ruby-lang mailing list credo “Be nice because Matz is nice”). IMO the green field led to great community, which of course caused Ruby to spread like wildfire.
    This is also a reason why this kind of success is not repeatable in PHP/C/C++/Java, there’s no green field, instead there’s tons of monkey coders, “give me teh codez”, self proclaimed guru’s, and “enterprise” solutions.
    The same unfortunately applies to LISP/Scheme/Smalltalk. Again no green field to build on – this time because of hermetic environment, and elitarism.
    Amazingly Ruby / rails comminity right now degenerated almost to the point of PHP community. Show me teh codez is major theme on ruby-lang lately. And innovation moved to other places – like node.js and coffescript.

      1. I’d suggest first to try to solve a problem. There’s huge gap between declarative languages like SQL and imperative like Ruby. Since more and more focus is on data analytics and handling of data that changes in time, it can be a good fit. Also coherence seemed like a great thing to build project management stuff like Redmine or Jira.

        I’d suggest taking a look at how coffescript evolved. They bootstraped it with Ruby and Treetop, then they matured language in one branch, and experimented with language in another, with goal to make javascript as pleasurable as possible.

        About pitching – I’d post some working code on github as soon as possible. Then start series of blog posts which show how you can apply Coherence in common problems that are hard to solve by imperative and/or declarative languages.

        On the upside, you already have a green field and good seed for Your new community 🙂

          1. True, I just learned ruby first, and that’s what I’m working with. They have nice web framework – lift.
            They also got great deal of hype at one point in time(especially when twitter switched to scala), but they failed to attract large enough community. I must say I was suprised by that, I suspected it’ll be “the next big thing”.

            Thoughts after short evaluation:

            I’ve loved the ability to create full dsls using built in parser generators, powerful stuff. Also dynamic typing with strict checking is simply amazing, I’d love to see something like this in Ruby.

            For me biggest problem was they focused to much on Java.
            Almost all tutorials assume You’re coming from Java. Most of them show interaction with java before many other language features. In contrast Ruby had several tutorials “Ruby from X” on it’s site since I can remember.
            There’s no such thing like rubygems, dependency manager instead of simply working, is documented like it’s phd thesis by someone who tries very hard to write in language that is as complicated and formal as possible. Half of the tutorials assume You’re fluent with Ant or Maven.
            In ruby you have a ‘clone’ of most standard unix tools – rake for make, rubygems/gem for yum/rpm or apt/deb and several others. At the beginning I thought this as a clear NIH syndrome, but after a while it proven to be a great thing for Ruby. You have to learn another tool, but for most part, they simply work, and allow you to use your new language for all parts of application.

          2. Regarding Scala: Yes, there will always be a powerful new start-of-the-art way to shoot yourself in the foot.

            I think F# and Active Patterns w/ Silverlight will give you the most flexibility going forward, and F# has features comparable to Scala, like active patterns vs. extractors. .NET Community is starting to mature. The presence of F# toolkit freely available no doubt helps a lot.

        2. F# is attractive, but I swore an oath that I would never again program without a rename refactoring. Visual Studio support is minimal, and locked into an archaic release nothing for two years cycle.

          3. Cool, thanks for the links Z-Bo. I loved Resharper on C#. But times have changed. Much if not most of the audience for my work is on Mac and Linux. Silverlight just isn’t sticking. Right now, its gotta be JVM for the engine and JavaScript for the UI.

          4. Cool. I didn’t know you were going to do a client/server scheme like CodeBubbles. In that case, maybe I’ll write a front-end in “the new hotness” Silverlight to replace whatever in “the slow/ugly” JavaScript.

  8. I’m sorry for double post, but I have forgotten to mention that all points made by Rob Heittman, and with points 1, 2, 4 from epitron’s post.
    as for point 3, as I’ve mentioned earlier, I’d substitute Mac for Linux.
    as for point 5, PickAxe is one of sh@#$@ books on programming I’ve had displeasure of reading, I almost abandoned learning ruby becouse of this book. To this day I have no idea how can you turn such beautiful language like Ruby into fragmented and lacking any kind of integrity code that served as examples in this book. So if Ruby gained popularity, IMO it’s in spite of books that were available early.

  9. BTW, I also don’t think Rails would’ve survived the early days without Zed Shaw. His Mongrel Web Server was a huge boost over comeptitors, and it took a long time for the FLOSS community to develop a competitor to Mongrel. As Zed documents in Rails Is a Ghetto blog post, DHH goes on the record saying his Rails apps would crash every 5 minutes due to slow response-time (before he switched to Zed’s Mongrel server).

    2. Definitely. Mongrel is great.

      Also, don’t forget to give some of Zed’s props to Adrian Thurston for making Ragel — the engine beneath Mongrel’s HTTP state-machine and a bunch of other great tools.

  10. We need a timeline. I would like to know when O’Reilly Inc. started to talk about it (in blogs, at conferences, and in book catalogs). I’m not sure they still are but, for several years there, my subjective impression (possibly wrong) was that they were king-makers. They very much were in a place to and did take stuff out of obscurity and into huge success — for fairly random reasons.

      1. BTW, as Chromatic mentions in the link above, if you have access to Nielsen BookScan, then you can actually track book sales, including breakdown by publisher (O’Reilly and its subsidiaries/affiliates).

      2. “OReilly’s been very public about how new technologies sell the most books.”

        That’s their story and they’re sticking to it. However, O’Reilly (the man, not the company) has been pretty clear that he and they identify what they dub “alpha geeks” (who come to O’Reilly to sell something), take their spiel, and start reporting on the hot new trend at conferences, on-line, and in the book catalog.

        In other words, O’Reilly has a history of doing what I would describe as setting out to create artificial trends – and succeeding.

        The “alpha hacker” lines of communication aren’t entirely a matter of glad handing. The stories they tell will be something like “We used X for project Y successfully,” and someone else says “we used X for project Z successfully” and then the hype machine starts. The problem is that there isn’t a heck of a lot of critical attention paid to the actual role of X in the successes of Y and Z (did X uniquely enable X and Y? did it help at all? did it actually hinder in unacknowledged ways? what sober lessons can be learned about the value of X in general? etc.).

        Once a lot of people believe that, say, RoR is perhaps the next big thing, everyone with money or spending power seems to want a piece of it. I was in a surprising (to me) number of conversations back when RoR was just coming across on the O’Reilly radar where potential project backers wanted to know if I would be using that. The perceived value of start-ups, at the time, was higher if they were on the RoR bandwagon – for no reason other than hype. And none of that investment bias actually bore out in results as nearly as anyone can tell — probably quite the opposite.

        Meanwhile, yeah, thousands of newbies take a quick scan of the job listings and the trade press while the hype bubble is being inflated, infer it must be important to have RoR on their resume, and sure, by books.

        And who would care or begrudge the bookseller a damn thing there were it not for the fact that as a casual side effect, millions are invested and lots of substandard infrastructure built out before the hype bubble deflates.

  11. There are lots of good responses here, particularly epitron’s and Rob’s.

    I also watched Rails in its early days, having considered building a Ruby web framework a couple of years prior, when the Ruby community was almost solely Japanese and difficult for an English-speaker to penetrate.

    Ruby’s success (at least outside of Japan) is completely hitched to Rails. Had Rails never emerged, Ruby would still be sitting on the sidelines. Plenty of developers learned the Rails flavor of Ruby first, then later realized that Ruby itself is actually an interesting and enjoyable language to work with, albeit not a perfect one.

    In my opinion, Rails grew in visibility because it was positioned both oppositionally and aspirationally. Rails provided a via media between the seemingly structureless and haphazard world of PHP web development and the overly constricting and bureaucratic world of Java web development. As others have pointed out, Rails was marketed just as the Mac was (once again) coming into its own as the premier software development platform. The end result was that Rails was quickly viewed as a technology you learned to escape the doldrums of the buttoned-down enterprise software world. Ditch the suit and the Dell, buy a Mac, learn Rails, work at a cool startup or as a freewheeling coffee shop contractor. Though it’s a bit eye-rolling now, I have to say, it worked for me.

    Rails also quickly created a marketplace for jobs, consulting services, hosting platforms, and developer tools. That economy kept the momentum going, and continues to keep the Ruby community more attractive to investment and entrepreneurship than, say, Python.

    Finally, I think Rails arrived at a generational shift in the industry. The Rails community tends to skew towards people in their 20s, many of whom came out of computer science programs that had revised their curricula to focus on OOP languages (I believe the dismissive term is “Java schools”). Rails provided the opportunity to work with a less stodgy technology using metaphors that are readily understood by someone coming from this educational background.

    So, put all of that together: you’ve got a well-marketed new technology with a fresh workforce of highly communicative and promotional digital natives and a growing economy around it. It’s no wonder that it was a success.

    1. Excellent analysis Alex. Combined with the other comments, this could become an authoritative thread on the success of Rails. “Oppositional and aspirational” is a great description. But all of this means that Rails was at the right place at a once-in-a-generation time. Not very reproducible.

      If you don’t mind me asking, what does your crystal ball tell you about Scala? I know you have made a major commitment to it, so you must believe in it strongly. I am a little worried. It is state of the art in many respects, and I am planning to build my new language with it. But I am not sure I see a clear path to Scala going mainstream. It kind of strikes me as a “Java++” – powerful integration of new ideas into the incumbent language, but with a big cost in complexity. I mean, not even IDE’s seem able to understand its type system. And looming in the background are Oracle thugs toting machine guns. Not a cool place for kids to aspire to anymore.

      I think Scala is vulnerable to a new lightweight language ala Groovy providing some of the key benefits without all the extra baggage. Compiled to JavaScript, the new assembly language of the net. Just give me case classes and pattern matching and functional collections and I’d be pretty happy. ScalaScript anyone? Maybe I should start a new thread on this.

      1. Funny you mentioned “assembly language of the net” …

        A while back I started a port of GWT to Scala using some ideas from Lex Spoon — I wanted to write the Scala language and compile it down to JavaScript — and not just for the browser, but to get off the JVM generally speaking. The JVM’s new owner doesn’t thrill me, and I’m doing a *lot* now with server side JS.

        Economics badly limited my free time, but a superhero student, Grzegorz Kossakowski, stepped up to keep the project moving, interned with Lex, and made a lot of headway. See: http://scalagwt.github.com Grzegorz just got to “Hello World” and could use some (a lot of) help.

      2. IDE’s could understand its type system, but Scala completely breaks all existing heuristics that traditional languages have and contemporary IDE’s take advantage of.

        That being said, most academics refuse to acknowledge this is a major problem. The only academic I talked to who was willing to let the cat out of the bag was Sean McDirmid. At SPLASH 2010, Lennart Kats basically dissed how Scala was designed at the end of his talk, say that if it was developed from the ground-up using a Stratego-XT style system then it would have better support for the user. Personally, I thought that claim was bullshit and got up to speak my mind after his talk.

        The problem is neither side has extended the olive branch to systematically study how we can merge meta-environments and plain old language design to learn what we can do well. Lennart’s claims suggest that the way Scala was layered and pipelined could’ve been done differently if defined in a meta-environment. I have a tough time believing this, but am out of my depths in accurately criticizing him. But I get the sneaking suspicion he is also out of his depths in making such unsubstantiated claims.

  13. I was with Rails since the early days (pre 1.0).

    If you want to understand the success of Rails, and even of Apple, you need to look at the idea that for something to be a raging success, it doesn’t need to be hugely better, it only needs to be “just better” in a compelling way – than the competition. I don’t know if you’ve ever tried to build a PHP-based database-driven web application, but it’s a severe pain. Rails is a joy in comparison. Things work the way you’d expect them to.

    Apple and DHH both did this thing where they removed the difficult bits. Rails did it through being a framework (ie you don’t have to roll it yourself) and in that framework, convention over configuration (ie some standard nice defaults – the “right” way to do it, best of breed) so that things are easy for the users (here the users are evidently the programmers).

    Apple does this with iOS, too. They look after their developers. Objective-C and Cocoa are both truly beautiful in terms of the deep understanding of abstraction and modern pragmatic requirements, and I’d be surprised if you haven’t looked into them already, talking about Model-View-Binding based frameworks and languages as you do.

    Apple also do this with their commercial products. An iOS tablet “just works” the way you’d expect a computer to work if you’ve never used a computer before. This is a HUGE thing to “get” if you’re not a computer pundit and most experts really are too deep in the trees to see the forest.

    Compared to building a web app in ANY other framework (and I’ve used a good deal of them), Rails is a true dream.

    You’ll also notice, that Rails has a severe amount of “cool” attached to it. So does Apple and their products. This is DHH and Apple’s STYLE factor. This is also Ruby and Objective-C’s STYLE factor. Ruby is designed for two purposes: to make code LOOK beautiful in the Japanese-aesthetic sense and the things that flows from that is to make the programmer happy. It is born of love. Believe it or not, Apple’s products are, too. They’re born of a deep understanding of style and design and love for the materials involved. Something in people resonates to this.

    This is why both of these things engender such delight in their users. They are powerful things that stem from a deep understanding of the human condition and transcend their technical and mechanical nature and make it human. The idea that essentially, we are made of love.

    I have a huge respect for where you’ve got to in your system and I’d love to discuss some of the ideas I’ve had for similar systems (I’m in the process of building a sort of similar system myself).

  14. I picked up ruby in 2003 around 1.6. I admin friend told me about it. I used to code in php and java and perl and moved wholesale to ruby. I still maintained the old code, mostly by using ruby to generate perl and php.

    When rails came out I was deep in ruby – albet without much of a community. I folded the ideas i found in the rails source code into my own ruby.

    The early rails people had an irc channel. It was friendly and fun and interesting. The framework was fast to work with, practical and focused.

Comments are closed.