This 80%/20% number is not for wealth (it is for income), and not for the U.S. (it is for the world).
"A 1993 UNDP report noted that the wealthiest 20% of humanity receives 82.7% of the world's income."
-- taken from here: http://www.idrc.ca/library/document/103249/chap3.h tml
Income distribution isn't quite that bad in the US, the top 20% get a little under 50% of the income. See http://www2.kenyon.edu/people/schalliold/ch1.htm
The distribution of wealth is much worse for both cases. I don't have figures for the world, but in the U.S. the top 10% of the population owns over 80% of the assets. -- see http://www.billtotten.com/english/ow1/00268.html
This doesn't sound like an easily replaced MB to me, it sounds like one of those integrated units that you can't twiddle with.
But the idea of an easily replaced MB is kinda silly anyhow, it is the hub into which everything else plugs, having it removable would require making something else the hub. Then it would be hard to replace... and you'd get slowdown due to increased wire length.
The situation is similar to the US in terms of standards (lack of conforming to), but the phones themselves are much cooler. Not suprising, since most are made there.
The problem is of course that CISC = variable length instruction, which means decode is a pain.
An ISA designed with this in mind might be a win (say first few bits determine instruction length for example), but you still end up with decode of an instruction depending on finding out where it begins which depends on the previous instruction type which depends on the one before it which depends on... This makes decoding a lot of instructions at the same time hard, which means having a fat pipe is harder.
I'd just like to note that Sweeney seems much less disdainful of functional langauages if you read his article on the unreal technology page where he specifically lauds Haskell.
He does seem somewhat less than willing to look at the advantages of functional languages in the article (maybe he doesn't realize Haskell is a functional language?).
Of course, none of the ideas are Sweeney's as he makes clear on the Unreal Technology page in his update called Engine R&D Notes posted on Nov 30, 1999, at 3:20 AM.
The closest thing to what is being described in terms of a non-experimental/non-academic language seems to me to be either Haskell or BETA. Haskell is free and available for Linux, Beta is also free and comes with an extensive development environment (called Mjølner) and it is also available for Linux (yay!). Both of these langauges are very interesting.
Most of the other systems that implement new ideas are experimental and not available AFAIK, but papers describing them are available.
Some good papers to look at are:
Kim Bruce's Papers: pretty much everything he lists under research is related to this thread.
Luca Cardelli's Papers: most of the stuff that relates is under Types and Semantics, but the other catagories have worthwhile stuff too.
Phillip Wadler has so many fascinating papers on so many interesting topics that I'm just gonna link to his main page... what else can I do?
These are good starting points. For more places to look see my list of language bookmarks , especially under people & projects (or specific languages).
> in C++ and other OO languages functions can be virtulized (without you realizing it)
Um, not if you're even a semi-decent C++ programmer. One of the problems with from a flexibility POV is that C++ doesn't make virtual functions unless you tell it to... this is precisely to avoid the "extra layers of indirection" if you're not using them.
The single level of indirection (due to the vtable lookup) is there with C or C++ if you're using polymorphism. The cost is minimal unless it causes a cache miss.
> using all your latest multiple inheritance, operator overloading etc. my be easier to develop and debug
Or it might not since C++ has such a bad version of parametric polymorphism.
> all that extra function call overhead and indiretion
Templates and operator overloading don't have any overhead... (well, templates have space overhead which can lead to extra cache misses, etc...)
BTW: Kim Bruce's work on statically typing and avoiding dynamic type-checks is worth looking at in this regard.
Perl is write-only because TIMTOWTDI means that oftentimes code not written by you will do things in ways that you never thought of and thus be completely incomprehensible.
TIMTOWTDI is opposed to orthagonality. It makes it easy to learn how to do new things, but makes things harder to maintain.
This isn't anything that can't be overcome with good comments and uniform coding style (ie: everyone in a group using the same methods), but it is a definite tendency in any language that gives you more than one way to do common tasks (this is true of C++ also).
Slashdot Mirror
This 80%/20% number is not for wealth (it is for income), and not for the U.S. (it is for the world).
"A 1993 UNDP report noted that the wealthiest 20% of humanity receives 82.7% of the world's income."
-- taken from here: http://www.idrc.ca/library/document/103249/chap3.h tml
Income distribution isn't quite that bad in the US, the top 20% get a little under 50% of the income. See http://www2.kenyon.edu/people/schalliold/ch1.htm
The distribution of wealth is much worse for both cases. I don't have figures for the world, but in the U.S. the top 10% of the population owns over 80% of the assets. -- see http://www.billtotten.com/english/ow1/00268.html
This doesn't sound like an easily replaced MB to me, it sounds like one of those integrated units that you can't twiddle with.
But the idea of an easily replaced MB is kinda silly anyhow, it is the hub into which everything else plugs, having it removable would require making something else the hub. Then it would be hard to replace... and you'd get slowdown due to increased wire length.
Nonetheless, he lists the 3rd addition in his book section at the link you provided
It's in the "Books I helped write which no longer acknowledge me as a contributor because of company politics" section. <G>
The situation is similar to the US in terms of standards (lack of conforming to), but the phones themselves are much cooler. Not suprising, since most are made there.
The problem is of course that CISC = variable length instruction, which means decode is a pain.
An ISA designed with this in mind might be a win (say first few bits determine instruction length for example), but you still end up with decode of an instruction depending on finding out where it begins which depends on the previous instruction type which depends on the one before it which depends on... This makes decoding a lot of instructions at the same time hard, which means having a fat pipe is harder.
Like anything, it's a tradeoff.
Plus it's a degree in one of eight fields with an option in nano, they are:
Chemistry
Physics
Bioengineering
Chemical Engineering
Electrical Engineering
Materials Science and Engineering
Biochemistry
Molecular Biotechnology
Physiology and Biophysics
All of which are good to have a degree in.
Not that I'm saying that isn't true of .NET, just that some UVM (Universal VM) is needed other than the JVM.
The fact that Mercury has been ported is slightly promising though.
--
cjon
He does seem somewhat less than willing to look at the advantages of functional languages in the article (maybe he doesn't realize Haskell is a functional language?).
The closest thing to what is being described in terms of a non-experimental/non-academic language seems to me to be either Haskell or BETA. Haskell is free and available for Linux, Beta is also free and comes with an extensive development environment (called Mjølner) and it is also available for Linux (yay!). Both of these langauges are very interesting.
Most of the other systems that implement new ideas are experimental and not available AFAIK, but papers describing them are available.
Some good papers to look at are:
These are good starting points. For more places to look see my list of language bookmarks , especially under people & projects (or specific languages).
Um, not if you're even a semi-decent C++ programmer. One of the problems with from a flexibility POV is that C++ doesn't make virtual functions unless you tell it to... this is precisely to avoid the "extra layers of indirection" if you're not using them.
The single level of indirection (due to the vtable lookup) is there with C or C++ if you're using polymorphism. The cost is minimal unless it causes a cache miss.
> using all your latest multiple inheritance, operator overloading etc. my be easier to develop and debug
Or it might not since C++ has such a bad version of parametric polymorphism.
> all that extra function call overhead and indiretion
Templates and operator overloading don't have any overhead... (well, templates have space overhead which can lead to extra cache misses, etc...)
BTW: Kim Bruce's work on statically typing and avoiding dynamic type-checks is worth looking at in this regard.
TIMTOWTDI is opposed to orthagonality. It makes it easy to learn how to do new things, but makes things harder to maintain.
This isn't anything that can't be overcome with good comments and uniform coding style (ie: everyone in a group using the same methods), but it is a definite tendency in any language that gives you more than one way to do common tasks (this is true of C++ also).
IMHO.
YMMV.
ps: my email address isn't real.