The worst part about it is the fact that many of the people driving monoculture are trained scientists who, for some reason, are oblivious to its negative ramifications.
The people driving it (whether or not trained as scientists at some point) are corporate executives for whom the short-term ramifications are positive financial benefits for themselves, and any negative ramifications are more distant and distributed to a large number of other people.
That people discount consequences that both are distant and borne mostly by other people is not at all surprising. If it wasn't for that fact, there would be very little reason to have governments at all.
Correct. The statement upthread that this relates to was that spinning hard disks are heading the way of tubes. You've gotten all caught up in the fact that tubes are still used in a narrow range of specialist applications rather than the wide array of applications for which they have been displaced by solid-state electonics as if that showed that the statement upthread were incorrect or at least not significant. It doesn't: in fact, its perfectly consistent with the message it was making, that spinning hard disks are likely to be displaced from general use by SSDs.
No, they aren't. Ignoring the subjective part, Ruby is a language, Rails is a web application framework written in Ruby, not a language.
but they really need to start focusing on their documentation.
Well, probably. This seems a pervasive problem, IME, with F/OSS languages and frameworks (but not F/OSS database servers -- SQLite, MySQL, and PostgreSQL all have pretty good documentation.) That said, Ruby and Rails don't seem particularly worse than the norm here (with the exception of the Ruby core (vs. standard library) documentation at ruby-doc.org, which is rather messed up.)
Rails is much worse. If any documentation exists as all, it's usually behind the web site peepcode for $9 a tutorial. These tutorials are not documentation but serve as a How To for Dummies, leaving you without sufficient knowledge on the scalability, security, or in many cases, any real clue of how to use the code provided.
The main documentation for Rails is the rdoc, which is part of the distribution and also available over the web for free.
Aside from that, the best source is probably the book Agile Web Development with Rails, the most recent version of which is currently available as a Beta pdf.
The documentation on something as core as DBI returns, "Nothing known about DBI".
What documentation on DBI "returns" that? (DBI is not part of Ruby's core, or its standard library, or Rails [though rails can use it], so I'm not sure how any problem with DBI's documentation is relevant to criticism of Rails' or Ruby's documentation.)
Why pick Ruby unless they're just trying to look trendy.
Probably to compete with Sun and JRuby (which isn't, per se, a Sun project, but it is a project Sun is participating in directly.) And dynamic languages (including, but not limited to, Ruby) aren't "trendy" for no reason -- they deliver real value. Sure, there's lots of hype around them, but there is something underneath the hype as well. Anything Java has, especially if it is something Sun is backing directly, Microsoft needs to show that.NET can match. Not, of course, that IronRuby is anywhere close to matching JRuby in any meaningful way.
I confess I don't know a lot about Ruby on Rails, but I've looked into it once or twice. I thought Rails was a Server-Side technology for creating dynamic websites? I thought SilverLight is a Flash-clone, for implementing client side interfaces and rich media playback? Is Microsoft talking about a SilverLight-based user-interface which connects to a Rails backend running on the server?
Yes, specifically, they are referring to a Silverlight-based UI which is presented by and connects back to a Rails backend running on Microsoft's IronRuby on the.NET platform on the server.
Well, it means they aren't mutually exclusive and/or they aren't exhaustive. Often, the latter is more important to the characterization of "false dichotomy" than the former, as in your example:
eg. "Did you vote for George Bush or are you a Terrorist?"
This is, as you note, not mutually exclusive (you can be a terrorist and vote for George Bush), but the real complaint about this kind of thing is more often that the presented dichotomy is not exhaustive: you can be a person who didn't vote for Bush and still not be a terrorist.
Mod parent up. Geez, how do/.ers not know how web caching works?
Ironically the GP, which has been modded up as you requested, seems to not know how web caching works. Merely saying "read the spec" isn't the same as actually understanding the spec. As, clearly, GP does not.
Um, RTFA. That's exactly what the article is saying when its says that they will make Java die "of old age" many, many years from now.
For one thing, they are SLOW which automatically disqualifies them in a lot of areas (like high-performance computing).
I'm not sure that's really all that relevant to their ability to compete with Java, which isn't exactly the language of choice for high-performance computing.
Also, Python interpreter is STILL single-threaded.
The production-ready (Ruby 1.8) main Ruby interpreter is single-(native)-threaded, and uses green threads for concurrency. The Python interpreter uses multiple native threads, but uses a "global interpreter lock" that allows only one of the threads it controls to run at a time (this is the same approach used by the Ruby 1.9 interpreter; JRuby, IIRC, uses Java threads [which in turn are usually -- always? -- native threads] without a GIL; and the Rubinius VM looks to use green threads at least initially, but is being designed with a multi-VM IPC mechanism that will provide an means of leverage multicore systems.)
I don't know about anyone else, but 1280x800 on a screen that small is going to be practically unreadable for my eyes, and I'm not exactly old.
If increasing resolution on the monitor makes things less readable, you've got an operating system (or, at least, window manager/display subsystem/etc.) that really sucks (worse than Windows), or you aren't using it properly.
It's worse in law. I just graduated from a law school whose name any joe on the street anywhere in the world would recognize. Most of the students there don't even know how to create a PDF.
Expecting these law students to sum a column in Excel would be like expecting typical/. posters to build a Core 2 Duo from stuff lying around their garage.
I've never understood how people who are generally very intelligent can fail to grasp the most basic computer concepts so completely.
Ever seen how many Slashdotters fail to grasp law? It works both ways.
You shouldnt have to unit test for syntactical errors though, thats just crazy.
The errors involved are not syntactic errors in Ruby, even if somewhat analogous errors in a different language might be.
You do unit tests to prove behavior, not correct syntax.
How an object responds to a message in an object-oriented language (following the model set by Smalltalk, not the C++/Java kind of "OO") is a matter of behavior, not syntax.
But that means that you've just lost all of that 'provable correctness' that you would otherwise have, and have to replace alot of what you got for free with a compiler, with hand-written unit tests.
Its probably no harder (and not easier, easier) to write a proof of correctness for code written in Ruby than any other language (presuming the correctness of the language implementation). But correctness proofs are rarely done, and provable correctness isn't what you lose: what you lose is having the compiler catch type errors and the like, which is nothing like provable correctness. It doesn't even, in most statically typed languages, actually validate that the methods passed will necessarily be always valid for the methods called, though some languages provide support for stronger invariants than C and Java (Ada comes to mind; ISTR that Eiffel is particularly strong in this regard as well) which enable this (or come closer to it), instead of forcing the developer to write code to catch invalid values or combinations of values and deal with them at runtime.
and have to replace alot of what you got for free with a compiler, with hand-written unit tests.
Not really. While you have to have some unit tests to catch the things a compiler would catch, these aren't usually extra as they aren't usually different unit tests than you'd need to test other aspects of behavior. A compiler telling you that a function returns the correct type or that a function call is made with the right type of parameters won't tell you that it returns the right values for any set of parameters; unit tests that verify that the correct values are returned will also (as class is part of a value) also tell you that the right classes are returned.
Now, that being said, statically typed languages and the ability for compilers and tools to automatically identify facts about code written in them are useful, and sometimes Java or C is the right choice. And sometimes Java or C is the wrong choice because they provide too little of that.
With that situation, even the stupidest most minor typos can be non-detectable until runtime.
Stupid, minor typos will usually fail pretty hard with even the most basic unit testing.
That takes me back to the horror of 15 years or so ago when I was working with pre-'option explicit' VB. Where typos could cause completely unpredictable (and rare/intermittent) strange side effects.
That kind of thing is so hard to troubleshoot, just makes me want to tear my hair out.
It's usually not that hard to troubleshoot if you are building decent unit tests, then coding small chunks, then running the unit tests, etc. If you code up a large system without doing that, yeah, you'll probably have all kinds of hard-to-find errors (some of the type a compiler would stop you from making, most not of that kind), but why would you do that?
The result is that its IMPOSSIBLE for the IDE or compiler or static analysis tool to know whether a method exists, or I've passed the right number/type of parameters in.
Well, in Ruby, the method not existing in the class of the object called (even at runtime) doesn't mean it doesn't exist in the object (through its metaclass) and the method not existing for the object doesn't mean the object can't respond properly to the message represented by a method call (that's what method_missing is for), so a tool that could detect the kind of "error" you describe would also prevent you from using much of the power of Ruby.
Frankly, I'd LOVE to have the Ruby syntactical sugar, closures, and expressiveness in a statically typed flavor of it with interfaces.
This is, I think, impossible. Much of the expressiveness of Ruby is a direct result of the fact that it uses manifest typing. Ruby is, strangely, oddly like C with respect to Java though for completely opposite reasons: Ruby and C both let you shoot yourself in the foot in ways that Java protects you against, and derive much power (of completely different kinds) from the freedom they permit.
If the code is so insignificant to the size of the data, then why is Google even taking on this project, and why do they think it's so important. Following your logic, having every user download 130K of javascript code is completely insignificant.
Having every user download 130K of JavaScript code is probably a small startup hit when they hit your site, more than made up for by the improved user experience afterward for most sites with substantial interactivity.
OTOH, its a lot better to have every user download that 130K of JavaScript code once per year, total, rather than the first time they hit any site that uses the library. What it means is that many users that hit your page will get all the benefit of that 130K of JavaScript code, without the initial, first-time, delay. (Plus, it means that users using your library where storage for cache may be more limited than on conventional computers, such as mobile devices, won't have as much chance of dropping the cached version of the library specific to your site before they return, and experiencing the delay again.)
Incorrect. A cached page STILL results in a hit to the server, the only difference is that the response is a "304 Not Modified" rather than "200 OK" with content. Check the HTTP spec sometime.
Incorrect. Attempting to read a cached page may still result in a hit to the server, depending on the configuration of the browser. Most browser have a configurable setting as to when they will check for modified pages, and "on every access" or the equivalent is not, IME, usually the default setting, so, without an active decision by the user to do so, the browser will not hit the server on every request for a cached page, and most browsers are easily configured to never hit the server if a non-stale version of a resource is cached, though the usual default is somewhere in between the extremes.
Check the HTTP spec sometime.
The HTTP spec disagrees with your position, which lays out a position contrary to a major purpose of HTTP caching (RFC 2616, Sec. 13: "The goal of caching in HTTP/1.1 is to eliminate the need to send requests in many cases, and to eliminate the need to send full responses in many other cases." [emphasis added].) Under the requirements for cache correctness (Sec. 13.1.1 of RFC 2616), a correct cache need not send a request to the server if it has a cached version that is "fresh enough" as defined by the most restrictive of the requirements of the client, origin server, or the cache itself (for a client local cache, of course, the first and last of these should be the same), and indeed, under the spec, a cache that has a fresh-enough version available should return it even when it has no connectivity to the origin server.
You seem to think that HTTP caching never reduces the number of requests sent, only the number of full responses returned. This position is not supported by the HTTP 1.1 specification (RFC 2616).
There is, of course, something of a privacy violation here, in that Google will now be able to keep track of which users are entering various non-Google Web pages.
Really? Sure, they can tell which web page using the Google-hosted library a user hits first, if they care, but how are they going to tell which one's they hit later when the request for the library are satisfied by the user's local cache rather than resulting in any network request at all, which is the whole point here?
Compared to all the other crappy media that sites tend to have these days, centralizing distribution of a bunch of Javascript libraries makes almost no sense. I doubt it would even appreciably reduce your bandwidth costs.
Uh, the problem isn't "bandwidth costs". The problem is user experience -- lots of sites use the same JavaScript libraries, but browsers cache based on URL. If a centralized repository for the JavaScript is used, the average load time of every page using the repository is reduced compared to if each site hosted the library locally.
The idea isn't that every request for a library has to go through Google, the idea is that almost all requests for the libraries can hit the user's local cache and not hit the network at all. (Google, I suspect, will get more, though still rough, information about website popularity than information about individual browsing habits from this.)
I'm not sure why that's pretty... because it uses OO stuff?
Its pretty because how it reads reflects what it does (though maybe the Ruby interpretation of the PHP version, below, is even better.) You could also do close analogs to the Perl and PHP versions if you wanted to in Ruby, e.g.:
I hate any language that places significance on whitespace
You later say:
Fact - C is the best language of all time.
So I guess you hate all languages, since in C, the following two programs, varying only in whitespace, are very different:
int main(int argc, char **argv) {
int foo;
foo = 0;// or... foo = argc-1;
exit(argv[foo][0]); }
vs,
int main(int argc, char **argv) {
int foo;
foo = 0;// or...
foo = argc-1;
exit(argv[foo][0]); }
Or, heck, if you don't consider C99 "real" C, ask yourself why C has a line splicing character ("\") to convert multiple physical lines into a single logical line: if whitespace (newline vs. space/tab) wasn't significant in C, you would never need such a tool.
Slashdot Mirror
So? People can send faxes with forged numbers from personal fax machines to which company policies don't apply, even if those policies were effective.
The people driving it (whether or not trained as scientists at some point) are corporate executives for whom the short-term ramifications are positive financial benefits for themselves, and any negative ramifications are more distant and distributed to a large number of other people.
That people discount consequences that both are distant and borne mostly by other people is not at all surprising. If it wasn't for that fact, there would be very little reason to have governments at all.
Correct. The statement upthread that this relates to was that spinning hard disks are heading the way of tubes. You've gotten all caught up in the fact that tubes are still used in a narrow range of specialist applications rather than the wide array of applications for which they have been displaced by solid-state electonics as if that showed that the statement upthread were incorrect or at least not significant. It doesn't: in fact, its perfectly consistent with the message it was making, that spinning hard disks are likely to be displaced from general use by SSDs.
No, they aren't. Ignoring the subjective part, Ruby is a language, Rails is a web application framework written in Ruby, not a language.
Well, probably. This seems a pervasive problem, IME, with F/OSS languages and frameworks (but not F/OSS database servers -- SQLite, MySQL, and PostgreSQL all have pretty good documentation.) That said, Ruby and Rails don't seem particularly worse than the norm here (with the exception of the Ruby core (vs. standard library) documentation at ruby-doc.org, which is rather messed up.)
The main documentation for Rails is the rdoc, which is part of the distribution and also available over the web for free.
Aside from that, the best source is probably the book Agile Web Development with Rails, the most recent version of which is currently available as a Beta pdf.
What documentation on DBI "returns" that? (DBI is not part of Ruby's core, or its standard library, or Rails [though rails can use it], so I'm not sure how any problem with DBI's documentation is relevant to criticism of Rails' or Ruby's documentation.)
Probably to compete with Sun and JRuby (which isn't, per se, a Sun project, but it is a project Sun is participating in directly.) And dynamic languages (including, but not limited to, Ruby) aren't "trendy" for no reason -- they deliver real value. Sure, there's lots of hype around them, but there is something underneath the hype as well. Anything Java has, especially if it is something Sun is backing directly, Microsoft needs to show that
Yes, specifically, they are referring to a Silverlight-based UI which is presented by and connects back to a Rails backend running on Microsoft's IronRuby on the
There is still plenty of RoR interest, plus MagLev is just as relevant to a lot of what people leave RoR for.
And, you know, computers, regardless of whether they are "low-end, cheap, and compact" or high-end supercomputers.
Well, it means they aren't mutually exclusive and/or they aren't exhaustive. Often, the latter is more important to the characterization of "false dichotomy" than the former, as in your example:
This is, as you note, not mutually exclusive (you can be a terrorist and vote for George Bush), but the real complaint about this kind of thing is more often that the presented dichotomy is not exhaustive: you can be a person who didn't vote for Bush and still not be a terrorist.
Ironically the GP, which has been modded up as you requested, seems to not know how web caching works. Merely saying "read the spec" isn't the same as actually understanding the spec. As, clearly, GP does not.
Um, RTFA. That's exactly what the article is saying when its says that they will make Java die "of old age" many, many years from now.
I'm not sure that's really all that relevant to their ability to compete with Java, which isn't exactly the language of choice for high-performance computing.
The production-ready (Ruby 1.8) main Ruby interpreter is single-(native)-threaded, and uses green threads for concurrency. The Python interpreter uses multiple native threads, but uses a "global interpreter lock" that allows only one of the threads it controls to run at a time (this is the same approach used by the Ruby 1.9 interpreter; JRuby, IIRC, uses Java threads [which in turn are usually -- always? -- native threads] without a GIL; and the Rubinius VM looks to use green threads at least initially, but is being designed with a multi-VM IPC mechanism that will provide an means of leverage multicore systems.)
If increasing resolution on the monitor makes things less readable, you've got an operating system (or, at least, window manager/display subsystem/etc.) that really sucks (worse than Windows), or you aren't using it properly.
Ever seen how many Slashdotters fail to grasp law? It works both ways.
The errors involved are not syntactic errors in Ruby, even if somewhat analogous errors in a different language might be.
How an object responds to a message in an object-oriented language (following the model set by Smalltalk, not the C++/Java kind of "OO") is a matter of behavior, not syntax.
Its probably no harder (and not easier, easier) to write a proof of correctness for code written in Ruby than any other language (presuming the correctness of the language implementation). But correctness proofs are rarely done, and provable correctness isn't what you lose: what you lose is having the compiler catch type errors and the like, which is nothing like provable correctness. It doesn't even, in most statically typed languages, actually validate that the methods passed will necessarily be always valid for the methods called, though some languages provide support for stronger invariants than C and Java (Ada comes to mind; ISTR that Eiffel is particularly strong in this regard as well) which enable this (or come closer to it), instead of forcing the developer to write code to catch invalid values or combinations of values and deal with them at runtime.
Not really. While you have to have some unit tests to catch the things a compiler would catch, these aren't usually extra as they aren't usually different unit tests than you'd need to test other aspects of behavior. A compiler telling you that a function returns the correct type or that a function call is made with the right type of parameters won't tell you that it returns the right values for any set of parameters; unit tests that verify that the correct values are returned will also (as class is part of a value) also tell you that the right classes are returned.
Now, that being said, statically typed languages and the ability for compilers and tools to automatically identify facts about code written in them are useful, and sometimes Java or C is the right choice. And sometimes Java or C is the wrong choice because they provide too little of that.
Stupid, minor typos will usually fail pretty hard with even the most basic unit testing.
It's usually not that hard to troubleshoot if you are building decent unit tests, then coding small chunks, then running the unit tests, etc. If you code up a large system without doing that, yeah, you'll probably have all kinds of hard-to-find errors (some of the type a compiler would stop you from making, most not of that kind), but why would you do that?
Well, in Ruby, the method not existing in the class of the object called (even at runtime) doesn't mean it doesn't exist in the object (through its metaclass) and the method not existing for the object doesn't mean the object can't respond properly to the message represented by a method call (that's what method_missing is for), so a tool that could detect the kind of "error" you describe would also prevent you from using much of the power of Ruby.
This is, I think, impossible. Much of the expressiveness of Ruby is a direct result of the fact that it uses manifest typing. Ruby is, strangely, oddly like C with respect to Java though for completely opposite reasons: Ruby and C both let you shoot yourself in the foot in ways that Java protects you against, and derive much power (of completely different kinds) from the freedom they permit.
Having every user download 130K of JavaScript code is probably a small startup hit when they hit your site, more than made up for by the improved user experience afterward for most sites with substantial interactivity.
OTOH, its a lot better to have every user download that 130K of JavaScript code once per year, total, rather than the first time they hit any site that uses the library. What it means is that many users that hit your page will get all the benefit of that 130K of JavaScript code, without the initial, first-time, delay. (Plus, it means that users using your library where storage for cache may be more limited than on conventional computers, such as mobile devices, won't have as much chance of dropping the cached version of the library specific to your site before they return, and experiencing the delay again.)
Incorrect. Attempting to read a cached page may still result in a hit to the server, depending on the configuration of the browser. Most browser have a configurable setting as to when they will check for modified pages, and "on every access" or the equivalent is not, IME, usually the default setting, so, without an active decision by the user to do so, the browser will not hit the server on every request for a cached page, and most browsers are easily configured to never hit the server if a non-stale version of a resource is cached, though the usual default is somewhere in between the extremes.
The HTTP spec disagrees with your position, which lays out a position contrary to a major purpose of HTTP caching (RFC 2616, Sec. 13: "The goal of caching in HTTP/1.1 is to eliminate the need to send requests in many cases, and to eliminate the need to send full responses in many other cases." [emphasis added].) Under the requirements for cache correctness (Sec. 13.1.1 of RFC 2616), a correct cache need not send a request to the server if it has a cached version that is "fresh enough" as defined by the most restrictive of the requirements of the client, origin server, or the cache itself (for a client local cache, of course, the first and last of these should be the same), and indeed, under the spec, a cache that has a fresh-enough version available should return it even when it has no connectivity to the origin server.
You seem to think that HTTP caching never reduces the number of requests sent, only the number of full responses returned. This position is not supported by the HTTP 1.1 specification (RFC 2616).
Really? Sure, they can tell which web page using the Google-hosted library a user hits first, if they care, but how are they going to tell which one's they hit later when the request for the library are satisfied by the user's local cache rather than resulting in any network request at all, which is the whole point here?
Uh, the problem isn't "bandwidth costs". The problem is user experience -- lots of sites use the same JavaScript libraries, but browsers cache based on URL. If a centralized repository for the JavaScript is used, the average load time of every page using the repository is reduced compared to if each site hosted the library locally.
The idea isn't that every request for a library has to go through Google, the idea is that almost all requests for the libraries can hit the user's local cache and not hit the network at all. (Google, I suspect, will get more, though still rough, information about website popularity than information about individual browsing habits from this.)
Its going to be hard to blame that on a rogue employee.
A deliberate decision to acquire the instrumentality of a crime is frequently fairly convincing evidence of intent.
Its pretty because how it reads reflects what it does (though maybe the Ruby interpretation of the PHP version, below, is even better.) You could also do close analogs to the Perl and PHP versions if you wanted to in Ruby, e.g.:
Perl: to Ruby: PHP: to Ruby:
JRuby is not a "merger" of the Java and Ruby languages. It is an implementation of the Ruby language for the Java platform.
You later say:
So I guess you hate all languages, since in C, the following two programs, varying only in whitespace, are very different: vs, Or, heck, if you don't consider C99 "real" C, ask yourself why C has a line splicing character ("\") to convert multiple physical lines into a single logical line: if whitespace (newline vs. space/tab) wasn't significant in C, you would never need such a tool.
And the basis for this is...what? Is the director actively hostile to the source material, as there was with film "adaptation" of Starship Troopers?