I think a lot of people hate java because it makes the feel obsolete
I agree. If twisting your brain to think like a silicon chip that is less intelligent than your average paramecium is your yardstick of personal greatness, so be it. It's not mine. I'd rather spend my time defining the architecture to solve the problem at hand than spend a few months writing the infrastructure to support that architecture. I'd rather let an expert on linked lists write the most efficient linked list possible, and just let me inherit from it.
Why does business like it?
For what you said, and so much more. In the end, Java reduces resource costs. It lets them choose their platform, and not be hamstrung because of that decision down the road. It lets them escape vendor lockin. It lets them vastly reduce their support costs. And many other reasons that I'm just too tired to list.
So the last refuge of the C, C++ programmer is speed. They can say there app is slightly faster then Java apps. With computers getting faster every day, this becomes less and less of an argument.
And besides, hardware is cheap, at least to a company. It's cheaper to buy many times more hardware to support a more maintainable application than it is to try to cut hardware costs by spending an arm and a leg developing the fastest, most efficient software. Not only do they risk not doing that (it's like a 10% shot that they can even do it), but the lifetime of hardware is much shorter than that of software, and it tends to be a fixed cost, unlike problems with software.
The answers I typically get are not related to the programming *language* at all, but the organization and "java culture":
But why does this invalidate the answers you get? Any language is equally as much a union of the language syntax itself and its built-in capabilities, i.e. its libraries. Your question is analogous to asking what is the advantage of English syntax over French syntax. In the broad scope of things, nothing really makes one better than the other--except perhaps their vocabularies.
The richness of a language's vocabulary is what lets its speakers express themselves in powerful ways distinct from what other language speakers can do. French has a number of terms and concepts that don't have direct translations in English, and in fact, a huge amount of common English vocabulary comes from French.
A programming language's libraries are equivalent to a natural language's vocabulary. And this is exactly where Java shines the most from an application development point of view. (It shines for other reasons on other fronts, like for embedded programming.)
If you REALLY hated pointers that much you could write C++ code without pointers and write your own garbage collector (not to mention that LISP does garbage collection too -- nothing new).
Sure, you can go out and develop a C++ app without using pointers, but that's just one app. The next one probably will use pointers. Even if I become a C++ programmer and refuse to use pointers in all my applications, I will have to work with someone who does, or use a library that requires them (is there one that doesn't?). And, eventually, I'll have to maintain someone's code that uses pointers. In the end, there's no getting away from it. Java eliminates the vulnerability pointers represent unilaterally, for better or worse.
And similarly, you can go grab a library for doing garbage collection, but which one? You have nearly infinite choices, and every app will make a different choice. It's exactly the consistency of features that make Java superior in this regard. And when I say superior, I mean cheaper, and not just in terms of money, but in terms of resources. The support engineer trying to fix a bug in a Java program won't have any questions about the subtleties of a garbage collection API he's never seen, nor wonder what's in this odd little pointer that seems to keep causing a production crash. These are real advantages, even if they are hard to quantify.
I haven't seen too many implementations when cross-platform is needed at run-time
That's just the limit of your experience then. My experience is exactly the opposite. The advantage here is the fact that you maintain a single codebase--the same source files--for all platforms, and they do work as advertised minus any VM bugs (which are fairly rare compared to application bugs).
Let me tell you a story. I used to work for one of the real success stories of the dot-com era. My company implemented different pieces of its product using Java and C++, and these pieces used CORBA to interoperate. As far as any one distributed object was concerned, the object on the other end could be any language; it was only a difference of implementation.
Anyway, the support and maintenance costs for the Java portion of the product were dramatically lower than for the C++ portions. They both used the same infrastructure, but one was cheaper and faster to develop in, easier to fix and enhance for the next version, easier to debug both in-house and in the field, and more stable to boot. Add to this the fact that you only had one copy of the source files for the Java portions, versus the several versions for all the different platforms we supported in C++. In the end, if you work on large, complex software systems, Java is vastly easier to maintain, and vastly cheaper to support. Ask any of the product engineers and they would say the same thing: Java is just more pleasant and productive to work in, and they prefer Java over C++. They all hated the C++ portions of the product, and regretted ever putting them in.
And, sadly, most programmers out there aren't that good. With C++, you give them a loaded weapon and tell them to be careful. As often as not, they inadvertantly shoot you or themselves. At least with Java, poor programmers have to load the gun before they can shoot anyone. Sorry for the extended analogy.
You know the platform of your server (it won't randomly change without you knowing) so why not write in a higher-level language such as C++ and skip all the platform-dependant code (or do ifdefs) and have it run natively faster? If your platform changes you just re-compile
Ugh, so much to say here. The problem is that what you are suggesting is a myth; it does not represent the real world of enterprise application development. You don't know your platform, it is not a constant in the equation. You want to provide for all platforms if you're a software vendor. Once you can sell to one, using Java, you can sell to all others without any significant extra effort. Furthermore, bugs fixed in one version of your code are fixed in all versions--support costs go down dramatically.
If you're a client, you may find that you are grossly unsatisified with vendor X's hardware/support/performance and want to switch to using a solution by vendor Y (and this happens all the time in the corporate environment). What do you do now? Just because you know things are changing doesn't make the cost of changing any less. However, the fact that you wrote your application in Java does make the cost less--it makes it nil, because the same code runs on HP, Solaris, Intel, Windows, Linux, MacOS, AS/400, etc. The ability to move code effortlessly between platforms allows you as a company to save costs if it makes sense to switch hardware platforms, or mix and match platforms.
"Java has a cross-platform GUI". So is GTK and QT.
Yes, but the application code your GUI fronts is also cross-platform. Not so with the others. And again, there's the benefit of the single binary versus a binary per platform.
"Java is easy to learn". I'll skip that.
That's fine, but it really is. Try it. The limited complexity of the language lets programmers focus on the task at hand far more easily in my experience, and it's much easier to do OO in Java than in C++. This means all the benefits of OO are more easily achievable (and if you don't think OO is a good thing, don't bother talking to me.)
Why program in Java when you can achieve the same result faster in another language?
If you can, great, but I haven't found that language yet. It might be Smalltalk, or Perl, or COBOL, but nothing so far has taken all the great ideas from all of these languages and made them so eminently useful and practical. For example, Smalltalk is probably the most elegant, most forward-thinking languages around (even today), with tons of powerful features. However, it doesn't have the network orientation that Java does, or the C/C++ like syntax that makes it easy for developers to learn. It doesn't have the ability to be pared down and run inside a DIMM-sized computer, or be as dynamic as Java.
I'm not advocating Java over other languages if those languages are more suited to the job. I'm not going to write a device driver in Java. I'm suggesting that a task that can be equally accomplished in Java and some other language will be more maintainable, cost less to support, and completed more quickly, when written in Java. The real-world merits of Java are that it reduces resource costs for anyone using it, end of story.
I hate to break it to you, but the COBOL rates are well over $200 an hour. I guess we can both see what that says about the correlation of language obsolesence to billing rates.
Oh, and by the way, when I used to bill (I left the loser consulting lifestyle behind long ago), I billed $10,000/week for enterprise Java expertise. You do the long division.
I am [sic] yet to see serious desktop application written in Java
Even if this were true (and it's not), what does a desktop application have to do with Java's viability? I've yet to see a serious desktop application written in COBOL, FORTRAN, or Perl. Furthermore, I have yet to see a serious desktop application written in any language for Linux. What does that say?
Anyway, with.net and C#, Java is already history
That's funny, since.net and C# aren't even the present yet.
they have also decided on a name for this wonderful new technology: C.
In other news, computer scientists have developed a way to preserve all the flaws of assembly language without having to remember those pesky 3-letter pneumonics. They have also decided on a name for this wonderful new technology: C.
Seems to me the problem with Java is that it waits until memory is full to garbage collect.
Your information is out of date. See the information on the HotSpot VM and its use of generational GC. Essentially, short-lived objects are GC'd frequently.
Just brainstorming here, but what about making every Java class (or related group of classes) a shared library that can be dynamically loaded? Seems like you could fake class inheritance by using inter-library references and some infrastructure to fix-up the references dynamically. Polymorphism would be achieved by translating calls to "super" as calls to the "parent" library.
I have yet to be proven wrong that developing using C++ is any harder or time consuming than writing in Java.
From this I deduce that you are either a student or someone in academia, or someone working at a small shop somewhere writing non-commercial or only minorly-commercial software. There is just no comparison when writing large, real world commercial (or even non-commercial IMHO) software. You wouldn't need it proved to you if you saw the misery C++ causes in these situations.
I myself have 7 different conceptual collection systems implemented that can be easily integerated into any code you want.
You know, this is exactly what I would expect guys like you to say. You have 7 different ways, the guy in the next cube has 3, my last company had N. This is the problem. Java has this capability built into the system, it works one way, and everyone understands it, both its strengths and its flaws. Same goes for all the other class libraries you mention in you argument.
The point is, I can come in and maintain someone else's code with far less trouble if it's written in Java than I can if it's written in C++. Same goes for the support engineers. Same goes for customers.
If it's written in C++, the application can essentially be a language unto itself. You have different mechanisms for just about any major feature between development teams; none of them are standard, and none of them are even remotely as easy to learn and use as the equivalent Java API. Maintaining these applications costs a huge amount, and is fraught with support issues exactly because there are so many incompatible ways of doing the same thing.
Your argument is so tired because it doesn't take into account the actual cost of developing real applications--maintenance and support.
Those who say that Java is easier to program in really don't want to learn the advantages of programming in C++.
Wrong: Those who say that Java is easier to program in (and who don't know C++) really don't want to learn the disadvantages of programming in C++.
If you disagree with those points and want to rebut them, fine-- but perhaps you should at least read them first?
Why extend this courtesy to someone who's stated very clearly that he won't reciprocate? If he uses someone's choice of mail client as a "lameness" filter, why shouldn't we use his voluntary censoring of himself as a "bigoted jackass" filter?
Well, I didn't know that, so thanks to the original poster for mentioning it. There's no need to rag on him/her for mentioning something "you and every single person *you* know" knows. It's a bigger world than your circle of friends.
Not today, but I remember reading that figure on BioWare's site. Of course, that includes doing *all* the quests, and all the little details that make the game immersive.
Part of me likes it though, I'm somewhat ashamed to admit. It used to really *SUCK* getting stuck at a certain stage in a game and not being able to progress because I had to be in a certain tile when the moon was full, and I needed to piece together clues from 5 towns people in 3 different towns to have figured out that was what I needed to do.
These sorts of puzzles were fun when you were a kid and had all the time in the world to mess around figuring them out. But, what toasts my nuts these days is developers like BioWare who build games that take hundreds of hours to complete. BGII was something like 200+ hours, and if you're a careful or slow player (like me), probably more like 300. I'm an adult with a day job and a family, and I can't spend all those hours playing a pointless game, no matter how fun it is.
I'd much rather see things go the way Serious Sam has, releasing smaller "episodes" that are half the price of other games. I'd like to for once start a game and be able to finish it in a reasonable amount of time (20-30 hours), while the developer cranks out more expansion packs and improvements. It seems like this would be much better for developers too, as they could drastically reduce their time to market.
Any goods you buy will be worth 30% less in a year... you did not gain money, you lost it.
Think about it. If you invest in money, you make 30% *relative to item values*.
What you've suggested is that there is depreciation of the value of items coupled with inflation (meaning depreciation in the value of money). These are opposite trends, and are mutually exclusive. Why? Because item values are defined in terms of the value of money, and the value of money is defined in terms of what items it can buy. A change in one means an opposite change in the other. (Note, once you start stating the value of items in other terms, like how quickly an item helps a given character kill a monster, that's another matter entirely.)
This is like the well-known equivalence of mass and energy. They are the same thing, just different forms. In the same way, items and money are the same "thing" in terms of fungible value, just different forms. And, just as in physics, you must pay a price to change from one form to another. However, the shoe is on the other foot here--the seller pays the price instead of the buyer (by selling at a lower cost than the item cost initially).
What the author suggested was that items become cheaper over time because there is an influx of items of increasingly greater value over time. There is no similar influx of money into the world (AFAIK)--you must sell items to make money. If you could mine platinum to make money, then things would be different. What this all boils down to is that making money is predicated on finding items.
Since the influx of value based on money into the world is small compared to the influx of value into the world based on items, there is a pressure on players to only spend within an absolute range of money for any item. In other words, you have a range of money valuation that ranges from 0 to X, and you have to fit increasingly more items within that range in a marketplace.
I believe all of this was exactly what the author described--if you keep a given amount of money, it increases in value in terms of items over time. Meaning, over time, you can buy more stuff for the same amount of money.
Again, it's another matter entirely if you start stating that a given amount of money buys an increasingly smaller amount of "badass-ness" for your character. This is thinking of item values in terms of their utility. And this is exactly how most characters think of items--that's where the fun of the game is to begin with. But, it's the switching between the two valuation models that confuses everyone I think.
Thats exactly what I said. The same ammount buys less. Thats the same as the same thing costs more.
Sorry, Gaijin, Kjella is right, but please read on.
You said, "The same ammount buys less". No. The same amount of currency today buys the same item for less money than yesterday. It only buys "less" if you are thinking in terms of what an item can do as its inherent value (meaning its suitability for a given character at a given level).
This isn't correct for an analysis of value of money versus item value *in terms of money*, but is an interesting idea. You are talking about the inflation that occurs based on the decrease in item value *in terms of utility*. It's interesting to wonder if this is an offsetting factor in the overall economy.
A working virtual economy on a large scale is very difficult to do -- I haven't seen anyone do it right (yet).
Well, I suppose it depends on what you mean by right, but it seems like the only thing required is to exactly mimic the real world--allow items to decay, limit the number of items, decrease the availability of large numbers of powerful items, etc.
Although this would ostensibly create a realistic economy, it wouldn't be very fun to play relative to games that provide an easier road to riches. The fundamental aspect here is that people like struggle and challenge, but only to a certain point. After that point, unrelenting struggle becomes a source of unhappiness, and so much so that people will stop playing such a game.
The problem is that other than the minimal community aspects of these games, they don't (yet) provide the same sort of fulfillment we can get in the real world. Whether they ever will or not I suppose is up to debate, but so much of our Earthly happiness is based on fulfilling our base desires like eating, sleeping, and mating. It will be a long time, if ever, before a game can provide the same level of satisfaction these activities do. Until then, the hyper-reality aspects that cause deflation will likely remain a popular element of these games.
Furthemore, it's not clear how you sustain a realistic economy with the ability of everyone to have equal opportunities to become richer. This certainly isn't how the real world works, and the premise of equal opportuntiy stems exactly from the abiity to just go out and do what anyone else does to become rich. If you can go farm items from the same pack of biots that a richer person does, the only difference between you is in the length of time each one has been doing it. In the real world, the means of becoming rich are carved out and protected by the rich, meaning equality of opportunity goes out the window.
I understood your original point as exactly what you said below. If you meant something less sweeping--and I hope you did--don't blame me for reading this quote and going off:
...the major obstacle (installation) is pretty much out of the way. The only thing Linux needs to be a true competitor on the desktop is applications.
First, I'm shocked to hear you or anyone else claim that installation is or ever was considered the major barrier to adoption to Linux on the desktop. Installation is/was one barrier, but it's just one part. The desktop is far more than installation, and more than applications that use the desktop. It's a usability pardigm that programs adopt; it's all the glue that underlies the user's experience with the computer. It's where and how files are stored and identified. It's how the user configures the machine and works with the hardware. It's how the user thinks when using the machine. It's a consistent vision of what the machine/OS/application union is.
Great, installation is out of the way, but there's so much more to do, and it's beyond just a little tweaking here and there. Contrary to some opinions, the UNIX/Linux way of doing things is not easy compared to the Windows or Mac way of doing things. Despite the fact that these OS's and computers in general are unintuitive, Linux is definitely even less intuitive.
For example, how does improved installation address the mounting of a Zip drive or the addition of other hardware (all this after initial installation)? How does it help users manage files, or understand what a man page or a command line is, or any of those other things that Linux/UNIX users are comfortable with, but the average user isn't? How do you explain why the user shouldn't be logged in as root, or what the conventions of the UNIX filesystem are, or what they're for? How does a user install and configure the latest version of Quake to run with his badass new video card? I guarantee it's nowhere near as easy as running a Windows or Mac installer and just double-clicking the icon on the desktop.
I think you must be grossly overestimating the the sophistication of the average computer user to think that these sorts of things are below the level of user consciousness, and that any issues in these areas disappear because the user has usable apps. It's almost the opposite--these are the things that are foremost in user's minds, before they ever get into an app. The rest follows after.
In the end, if the user has to do anything besides live entirely inside a single application that's always running, Linux is NOT ready for the desktop. I mean, this should be obvious, just put them side by side. Mac OSX is the only viable desktop UNIX around, and Linux in my wet dreams isn't even close to that.
I'm all on board with the improvements in installation you've described, but that's...that's just not nearly enough to support your premise that given some usable apps, everyone could be running Linux on the desktop. I'm all for being a fan of Linux, but that's just too much to swallow.
Lay off the crack before posting, please. No Linux distro I've seen is anywhere near the ease of use of Microsoft products. Fine, installation may be easy, but you only do that once, then Grandma has to use the thing day in, day out. What apps there are generally suck in terms of usability; there're no desktop standards; etc., on and on. Please don't do a disservice to Linux by saying the work is already done in making it ready for the desktop--the work has barely begun.
You missed his point. Just as the personal data about ourselves should belong to us, Microsoft fundamentally believes that the music you listen to, the video you watch, and the software you run are not your data. They are other entities' data, who only grant you a limited license to use their data as they see fit.
Forget SpringWalker and these other technologies that aren't available yet--you can get a pair of PowerSkip boots today. These were posted on Slashdot last April 1st, and many people thought they were a joke; they aren't, and you can be out running around in them and jumping cars for around $800-1000.
You mean projectors? Yeah, absolutely. Some friends and I watched a couple movies on an InSync projector at work last night. The picture quality was stunning, far better than any TV I'd seen. It was even better than most movie theatres.
Apparently, at least InFocus is getting on board with marketing to consumers. Check out the InFocus ScreenPlay. Unfortunately, the home models are more expensive than some of the corporate models, but I'm hoping that volume and word of mouth will start to lower prices. At least these companies are finally realizing that they can market to the consumer.
Slashdot Mirror
The richness of a language's vocabulary is what lets its speakers express themselves in powerful ways distinct from what other language speakers can do. French has a number of terms and concepts that don't have direct translations in English, and in fact, a huge amount of common English vocabulary comes from French.
A programming language's libraries are equivalent to a natural language's vocabulary. And this is exactly where Java shines the most from an application development point of view. (It shines for other reasons on other fronts, like for embedded programming.)
Sure, you can go out and develop a C++ app without using pointers, but that's just one app. The next one probably will use pointers. Even if I become a C++ programmer and refuse to use pointers in all my applications, I will have to work with someone who does, or use a library that requires them (is there one that doesn't?). And, eventually, I'll have to maintain someone's code that uses pointers. In the end, there's no getting away from it. Java eliminates the vulnerability pointers represent unilaterally, for better or worse.And similarly, you can go grab a library for doing garbage collection, but which one? You have nearly infinite choices, and every app will make a different choice. It's exactly the consistency of features that make Java superior in this regard. And when I say superior, I mean cheaper, and not just in terms of money, but in terms of resources. The support engineer trying to fix a bug in a Java program won't have any questions about the subtleties of a garbage collection API he's never seen, nor wonder what's in this odd little pointer that seems to keep causing a production crash. These are real advantages, even if they are hard to quantify.
That's just the limit of your experience then. My experience is exactly the opposite. The advantage here is the fact that you maintain a single codebase--the same source files--for all platforms, and they do work as advertised minus any VM bugs (which are fairly rare compared to application bugs).Let me tell you a story. I used to work for one of the real success stories of the dot-com era. My company implemented different pieces of its product using Java and C++, and these pieces used CORBA to interoperate. As far as any one distributed object was concerned, the object on the other end could be any language; it was only a difference of implementation.
Anyway, the support and maintenance costs for the Java portion of the product were dramatically lower than for the C++ portions. They both used the same infrastructure, but one was cheaper and faster to develop in, easier to fix and enhance for the next version, easier to debug both in-house and in the field, and more stable to boot. Add to this the fact that you only had one copy of the source files for the Java portions, versus the several versions for all the different platforms we supported in C++. In the end, if you work on large, complex software systems, Java is vastly easier to maintain, and vastly cheaper to support. Ask any of the product engineers and they would say the same thing: Java is just more pleasant and productive to work in, and they prefer Java over C++. They all hated the C++ portions of the product, and regretted ever putting them in.
And, sadly, most programmers out there aren't that good. With C++, you give them a loaded weapon and tell them to be careful. As often as not, they inadvertantly shoot you or themselves. At least with Java, poor programmers have to load the gun before they can shoot anyone. Sorry for the extended analogy.
Ugh, so much to say here. The problem is that what you are suggesting is a myth; it does not represent the real world of enterprise application development. You don't know your platform, it is not a constant in the equation. You want to provide for all platforms if you're a software vendor. Once you can sell to one, using Java, you can sell to all others without any significant extra effort. Furthermore, bugs fixed in one version of your code are fixed in all versions--support costs go down dramatically.If you're a client, you may find that you are grossly unsatisified with vendor X's hardware/support/performance and want to switch to using a solution by vendor Y (and this happens all the time in the corporate environment). What do you do now? Just because you know things are changing doesn't make the cost of changing any less. However, the fact that you wrote your application in Java does make the cost less--it makes it nil, because the same code runs on HP, Solaris, Intel, Windows, Linux, MacOS, AS/400, etc. The ability to move code effortlessly between platforms allows you as a company to save costs if it makes sense to switch hardware platforms, or mix and match platforms.
Yes, but the application code your GUI fronts is also cross-platform. Not so with the others. And again, there's the benefit of the single binary versus a binary per platform. That's fine, but it really is. Try it. The limited complexity of the language lets programmers focus on the task at hand far more easily in my experience, and it's much easier to do OO in Java than in C++. This means all the benefits of OO are more easily achievable (and if you don't think OO is a good thing, don't bother talking to me.) If you can, great, but I haven't found that language yet. It might be Smalltalk, or Perl, or COBOL, but nothing so far has taken all the great ideas from all of these languages and made them so eminently useful and practical. For example, Smalltalk is probably the most elegant, most forward-thinking languages around (even today), with tons of powerful features. However, it doesn't have the network orientation that Java does, or the C/C++ like syntax that makes it easy for developers to learn. It doesn't have the ability to be pared down and run inside a DIMM-sized computer, or be as dynamic as Java.I'm not advocating Java over other languages if those languages are more suited to the job. I'm not going to write a device driver in Java. I'm suggesting that a task that can be equally accomplished in Java and some other language will be more maintainable, cost less to support, and completed more quickly, when written in Java. The real-world merits of Java are that it reduces resource costs for anyone using it, end of story.
Oh, and by the way, when I used to bill (I left the loser consulting lifestyle behind long ago), I billed $10,000/week for enterprise Java expertise. You do the long division.
Just brainstorming here, but what about making every Java class (or related group of classes) a shared library that can be dynamically loaded? Seems like you could fake class inheritance by using inter-library references and some infrastructure to fix-up the references dynamically. Polymorphism would be achieved by translating calls to "super" as calls to the "parent" library.
The point is, I can come in and maintain someone else's code with far less trouble if it's written in Java than I can if it's written in C++. Same goes for the support engineers. Same goes for customers. If it's written in C++, the application can essentially be a language unto itself. You have different mechanisms for just about any major feature between development teams; none of them are standard, and none of them are even remotely as easy to learn and use as the equivalent Java API. Maintaining these applications costs a huge amount, and is fraught with support issues exactly because there are so many incompatible ways of doing the same thing.
Your argument is so tired because it doesn't take into account the actual cost of developing real applications--maintenance and support.
Wrong: Those who say that Java is easier to program in (and who don't know C++) really don't want to learn the disadvantages of programming in C++.Well, I didn't know that, so thanks to the original poster for mentioning it. There's no need to rag on him/her for mentioning something "you and every single person *you* know" knows. It's a bigger world than your circle of friends.
Exactly, man, you grok.
Yeah, *with* their family. Unless your wife or SO is just as big a geek as you, these games tend to be solo affairs.
I'd much rather see things go the way Serious Sam has, releasing smaller "episodes" that are half the price of other games. I'd like to for once start a game and be able to finish it in a reasonable amount of time (20-30 hours), while the developer cranks out more expansion packs and improvements. It seems like this would be much better for developers too, as they could drastically reduce their time to market.
What you've suggested is that there is depreciation of the value of items coupled with inflation (meaning depreciation in the value of money). These are opposite trends, and are mutually exclusive. Why? Because item values are defined in terms of the value of money, and the value of money is defined in terms of what items it can buy. A change in one means an opposite change in the other. (Note, once you start stating the value of items in other terms, like how quickly an item helps a given character kill a monster, that's another matter entirely.)
This is like the well-known equivalence of mass and energy. They are the same thing, just different forms. In the same way, items and money are the same "thing" in terms of fungible value, just different forms. And, just as in physics, you must pay a price to change from one form to another. However, the shoe is on the other foot here--the seller pays the price instead of the buyer (by selling at a lower cost than the item cost initially).
What the author suggested was that items become cheaper over time because there is an influx of items of increasingly greater value over time. There is no similar influx of money into the world (AFAIK)--you must sell items to make money. If you could mine platinum to make money, then things would be different. What this all boils down to is that making money is predicated on finding items. Since the influx of value based on money into the world is small compared to the influx of value into the world based on items, there is a pressure on players to only spend within an absolute range of money for any item. In other words, you have a range of money valuation that ranges from 0 to X, and you have to fit increasingly more items within that range in a marketplace.
I believe all of this was exactly what the author described--if you keep a given amount of money, it increases in value in terms of items over time. Meaning, over time, you can buy more stuff for the same amount of money.
Again, it's another matter entirely if you start stating that a given amount of money buys an increasingly smaller amount of "badass-ness" for your character. This is thinking of item values in terms of their utility. And this is exactly how most characters think of items--that's where the fun of the game is to begin with. But, it's the switching between the two valuation models that confuses everyone I think.
You said, "The same ammount buys less". No. The same amount of currency today buys the same item for less money than yesterday. It only buys "less" if you are thinking in terms of what an item can do as its inherent value (meaning its suitability for a given character at a given level).
This isn't correct for an analysis of value of money versus item value *in terms of money*, but is an interesting idea. You are talking about the inflation that occurs based on the decrease in item value *in terms of utility*. It's interesting to wonder if this is an offsetting factor in the overall economy.
Although this would ostensibly create a realistic economy, it wouldn't be very fun to play relative to games that provide an easier road to riches. The fundamental aspect here is that people like struggle and challenge, but only to a certain point. After that point, unrelenting struggle becomes a source of unhappiness, and so much so that people will stop playing such a game.
The problem is that other than the minimal community aspects of these games, they don't (yet) provide the same sort of fulfillment we can get in the real world. Whether they ever will or not I suppose is up to debate, but so much of our Earthly happiness is based on fulfilling our base desires like eating, sleeping, and mating. It will be a long time, if ever, before a game can provide the same level of satisfaction these activities do. Until then, the hyper-reality aspects that cause deflation will likely remain a popular element of these games.
Furthemore, it's not clear how you sustain a realistic economy with the ability of everyone to have equal opportunities to become richer. This certainly isn't how the real world works, and the premise of equal opportuntiy stems exactly from the abiity to just go out and do what anyone else does to become rich. If you can go farm items from the same pack of biots that a richer person does, the only difference between you is in the length of time each one has been doing it. In the real world, the means of becoming rich are carved out and protected by the rich, meaning equality of opportunity goes out the window.
Great, installation is out of the way, but there's so much more to do, and it's beyond just a little tweaking here and there. Contrary to some opinions, the UNIX/Linux way of doing things is not easy compared to the Windows or Mac way of doing things. Despite the fact that these OS's and computers in general are unintuitive, Linux is definitely even less intuitive.
For example, how does improved installation address the mounting of a Zip drive or the addition of other hardware (all this after initial installation)? How does it help users manage files, or understand what a man page or a command line is, or any of those other things that Linux/UNIX users are comfortable with, but the average user isn't? How do you explain why the user shouldn't be logged in as root, or what the conventions of the UNIX filesystem are, or what they're for? How does a user install and configure the latest version of Quake to run with his badass new video card? I guarantee it's nowhere near as easy as running a Windows or Mac installer and just double-clicking the icon on the desktop.
I think you must be grossly overestimating the the sophistication of the average computer user to think that these sorts of things are below the level of user consciousness, and that any issues in these areas disappear because the user has usable apps. It's almost the opposite--these are the things that are foremost in user's minds, before they ever get into an app. The rest follows after.
In the end, if the user has to do anything besides live entirely inside a single application that's always running, Linux is NOT ready for the desktop. I mean, this should be obvious, just put them side by side. Mac OSX is the only viable desktop UNIX around, and Linux in my wet dreams isn't even close to that.
I'm all on board with the improvements in installation you've described, but that's...that's just not nearly enough to support your premise that given some usable apps, everyone could be running Linux on the desktop. I'm all for being a fan of Linux, but that's just too much to swallow.
Lay off the crack before posting, please. No Linux distro I've seen is anywhere near the ease of use of Microsoft products. Fine, installation may be easy, but you only do that once, then Grandma has to use the thing day in, day out. What apps there are generally suck in terms of usability; there're no desktop standards; etc., on and on. Please don't do a disservice to Linux by saying the work is already done in making it ready for the desktop--the work has barely begun.
You missed his point. Just as the personal data about ourselves should belong to us, Microsoft fundamentally believes that the music you listen to, the video you watch, and the software you run are not your data. They are other entities' data, who only grant you a limited license to use their data as they see fit.
Forget SpringWalker and these other technologies that aren't available yet--you can get a pair of PowerSkip boots today. These were posted on Slashdot last April 1st, and many people thought they were a joke; they aren't, and you can be out running around in them and jumping cars for around $800-1000.
I laughed my head off seeing that sig. It's nice to see some people on Slashdot aware of the other really good open source project. Cheers.
Apparently, at least InFocus is getting on board with marketing to consumers. Check out the InFocus ScreenPlay. Unfortunately, the home models are more expensive than some of the corporate models, but I'm hoping that volume and word of mouth will start to lower prices. At least these companies are finally realizing that they can market to the consumer.
Elbereth
Nope. Damn.