I'm not one of the rabid Free Marketers around here, but your logic is flawed: it does not follow that actors in a free market be omniscient for them to make informed decisions.
It does for them to make rational decisions as underpin basic market theory, since rationality, as defined there, is defined as making decisions based on perfect and complete information about the consequences, as well as acting to maximize the actor's own realized utility based on that information.
That this rational actor model is, at best, a simplified model is well-known; though GP's description of the economic theory which results from it as a "fairy tale" is rather hyperbolic.
In this article on the BBC News website, Professor Gordon Murray explains that a weight saving of 10% in a normal car would make more difference than switching to a hybrid engine and motor combination.
Maybe it would, who cares? Many cars that are focussed on fuel economy from the ground up use advanced drivetrain along with fine tuning aerodynamics and construction techniques. The ones that just use a different drivetrain tend to be alternate-drivetrain versions of models that also are available with a traditional drivetrain. Lots of manufacturers offer hybrid options for models that aren't hybrid-only. The advantage of this is that you share most of the frame and body with versions that are expected to sell more widely, keeping the cost down.
So, (1) presenting it as improved construction vs. improved drivetrain is a false dichotomy, for purpose-designed efficient vehicles, you use both (and aerodynamic improvements, among others) together, and (2) for manufacturers working in the real world, improved drivetrains are particularly useful outside of ground-up designs-for-efficiency, as they are more easily incorporated into an existing product mix where the volume expected from the less expensive base vehicles keeps the overall price of the more expensive advanced vehicles down because of the opportunity for shared components.
However, the very OO-centric approach falls flat on its face sometimes. Functional really does fit the bill better, and there, Python's more balanced approach is nice. For instance:
genome11.mateWith(genome2) # Ruby/Java style vs mate(genome1, genome2) # Python style
In the first case, you're implying genome1 has the correct implementation, which could have been overriden. In the second case, you're implying mating is not a function of either genome, but a function of the pair itself, which is what most accurately represents the real relationship.
Actually, the "mating" behavior seems to be a behavior of the type-of-thing "genomes", for which the most direct translation into Ruby-style OO is using a class method on the Genome class which takes two genome objects and returns a third, e.g., Genome.mate(genome1, genome2). Now, its true that frequently people would implement this using instance methods, but that's no less true of Python than Ruby. Using a global "mate" function, as your Python version does, is not good, because then if you want to implement, say, mating behavior for organisms, and you try to do mate(organism1, organism2) you can't, and you have to work around that. If you use class methods in Ruby, you naturally then have Organism.mate(organism1, organism2). And, even if it is less elegant than class methods, you don't have a problem if you used instance methods either, as organism1.mate(organism2) doesn't get in the way of genome1.mate(genome2).
Of course, using Common Lisp or some other system that supports multimethods instead of Python would obviate the problems with the Python approach you suggest, since then mate could be a multimethod with genome, genome and organism, organism specializations, so there would be no collision. I think class methods have the best match to the logic of what is going on, though in practice I'd probably implement instance methods that called the class methods.
Actually, the use of method_missing is discouraged because it's slow and difficult to extend when multiple features end up needing it.
Discouraged by whom? If you use modules for library components and call super to chain them, its not hard to extend. It is hard to extend if you just monkeypatch it directly into classes, but that's true of anything you do that with, not just method_missing.
Much better is to dynamically do define_method / alias_method / etc.
Supposing that what you are trying to do is something that makes sense to do that way, that can be better. Not everything you'd want to use method_missing for works as naturally with that approach though. Sure, there are better approaches than using method_missing for many uses, but if everything in Ruby, as claimed, has an equivalent in most other languages, and as implied by the examples, specifically in Java, I'd still like to know the equivalent of method_missing in Java.
Why not replace the javascript engine (spidermonkey/tamarin) with Parrot (or something similiar) that can run a script in ANY language?
Why do you need to replace the JavaScript engine to do that? If you've got an engine like Tamarin that uses a separate JavaScript compiler and VM, you already have something like Parrot: all you have to do, like Parrot, is build the compilers for your other languages for the VM.
This is esentially what MS is trying to do with silverlight and its actually a pretty good idea.
Its also essentially what Mozilla/Adobe are trying to do with Tamarin. Its fairly fundamental to the idea of "browser as platform": a platform that supports only one language isn't much of a platform.
So far everything I've seen that was at all "special" about Ruby is available in just about every other language via helper classes (like Integer for ints in Java) and perhaps slightly less graceful structures like callbacks (just look at jQuery, for example.)
Since your examples are all Java, what is the Java equivalent (even with a "slightly less graceful" structure) of #method_missing in Ruby that lets you capture and respond to arbitrary methods calls on an object, with access to the name of the method called and the parameter list? This one feature is a major center of the support for internal DSLs and metaprogramming in Ruby, and Java doesn't, AFAIK, support anything much like it.
I guess they're hoping someone else will make it less of a CPU hog.
Well, they are still working on it, just letting other people work on (and use) some components of it as well. Its not like Adobe stopped being involved in Tamarin once they gave it to Mozilla.
When you develop an AJAX application, it runs in the browser without any special client-side extensions. "ARAX" requires Silverlight
ARAX doesn't require Silverlight--HotRuby is a Ruby-on-JavaScript engine that runs Ruby 1.9 bytecode. Microsoft would probably like people interested in Ruby-in-the-browser to get locked into Silverlight before they are aware of any of the other efforts in that direction, since they (HotRuby, Tamarin:IronMonkey) tend to be JavaScript-centered and Flash- and Mozilla-friendly, and thus don't contribute to Microsoft's efforts to have their browser and OS have the first and best implementations of the technology so that anyone using it will have a reason to stick with Microsoft platforms.
Well, JRuby's better than MRI, performance wise, unlike IronRuby, which is worse, so if we wanted to ARAX, it would be better to embed a JVM in the browser than a.NET system like Silverlight.
With ECMAScript 4, the advantages of running anything other than Javascript fade away: you still have all your Ruby/Python/Lisp features, just spelled differently.
No, you won't, except in the sense that all Turing-complete languages are equivalent. You don't have Smalltalk-style message passing, as in Ruby. You don't have universally-open classes as in Ruby (you can create classes as "dynamic" with an explicit declaration where they are defined, but even then it seems you can't redefine their methods.) You don't have a Scheme-style numeric tower. You'll probably be missing all kinds of features near and dear to the heart of Python fans that I'm not immediately thinking of.
Also, instead of trying to compile languages to MSIL, why not just write a source-to-source translator to Javascript?
Sure, you can compile to a language designed as a "source" language rather than to machine code, VM bytecode, or something like MSIL designed as an intermediary language. And it may sometimes be good for portability when you've got a target language for which there are source-compatible implementations on different platforms without anything lower-level that is compatible. But if you've got something lower-level that is compatible, compiling to that is often going to be better for performance.
Now they are trying to develop proprietary technologies to compete: Silverlight and this new ARAX bull will replace Flash and AJAX.
Given HotRuby and Tamarin:IronMonkey, Silverlight & ARAX is going to have to fight Flash & ARAX, Flash & APAX, Flash & APyAX, and all kinds of other things, not just Flash & AJAX.
Stunning insight. A language "for people who hate Java" is nothing like Java? Wow.
GP did not characterize it as merely a language "for people who hate Java", but as "Java for people who hate Java". Which might be a fair description of, say, C#, which is similar in role in many big-picture ways to Java, but addresses numerous points which make people who hate Java do so. It is not a useful description of Ruby, which is nothing like Java except insofar as both are Turing-complete programming languages.
It just seems like Java for people who hate Java from what little research I've done on it
Its nothing like Java.
Now, if you said it sounds like "Python for people who hate Python", that would be more reasonable. Or, say, "Perl for people who can't read Perl". But those, though better than "Java for people who hate Java", still miss the point.
Its a dynamic scripting language whose strongest initial influences were, IIRC, Smalltalk and Perl; it was more OO from the start than Python, though I think that's less of a gap now. It seems to have stronger influences from functional programming than Python, and its design follows more of Perl's "There's more than one way to do it" philosophy than Python's more "There's one way to do it" approach. It has good support for metaprogramming and internal DSLs. Its frequently criticized for the fact that the main current (1.8.x) implementation is slow, even among dynamic scripting languages, though faster implementations (the new, but less stable, 1.9 implementation, and the alternative, Java-based, 1.8-compatible JRuby implementations) exist.
Anybody see Firefox adding support for other scripting languages as a result of this?
Mozilla is already working with Adobe on a project called "Tamarin" which is an bytecode compiled Javascript engine that will be used in Mozilla products and Adobe products, one side project of which ("IronMonkey") is aimed at providing Ruby and Python (and maybe PHP) support, apparently through simply taking IronRuby and IronPython (and maybe IronPHP) and doing a mapping from the CIL to Tamarin's bytecode. So I don't see Mozilla adding more scripting language support in response to Microsoft's recent announcements, since Mozilla's already working on that support.
There are also another Ruby on JavaScript project (HotRuby) that has produced a working (but somewhat limited, so far) Ruby 1.9 bytecode interpreter that runs on JavaScript. So support for additional scripting languages in browsers seems to be coming from multiple different directions.
There are at least two Ruby-on-JavaScript (HotRuby, IronMonkey) projects I know of, the former of which has a working, limited Ruby 1.9 bytecode interpreter running on JS.
Now that they're married (because nobody would be stupid enough to share this type of data BEFORE marriage...would they?), they share their genetic information with each other as they are talking about children. But, what's this?! Juliet sees that Romeo has a high propensity for Down Syndrome (or any other "disease" - take your pick). Well, this isn't good.
So, instead, Juliet decides to get a divorce and go on her merry way.
Is this really bad, compared to alternatives like someone like Juliet that can't cope with even the possibility (much less the reality) of a child born with a genetic defect not knowing about the probability but leaving after such a child is born, or when she turns up pregnant with such a child and she and Romeo can't agree on what to do. Or has the child and stays around -- but is abusive or neglectful because she can't deal with the child.
I personally see the digitalization of medical records happening *very* slowly - over the next 20 years or so. And that's a feature, not a bug folks. There are absolutely huge societal issues to be dealt with before we give some uber-governmental department the holy grail of databases.
Having a standard format and infrastructure for requesting and exchanging digital records doesn't mean having a single entity (government or otherwise) with access to all the data.
But can we at least have one of these conversations without people throwing around the "M" word like it applies to any and every situation involving a public corporation?
Yeah, its really annoying when people say "Monopoly" when the right term is "Oligopoly".
Even without Alltel being bought by Verizon, the four-firm concentration (combined marketshare of the top four firms) in the wireless market is over 80%.
What it certainly is not is a open, competitive market.
As another example, the human brain has about 10^11 neurons. Each of those may be connected to 10^4 other neurons, so the total number of connections is about 10^15. That suggests that the total amount of RAM needed for direct, brute-force modeling of a human brain (assuming we knew enough to program such a model, which we don't, and had parallel processors that could run such a simulation, which we don't) might be about 10^15 bytes, which is a 50-bit address space.
Assuming, of course, that the brain could be adequately modelled as a network with a 1-byte weights for each connection as the only relevant state. Which seems rather unlikely.
Right, but I believe for mass storage (colloquial, not technical; 512M is mass storage technically...), you can't approach the price of a hard disk.
Well, sure, you can't today; if you could, SSDs would already have displaced HDDs. Over the long-term, though, SSDs are improving (capacity:cost) faster than HDDs, and are likely to continue to do so for some time.
Ruby 1.9 support for unicode is minimal. It just allow you to use unicode but it has absolutely nothing to let you to actually use foreign languages with sorting, capitalization and so on.
The things you list are important for internationalization, to which Unicode support (as is support for local encodings where Unicode is not necessarily dominant) is also important, but beyond that they have nothing to do with Unicode support.
Slashdot Mirror
It does for them to make rational decisions as underpin basic market theory, since rationality, as defined there, is defined as making decisions based on perfect and complete information about the consequences, as well as acting to maximize the actor's own realized utility based on that information.
That this rational actor model is, at best, a simplified model is well-known; though GP's description of the economic theory which results from it as a "fairy tale" is rather hyperbolic.
As with polls, the state of the markets immediately before the election tends to be a pretty good predictor of who will win the election.
Maybe it would, who cares? Many cars that are focussed on fuel economy from the ground up use advanced drivetrain along with fine tuning aerodynamics and construction techniques. The ones that just use a different drivetrain tend to be alternate-drivetrain versions of models that also are available with a traditional drivetrain. Lots of manufacturers offer hybrid options for models that aren't hybrid-only. The advantage of this is that you share most of the frame and body with versions that are expected to sell more widely, keeping the cost down.
So, (1) presenting it as improved construction vs. improved drivetrain is a false dichotomy, for purpose-designed efficient vehicles, you use both (and aerodynamic improvements, among others) together, and (2) for manufacturers working in the real world, improved drivetrains are particularly useful outside of ground-up designs-for-efficiency, as they are more easily incorporated into an existing product mix where the volume expected from the less expensive base vehicles keeps the overall price of the more expensive advanced vehicles down because of the opportunity for shared components.
Actually, the "mating" behavior seems to be a behavior of the type-of-thing "genomes", for which the most direct translation into Ruby-style OO is using a class method on the Genome class which takes two genome objects and returns a third, e.g., Genome.mate(genome1, genome2). Now, its true that frequently people would implement this using instance methods, but that's no less true of Python than Ruby. Using a global "mate" function, as your Python version does, is not good, because then if you want to implement, say, mating behavior for organisms, and you try to do mate(organism1, organism2) you can't, and you have to work around that. If you use class methods in Ruby, you naturally then have Organism.mate(organism1, organism2). And, even if it is less elegant than class methods, you don't have a problem if you used instance methods either, as organism1.mate(organism2) doesn't get in the way of genome1.mate(genome2).
Of course, using Common Lisp or some other system that supports multimethods instead of Python would obviate the problems with the Python approach you suggest, since then mate could be a multimethod with genome, genome and organism, organism specializations, so there would be no collision. I think class methods have the best match to the logic of what is going on, though in practice I'd probably implement instance methods that called the class methods.
Discouraged by whom? If you use modules for library components and call super to chain them, its not hard to extend. It is hard to extend if you just monkeypatch it directly into classes, but that's true of anything you do that with, not just method_missing.
Supposing that what you are trying to do is something that makes sense to do that way, that can be better. Not everything you'd want to use method_missing for works as naturally with that approach though. Sure, there are better approaches than using method_missing for many uses, but if everything in Ruby, as claimed, has an equivalent in most other languages, and as implied by the examples, specifically in Java, I'd still like to know the equivalent of method_missing in Java.
Why do you need to replace the JavaScript engine to do that? If you've got an engine like Tamarin that uses a separate JavaScript compiler and VM, you already have something like Parrot: all you have to do, like Parrot, is build the compilers for your other languages for the VM.
Its also essentially what Mozilla/Adobe are trying to do with Tamarin. Its fairly fundamental to the idea of "browser as platform": a platform that supports only one language isn't much of a platform.
Since your examples are all Java, what is the Java equivalent (even with a "slightly less graceful" structure) of #method_missing in Ruby that lets you capture and respond to arbitrary methods calls on an object, with access to the name of the method called and the parameter list? This one feature is a major center of the support for internal DSLs and metaprogramming in Ruby, and Java doesn't, AFAIK, support anything much like it.
Well, no, they opened the VM and a partial JavaScript compiler, which is part of Flash, but not the same thing as Flash.
Well, they are still working on it, just letting other people work on (and use) some components of it as well. Its not like Adobe stopped being involved in Tamarin once they gave it to Mozilla.
ARAX doesn't require Silverlight--HotRuby is a Ruby-on-JavaScript engine that runs Ruby 1.9 bytecode. Microsoft would probably like people interested in Ruby-in-the-browser to get locked into Silverlight before they are aware of any of the other efforts in that direction, since they (HotRuby, Tamarin:IronMonkey) tend to be JavaScript-centered and Flash- and Mozilla-friendly, and thus don't contribute to Microsoft's efforts to have their browser and OS have the first and best implementations of the technology so that anyone using it will have a reason to stick with Microsoft platforms.
Well, JRuby's better than MRI, performance wise, unlike IronRuby, which is worse, so if we wanted to ARAX, it would be better to embed a JVM in the browser than a .NET system like Silverlight.
Hey. Java in the browser. That's a new idea...
But, ALAS, Lispers don't use XML, as they prefer S-expressions.
No, you won't, except in the sense that all Turing-complete languages are equivalent. You don't have Smalltalk-style message passing, as in Ruby. You don't have universally-open classes as in Ruby (you can create classes as "dynamic" with an explicit declaration where they are defined, but even then it seems you can't redefine their methods.) You don't have a Scheme-style numeric tower. You'll probably be missing all kinds of features near and dear to the heart of Python fans that I'm not immediately thinking of.
Sure, you can compile to a language designed as a "source" language rather than to machine code, VM bytecode, or something like MSIL designed as an intermediary language. And it may sometimes be good for portability when you've got a target language for which there are source-compatible implementations on different platforms without anything lower-level that is compatible. But if you've got something lower-level that is compatible, compiling to that is often going to be better for performance.
Given HotRuby and Tamarin:IronMonkey, Silverlight & ARAX is going to have to fight Flash & ARAX, Flash & APAX, Flash & APyAX, and all kinds of other things, not just Flash & AJAX.
GP did not characterize it as merely a language "for people who hate Java", but as "Java for people who hate Java". Which might be a fair description of, say, C#, which is similar in role in many big-picture ways to Java, but addresses numerous points which make people who hate Java do so. It is not a useful description of Ruby, which is nothing like Java except insofar as both are Turing-complete programming languages.
Its nothing like Java.
Now, if you said it sounds like "Python for people who hate Python", that would be more reasonable. Or, say, "Perl for people who can't read Perl". But those, though better than "Java for people who hate Java", still miss the point.
Its a dynamic scripting language whose strongest initial influences were, IIRC, Smalltalk and Perl; it was more OO from the start than Python, though I think that's less of a gap now. It seems to have stronger influences from functional programming than Python, and its design follows more of Perl's "There's more than one way to do it" philosophy than Python's more "There's one way to do it" approach. It has good support for metaprogramming and internal DSLs. Its frequently criticized for the fact that the main current (1.8.x) implementation is slow, even among dynamic scripting languages, though faster implementations (the new, but less stable, 1.9 implementation, and the alternative, Java-based, 1.8-compatible JRuby implementations) exist.
Mozilla is already working with Adobe on a project called "Tamarin" which is an bytecode compiled Javascript engine that will be used in Mozilla products and Adobe products, one side project of which ("IronMonkey") is aimed at providing Ruby and Python (and maybe PHP) support, apparently through simply taking IronRuby and IronPython (and maybe IronPHP) and doing a mapping from the CIL to Tamarin's bytecode. So I don't see Mozilla adding more scripting language support in response to Microsoft's recent announcements, since Mozilla's already working on that support.
There are also another Ruby on JavaScript project (HotRuby) that has produced a working (but somewhat limited, so far) Ruby 1.9 bytecode interpreter that runs on JavaScript. So support for additional scripting languages in browsers seems to be coming from multiple different directions.
There are at least two Ruby-on-JavaScript (HotRuby, IronMonkey) projects I know of, the former of which has a working, limited Ruby 1.9 bytecode interpreter running on JS.
So, if your browser supports JavaScript...
Is this really bad, compared to alternatives like someone like Juliet that can't cope with even the possibility (much less the reality) of a child born with a genetic defect not knowing about the probability but leaving after such a child is born, or when she turns up pregnant with such a child and she and Romeo can't agree on what to do. Or has the child and stays around -- but is abusive or neglectful because she can't deal with the child.
Having a standard format and infrastructure for requesting and exchanging digital records doesn't mean having a single entity (government or otherwise) with access to all the data.
Web 3.0? That's just silly.
Yeah, its really annoying when people say "Monopoly" when the right term is "Oligopoly".
Even without Alltel being bought by Verizon, the four-firm concentration (combined marketshare of the top four firms) in the wireless market is over 80%.
What it certainly is not is a open, competitive market.
Assuming, of course, that the brain could be adequately modelled as a network with a 1-byte weights for each connection as the only relevant state. Which seems rather unlikely.
Well, sure, you can't today; if you could, SSDs would already have displaced HDDs. Over the long-term, though, SSDs are improving (capacity:cost) faster than HDDs, and are likely to continue to do so for some time.
So, if I set RepRap beside my laser printer, the RepRap will invade and occupy the printer?
The things you list are important for internationalization, to which Unicode support (as is support for local encodings where Unicode is not necessarily dominant) is also important, but beyond that they have nothing to do with Unicode support.