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 is...
I am very proud he mentioned Ruby in one of his essays. Actually, I agree with his conclusion:
>that's not a safe choice for at least another year or six. that's not >a safe choice for at least another year or six.
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) it displays a stunning antipathy towards Unicode and > (2) it's known to be slow, so if you become The Next MySpace, you'll > be buying 5 times as many boxes as the .NET guy down the hall.
(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.
> Actually, despite the fact that I love Ruby a lot, I'm inclined to > partially agree with him on this.
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.
On 1 Sep 2006, at 14:00, Yukihiro Matsumoto wrote:
> Actually, I agree with his conclusion:
>> that's not a safe choice for at least another year or six. that's not >> a safe choice for at least another year or six.
> 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.
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.
> 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.
> 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 > is...
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":
"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.
In message "Re: Joel Spolsky on languages for web programming" on Fri, 1 Sep 2006 23:28:09 +0900, James Edward Gray II <ja...@grayproductions.net> writes:
|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.
> 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 > is...
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 far.
> In message "Re: Joel Spolsky on languages for web programming" > on Fri, 1 Sep 2006 23:28:09 +0900, James Edward Gray II > <ja...@grayproductions.net> writes:
> |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.
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. ;)
On 9/1/06, James Edward Gray II <ja...@grayproductions.net> wrote:
> 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.
> James Edward Gray II
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 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.
In message "Re: Joel Spolsky on languages for web programming" on Fri, 1 Sep 2006 23:49:44 +0900, James Edward Gray II <ja...@grayproductions.net> writes:
|> 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.
On 9/1/06, Rob Sanheim <rsanh...@gmail.com> 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": > 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.
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)
In message <44F8494F.7080...@gmail.com>, James Britt <james.br...@gmail.com> writes
>Where would be but for Not Invented Here?
Paying homage to Doug Englebart rather than Steve Jobs.
Stephen -- Stephen Kellett Object Media Limited http://www.objmedia.demon.co.uk/software.html Computer Consultancy, Software Development Windows C++, Java, Assembler, Performance Analysis, Troubleshooting
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.
Yukihiro Matsumoto wrote: > Hi, > (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.
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 necessary.
Ben Harper wrote: > 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.
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.
> 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 > necessary.
It is very easy, though, for even simple queries on a simple, optimized DB schema on a well tuned engine to be the single largest bottleneck for a dynamic web site or web based application.
Take, for example, a site that I am working on today.
It is dynamically generated using data from a simple db, but it is ok for there to be a short latency between changes to db data and changes appearing on the site pages.
Querying everything from the db for every request was netting around 35 pages per second -- a little under 3 hundredths of a second per page generation. Changing the code so that it queries no more than twice a minute, operating off of cached data between queries, dropped the page generation to around 5 or 6 thousandths of a second -- about 170ish a second. For comparison, on my development server I get about 620 page loads a second from a static version of the content.
The database presents a significant bottleneck that I can fortunately work around through a little bit of caching. If, for whatever reason, I could not employ this caching, that db bottleneck could be a much more significant issue than any Ruby speed issues.
Kirk Haines
BTW, just for comparison, a version of this content rendered and delivered through CakePHP on PHP4, with no db data caching, renders about 17 pages per second.
> > 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":
> James Edward Gray II wrote: >> 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.
>> James Edward Gray II
> Do you know what ironic means?
ironic |īˈränik| |aɪˌrɑnɪk| |ʌɪˌrɒnɪk| adjective using or characterized by irony : his mouth curved into an ironic smile. • happening in the opposite way to what is expected, and typically causing wry amusement because of this : [with clause ] it was ironic that now that everybody had plenty of money for food, they couldn't obtain it because everything was rationed.
-=-=-=-=-=-
My usages of the term seems OK to me.
Joel bashed Ruby for being unproven, then went on to say that they were using a custom language they invented. By his own definition, that is unproven. That's "happening in the opposite way to what is expected" because of his earlier statements and it also causes me "wry amusement."
Squeamizh wrote: > James Edward Gray II wrote: >> 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.
>> James Edward Gray II
> Do you know what ironic means?
After gem install MerriamWebster, ri irony outputs:
3 a (1) : incongruity between the actual result of a sequence of events and the normal or expected result (2) : an event or result marked by such incongruity b : incongruity between a situation developed in a drama and the accompanying words or actions that is understood by the audience but not by the characters in the play -- called also dramatic irony, tragic irony
In this case, "tragic irony" seems apt.
..Just another Joel
-- vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
|
