Slashdot Mirror

I, btw, question your claim that ruby can maintain "several million hits per day" (or did you mean cache hits?) on "modest" hardware.

According to Wikipedia, Penny Arcade handles 2 million page requests daily with Ruby on Rails. On the forums there, it's been mentioned that Penny Arcade runs off a cluster of 5 machines.

If Penny Arcade's content is too static for your tastes, then the Robot Co-op family of sites, which consists largely of AJAX web applications such as 43places, manages 2.5 million daily page requests with 6 machines.

I consider half a dozen machines to be a fairly modest hardware requirement for handling such large volumes of traffic. You may disagree.

Sorry but it's a bit naive to assume that hardware can simply be replaced every two years.

You misunderstand me. What I'm saying is that, in general, the average increase of CPU requirements for server applications is likely less than a 100% increase every two years. Given this initial premise, the logical conclusion is that, in overall, the number of server applications that use Java will tend toward an increase, and correspondingly, the number of C++ server applications will decrease.

Obviously most server-side systems last for longer than two years, but what matters is the rate of increase. For instance, if the average lifespan of a C++ server system is ten years, then unless resource requirements have increase a thousandfold in that time, then it makes more sense for the replacement to be programmed in Java (or Python, or Ruby), than in C++.

I have first hand expirience that sloppy programming does indeed almost always imply the other two.

Most of the time, I'll agree with that. My point was more that inefficient programs (in terms of computer resources being used) does not imply sloppy coding, nor an unscalable system. A program need only perform up to spec with the resources it has; efficiency gains beyond that point will be increasingly less useful and more costly.

Best language and framework I've ever worked with. And... it can scale too ! http://blog.segment7.net/articles/2006/03/06/2-5-m illion

Interestingly, there is a ruby framework based on seaside. It's called Borges, and can be found here.

Seaside, a "web application framework" written in Smalltalk uses continuations for things like backtracking. The resulting code is said by some to be cleaner and easier to understand than more conventional approaches. The author's blog has some discussion on the matter. There's also a port of Seaside to Ruby called Borges.

But yea, in general, it's hard to see what good call/cc is. It tends to be one of those features that people bring up in "language x vs y" flamewars, but never actually use in practice.

Can you give an example of your first point? I've looked in the past, and only ever really found Seaside and Borges (a Ruby implementation of Seaside) as real-world examples of the use of callcc.

(I understand CPS as an optimization technique, but that doesn't require or typically use first-class continuations like callcc, so it's something of a different issue, I think.)

I've created a Links Panel for Mozilla (works with nightlies, Moz0.6 and NS6) and I've wrapped up the History Panel RFE from bug 32594

Other packages/projects can be retrieved from mozdev.org and a very cool forum reader called Forumzilla

Enjoy!

I've created a Links Panel for Mozilla (works with nightlies, Moz0.6 and NS6) and I've wrapped up the History Panel RFE from bug 32594

Other packages/projects can be retrieved from mozdev.org and a very cool forum reader called Forumzilla

Enjoy!

http://segment7.net/mozilla/links/l ink s.html It displays all of the links from a document in the sidebar, and can be insanely useful. Go check it out!

--
Eric is chisled like a Greek Godess

Opera (win32) doesn't support complete styling of the H1 element (as of one month ago), the size stays the same: segment7 - main page but it does do a hell of a lot better than MSIE* or NS4 at style sheet rendering.

I built from source on FreeBSD-current (even less bug reports/fixing there) and my only problem (with building) was that gcc2.95 outputted some poorly formed assembly that forced me to turn off optimizations for one source file.

I'm writing a heavily CSS'd and HTML4.0 strict web site that mozilla has yet to crash on when rendering. I've been writing a script for it using the DOM that adds and deletes elements including forms and input buttons that are attached to DOM to add more elements. I've probably seen one crash from a bonehead programming mistake and that's it.

If you want to check it out, http://segment7.net/php3/newpage.html but there is a bug that has been preventing me from extracting values from input elements, so not all of the input elements work.