Joel Spolsky on languages for web programming

Discussion in 'Ruby' started by Dido Sevilla, Sep 1, 2006.

  1. Dido Sevilla

    Dido Sevilla Guest

    Actually, despite the fact that I love Ruby a lot, I'm inclined to
    partially agree with him on this. Presently, our company does have
    some Rails-based web applications deployed but they're predominantly
    applications geared for use by only a few people (internal client use
    only); we've not yet tried to deploy a real public-facing web
    application based on Rails. For that, it works really well. We're
    taking a wait and see attitude before we attempt to use Rails for any
    high load applications; my own experiences attempting to optimize
    plain Ruby code for performance have been simultaneously frustrating
    and rewarding. I doubt I could do the same with a Rails app. So for
    now we're gonna stick with PHP for our public facing web applications,
    even if it is even worse for i18n/l10n/m17n applications than Ruby
    Dido Sevilla, Sep 1, 2006
    1. Advertisements

  2. Hi,

    In message "Re: Joel Spolsky on languages for web programming"


    I am very proud he mentioned Ruby in one of his essays. Actually, I
    agree with his conclusion:
    He is a businessman, not a geek, so he does not have to risk himself
    using Ruby (and Rails). It doesn't matter. He will not pay me
    anything even if he choose Ruby.

    But we disagree in the middle.
    (1) Although we took different path to handle m17n issue from other
    Unicode centric languages, we don't have any "stunning antipathy".
    (2) Although Ruby runs slower than other languages in those
    micro-benchmarks, real bottleneck in the most application lies in
    either network connection or databases. So we don't have to buy 5
    times as many boxes.

    Yukihiro Matsumoto, Sep 1, 2006
    1. Advertisements

  3. He is a good writer, and I really like how he cuts through the
    rhetoric and is firmly grounded on practical programming matters.

    His core point on technology choice is valid:
    "How do you decide between C#, Java, PHP, and Python? The only real
    difference is which one you know better. If you have a serious Java
    guru on your team who has build several large systems successfully
    with Java, you're going to be a hell of a lot more successful with
    Java than with C#, not because Java is a better language (it's not,
    but the differences are too minor to matter) but because he knows it
    better. Etc."

    His point is valid too if you have a big Rails guru on your team, someone who
    has built large successful Rails systems, then you pick a Rails solution.

    The performance/scalability of Rails as an enterprise web-fronted system is
    continually questioned. People point to Basecamp etc. as examples that Rails can
    do it.

    But thats missing the point - those systems are successful becuase those
    companies have very good, experienced Rails engineers. Rails n00bs would
    probably make a lot of mistakes that clash with the framework and
    compromise its scalability.

    He also has a point about his wait-and-see attitude wrt Rails. Rails development
    is moving quickly, and in a year's time the major issues like unicode support,
    deployment, support ecosystem (tools, etc.) and performance could be
    solved problems.
    Richard Conroy, Sep 1, 2006
  4. In the context of the enterprise, I agree too. But only in the sense
    that 'safe' implies availability of skills, and perhaps tools to some
    extent. IMO, Ruby and Rails are 'safe' in the sense that they have
    longevity, which I think would be the next biggest concern of
    enterprise users.
    Derek Chesterfield, Sep 1, 2006
  5. In the context of the enterprise, I agree too. But only in the sense
    There is another take on what's risky and what's safe:

    Rimantas Liubertas, Sep 1, 2006
  6. Dido Sevilla

    Rob Sanheim Guest

    I find it amusing that he says Rails is too risky and new, yadda
    yadda, but then he goes on to talk about their in-house language,

    "Wasabi, a very advanced, functional-programming dialect of Basic with
    closures and lambdas and Rails-like active records that can be
    compiled down to VBScript, JavaScript, PHP4 or PHP5."

    So Rails is too risky, but inventing your own language isn't? Did
    someone say "not invented here" ??

    Also, I could see how looking at unicode in Rails could scare large
    enterprise apps, but the scaling and slowness thing is just FUD.

    - Rob
    Rob Sanheim, Sep 1, 2006
  7. I too found that beyond ironic.

    James Edward Gray II
    James Edward Gray II, Sep 1, 2006
  8. Hi,

    In message "Re: Joel Spolsky on languages for web programming"

    |On Sep 1, 2006, at 9:20 AM, Rob Sanheim wrote:
    |> I find it amusing that he says Rails is too risky and new, yadda
    |> yadda, but then he goes on to talk about their in-house language,
    |> "Wasabi":
    |I too found that beyond ironic.

    That indicates that he trusts himself, and not me (Ruby). And I think
    he's right.

    Yukihiro Matsumoto, Sep 1, 2006
  9. Dido Sevilla

    khaines Guest

    and rewarding. I doubt I could do the same with a Rails app. So for
    An interesting performance test is to take some task and implement it in
    Rails or Nitro or IOWA or Camping or whatever, and then implement it in a
    PHP framework with equivalent functionality.

    I have done some of this using CakePHP, which is a reasonably good PHP web
    development framework, and the results are interesting. While PHP will
    benchmark faster than Ruby for isolated benchmark tasks, when one starts
    looking at frameworks with equivalent capabilities, PHP loses that
    performance advantage, at least in the limited testing that I have done so

    Kirk Haines
    khaines, Sep 1, 2006
  10. Well, to be fair, it's not quite that.

    Start with --
    they had a VBScript app and it needed to be on PHP. So they wrote
    a VBScript to PHP compiler.

    Good choice, given the market pressures.

    Three years later, they've extended that compiler a little in the
    direction of a FogBUGZ specific DSL and given it a silly name.

    Not particularly surprising, nor particularly relevant to language

    William Grosso, Sep 1, 2006
  11. Really? I trust you a lot more than me, at least as far as designing
    languages goes.

    James Edward Gray II

    P.S. I've used Spolsky's software and read his books and it just so
    happens that I trust you more than him too. ;)
    James Edward Gray II, Sep 1, 2006
  12. Dido Sevilla

    Rob Sanheim Guest

    On second though, maybe Joel was just trolling a bit here? Maybe just
    a bit of an in-joke, knowing that the bloggers would go nuts about the
    obvious contradiction?

    It seems to nutty to be true...
    - rob
    Rob Sanheim, Sep 1, 2006
  13. Dido Sevilla

    James Britt Guest

    James Britt, Sep 1, 2006
  14. Dido Sevilla

    Mike Berrow Guest

    It seems to me that Joel has accused us of having too much *fun* with
    Ruby and with Rails. Way too much. And we all know that fun can't
    possibly go hand in hand with productivity and *real* business.

    -- Mike Berrow
    Mike Berrow, Sep 1, 2006
  15. Hi,

    In message "Re: Joel Spolsky on languages for web programming"

    |> That indicates that he trusts himself, and not me (Ruby). And I think
    |> he's right.
    |Really? I trust you a lot more than me, at least as far as designing
    |languages goes.

    To rephrase, he has right to trust himself than me. I think I am a
    better language designer than him. But at the same time, I think he
    is a better programmer to create enterprisy software.

    |P.S. I've used Spolsky's software and read his books and it just so
    |happens that I trust you more than him too. ;)

    I've read his book, but not used his software, so that I may not be
    the right person to judge him.

    Yukihiro Matsumoto, Sep 1, 2006
  16. Yes, *Joel* did. He makes quite a strong case for it:
    "in defense of not-invented-here syndrome"
    The unicode issue is scary to an enterprise mindset, where having
    a valid unicode mechanism that is 'non-unicode centric' still qualifies
    as 'unicode antipathy'. The enterprise mindset has become happy
    with the fact that unicode support is one of those things that they
    don't have to think about in the languages/frameworks they favour.

    The scaling/slowness thing though I can kind of understand (the
    concern that is). I get
    the feeling that Rails performs properly when you stick to the promoted
    model, but if you deviate from it (processing too much, rather than
    using the stack properly) you can choke your performance. Other
    languages are probably more forgiving in this respect.

    Don't forget the original context of Joels post: "Which web technology
    would you bet your company on" (and by implication you house &
    savings and whatever other assets you have used to get capital)
    Richard Conroy, Sep 1, 2006
  17. Paying homage to Doug Englebart rather than Steve Jobs.

    Stephen Kellett, Sep 1, 2006
  18. Dido Sevilla

    Ben Harper Guest

    I suspect the 'fun' thing is a bit of a stab at the frequency of the
    word 'fun', as well as the 'programmer happiness' thing in Ruby and/or
    Rails evangelism. I myself don't like such terms too much when used to
    describe what I do.
    I love my work, and some of it now involves ruby, but 'fun', in written
    english, has connotations that perhaps do not suit the way myself and
    like-minded people describe how we feel about our work. I would use it
    in conversation, but I would not use it in a banner advertising my
    working environment.
    Ben Harper, Sep 1, 2006
  19. Allow me to rant on what we performance engineers do for a living ... :)

    Most web applications I've encountered are not engineered for
    performance -- *ever*. There's this little slogan they teach
    programmers, which I've heard repeated numerous times on this list:

    Beware premature optimization.

    As a performance engineer, I don't consider premature optimization a
    sin, of course. But leaving that aside, what it translates to is "make
    it work, then make it pretty, then deploy it." Once it's deployed, it's
    faster to "throw hardware at it" than it is to do the performance
    optimization aka performance *re-engineering*.

    Incidentally, the person who coined that slogan, Edsger W. Dijkstra,
    said also that programming should separate the concerns of correctness
    and efficiency. He *never* said to *only* worry about correctness. Part
    of the discipline of programming is to pay attention to the efficiency
    in equal measure to the correctness. That somehow seems to have been lost.

    OK ... on with the rant: :)

    1. Those of you who claim to be doing "test-driven development": If
    performance testing isn't part of your test-driven development, you
    aren't *really* doing test-driven development.

    2. Micro-benchmarks are important. A few weeks ago, I ran and profiled a
    micro-benchmark on "Matrix", which I posted to the YARV mailing list and
    on my RubyForge project page. It's four times as fast in YARV as it is
    in Ruby 1.8.5.

    Whether it's YARV or some other low-level implementation techniques
    really isn't important. What *is* important is that the Ruby "inner
    interpreter", to borrow a term from Forth, *must* be as fast as it can
    be given the other design constraints like compilers and portability.
    The way to achieve this is with profiling on micro-benchmarks.

    3. The future of "throw hardware at it" is multi-core processors and
    storage array networks (SANs). If you aren't designing your applications
    to take advantage of multi-processors, or if you aren't paying attention
    to the "lower-level" I/O characteristics of your applications, they're
    going to throw hardware at someone else's code.

    Speaking of throwing hardware at it, there are ways to know what *kind*
    of hardware to throw at it. Learn them. :)

    4. An application with a network bottleneck is very often poorly
    designed. One of the goals of performance engineering is *minimizing*
    the amount of traffic between the client and the server.

    Of course, if you're streaming audio, displaying high-definition video,
    etc., the network traffic *is* the application, but an on-line banking
    application should *not* have to send back more than a couple of
    kilobytes to confirm that I've made a payment.

    5. Database "bottlenecks": Most of the "industrial strength" databases
    -- Oracle, PostgreSQL, MySQL, SQL Server 2005, DB2, etc. -- are
    co-optimized with the operating systems and the platform hardware.
    They've done their homework; they've done their performance engineering,
    profiling and micro-benchmarking.

    As good as they are, a poorly engineered database schema can make the
    RDBMS work much harder than it needs to, requiring more hardware than is
    M. Edward (Ed) Borasky, Sep 1, 2006
  20. Yes ... I do what I do for a living (mostly in Perl and R, not yet Ruby
    or Rails) for two reasons: I enjoy doing it and I get paid well for it.
    Take away either of those and I'd go job hunting.
    M. Edward (Ed) Borasky, Sep 1, 2006
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.