I clearly fouled up this post. I intended to say, "given this fine effort, application maintainers and contributors who think they would have something to offer, and know several languages... consider adding a major language to your app first."
I was NOT trying to belittle these fine people or their effort, just talking to app maintainers and contributors.
The simple, flame-war-free answer is that Sun could not bear the support burden of a C++ GUI toolkit and desktop system for a platform that had two major C++ compilers (Sun's and gcc). Now that the C++ ABI is more entrenched that might not be as much of an issue, but at the time it was a key factor.
Personally, I would have gone with Gnome for other reasons. The architecture is much more open in a component sense (e.g. smaller, replacable parts). Sun has also shown that human factors were huge concern to them, and KDE suffered from having been ahead of Gnome. Sun literally got to write the book on human factors for Gnome, and that ended a LOT of debate before it got started.
I like the way Gnome has shaped up. It started with a lot of catch-up to do with respect to KDE, which was already functional when Gnome was first started. But over the years I have seen that gap narrow tremendously, and I like the Gnome code a great deal more.
Still, both are worthy of praise and use... may we have two of the three best desktops in the world for a good long time to come!
I don't have a problem with Farsi or advocacy. I was just pointing out that maintainers should FIRST work on implementing the major languages. For large systems like core KDE or Gnome, that's not a worry, but satellite projects can sometimes be tempted to work on "fad features" and that often hurts the application.
If your project supports Arabic, English, Hindi, Chinese and at least one European language other than English, then I would say go for it, but that's not usually the case for small projects.
That said, there is one language which I have heard a reasonable argument for doing which had almost no practical value... Klingon. This is a constructed language with very simple rules, so if you are looking for a first language to test your application's localization on, Klingon can be a good choice.
Will open source projects ignore this and implement obscure languages anyway? Sure, but hopefully I've made a couple of maintainers think about their priorities... after all, don't you WANT lots of people to use your software?
Ports to languages like Farsi are interesting, but maintainers of applications really need to focus on Arabic, Hindi, whatever the primary Chinese used for computers is, Spanish and English. If your application ships with these languages, you cover your bases VERY nicely. Let localized distributions help you out on the smaller languages (*cough*klingon*cough*).
Don't get me wrong, I applaud these people for their work, but package maintainers can easily get caught up in a sort of fad around certain translations, and sometimes that hurts if the biggest languages are not covered well.
On another front, Gnome also supports right-to-left languages, so don't feel you have to chose KDE... choose whichever supports your needs best from an application standpoint.
If you think that, in 2 years you can write a VM that satisfies all of the lanugages that Parrot targets, have at it... I'll use yours if it really is better than Parrot.
It's a HUGE job, and realistically, if they do it right, one that can never truly be done (because new models of language design require growth and adaptation). I'm just glad that someone is doing it.
Too bad they pissed away $180,000 in Perl Foundation money and have nothing to show for it
Your points fall apart into baseless attacks here. Go back and look at what Parrot DOES have to show... I've only written a little Parrot code, but it has worked very well for my attempts to code some Perl primatives and for my work with the Python front-end (which is still fairly primative).
This is hard work, and I encourage you to help if you feel it's too slow.
That definition falls down in the face of most modern high level languages, and most older ones. All LISPs have an eval... how does that play in? Perl compiles to an intermediate representation, optimizes, then executes... that certainly does not match the model of a scripting language like Bash or VMS's shell.
When I hear "scripting language", I think of the batch file systems of yore, and recall what real scripting was. Languages like Ruby, Perl, Python and O'Caml are Very High Level Languages (VHLL), and not scripting languages.
Java and C# are statically typed languages, designed to allow type-safe, efficient separate compilation. Python is a dynamically typed language with a flexible but inefficient object model. Sometimes, the distinctions between scripting and non-scripting programming languages are blurry, but in the case of Java and Python, there is little question which is which.
Most of your list of comparisons are correct. The rest are conclusions based on perspective (e.g. efficient vs. inefficient, which are subjective terms that you clearly have some notions about in this case). I'll grant that those are somewhat fair comparisons. However, you again try to shoehorn in the word "scripting". This is a semantically null word which you seem to think means "lesser".
The more apt term (and one that has been in use for quite some time) is very high level language (VHLL). A VHLL will tend to be one which abstracts hardware features, usually at the cost of performance, in order to simplify large programming tasks.
That may have been true for the PDP-11 and K&R C, it is wrong for modern machines and ANSI C: ANSI C semantics and machine semantics have become very different.
Not really, no. The x86 platform continues to be "your father's CMOS" emulated on top of increasingly more sophisticated designs, and other platforms don't really offer a substantially different programming model (architecture, and execution YES, but those are different things). Such changes as in-core parallelism, speculative execution and virtual register banks don't really have to impact how you think about the hardware. ANSI C really didn't change the language's standing with respect to hardware. ANSI C is no higher level than K&R... the largest changes were in fact around the prototyping and pre-processing models. Certainly ANSI C's impact was mostly in the full definition of a standard C library....
Parrot is designed for the execution of dynamically typed code with a highly dynamic object model
Not really, no. You start thete, and then move down to a level that suits your needs. Perl 5 for example will not need to move beyond what you describe, but Java most certainly will, as will C#, both languages that the Parrot developers are keeping the platform open to.
Parrot seems to have no features to indicate properties like absence of aliasing, vectorization, detailed control of floating point computations, or value classes
Some of these things are there (perhaps to your satisfaction, perhaps not), but again let me stress, that Parrot is an attempt to create an inclusive VM. If these features are needed for such a goal, then they will be added as they are needed. Perhaps you would like to help?
Wow, that's a lot of venom for so little fact... Let's disarm a bit of that:
Threading in parrot is still being worked out, but I think what you are looking at is the model being used by the Perl 5 project (currently Parrots biggest customer, along with Perl 6) and assuming that that model is "Parrot's" rather than "Perl's". Perl 5 NEEDS that threading model in order to have the same threading semantics on Parrot as it did stand-alone. Other languages will use threading differently, and Parrot will need to support those models.
Your definition of a "scripting" language is moot. Java is no more or less a "scripting" language than Python. C# no more or less than Ruby. There are several things that make a language what it is:
* basic calculation capabilities (turing completeness) * how code is dealt with (or not) at runtime (eval, closures, code as data, etc.) * support for programming models (e.g. OO features) * syntax and grammar * level of semantic complexity * level of hardware abstraction
Modern high-level languages offer a certain take on these features. Perl, for example offers most of the above features with maximal semantic complexity and hardware abstraction. LISP on the other hand offers most of thse features as well, while remaining semantically very regular and simple. Java lies somewhere in between, but its support for features like treating code as data are strictly limited by design.
These are choices, and there is nothing wrong with any of them. To introduce "scripting" as a pejorative term is meaningless. Ultimately scripting refers to the wrote execution of a set of primative commands. In a sense any language with logic structures can be said to have gone beyond this primative stage of "language" design. Also by that same logic you could say that EVERY language meets these criteria. After all, hardware instructions are just primative commands which your program executes in a predictable way.
Lets talk about real language features, not this psuedo-distinction which is used to dismiss languages with more peasant roots than those you might prefer.
You also bring up C... lest we forget, C is one of the thinnest layers on top of assembly that you can create. Making a byte-code interpreter that doesn't slow down your average C code is called "writing a compiler". Your bytecode would have to be something like GCC's RTL, and that would not give you the abstraction that makes VMs valuable in the first place. C is the language you use when you want to write machine code, but you need to remain fairly portable. No C#, Java or other VM will be able to aproach the efficiency of hand-coding in C until the compiler is able to understand the code well enough to have written it in the first place. That does not make the goal of a high-performance VM moot, it simply sets the upper bound for the limit function.
I really hope the author's smiley was to indicate that he understood that his string of buzzwords was meaningless.
What I hope is that Sun takes a good, long look at the only intermediate assembly that has been designed with language neutrality in mind, Parrot. While this article is over 2 years old, it's a decent starting point. Parrot has already been used to implement rudimentary versions of Perl 5, Perl 6, Python, Java, Scheme and a number of other languages. The proof of concept is done, and Sun could start with a wonderfully advanced next generation byte code language if they can avoid dismissing Parrot as, "a Perl thing" with their usual distain for things "not of Sun".... IBM on the other hand is usally more open to good ideas.
"Whether you "think" there is global warming or not"
Very little real debate takes place on that ground. Generally the questions are:
1. Is global temperature impacted by humans in a substantial way.
2. How does the current period of warming compare to previous (often more severe) periods in the past.
3. Given that all human attempts to reduce (for example) carbon monoxide and carbon dioxide emmisions would be for naught in the face of ONE large volcanic erruption, what changes could we make that might have a positive effect?
"is there global warming" is a naive question that even the author in question points out is NOT up for debate in his opinion.
He further goes on to address cost and benefit. I agree with his statement that money could be better spent, though I challenge him to separate costs when he addressess such topics. "Costs" in terms if reduced revenues should not be calculated into such an equation. Instead, only costs directly associated with complying with a treaty such as Kyoto should be counted. I doubt that would be enough to bring clean water to everyone, but it would be a lovely start!
"I recall criticisms by authors cited by Lomborg, who say that their work fails to support (or even contradicts) Lomborg's conclusions. To the extent that Lomborg claims their support, they say it is from sections taken out of context. This is hardly the work of an honest academic."
This is a common reaction, and not as much of a problem as you might think. If the man cites data from a valid source, I'll accept it. Conclusions have a context (and we must skeptically evaluate conclusions without bias). Data does not. People are often mad when their data is used to support conclusions with which they do not agee... too bad.
"[... that there is an impending disaster] proves that his "don't worry, be happy" conclusion is bunk."
No, it proves that there is an impending disaster, and one which should be evaluated for possible action.
Let's look at global warming just as an example. There is a wide spectrum of warming activism. On one end you have the folks who would say, "Global warming is a fact; we must act; SUVs should be taken off the roads!" These people are wrong, but that's not terribly surprising, after all they are reactionary extremists. On the other end of the spectrum you have the people who would say, "Global warming is a myth; we must not act; environmentalists are a menace!" Guess what -- yep, wrong too.
So, what is correct? I have no clue, and one of Lomborg's points in his response is that he doesn't either. All anyone can be sure of is that the people who tell you they have all the answers are full of it.
The problem is that of validation and miscommication for the most part. For example, when warming activists are told they are wrong, they run to their thermostats and point, saying that it's warm out! What they often miss is that it was very warm out 1500 years ago when a period of global warming destroyed countless species and wiped out at least one culture. What many scientists have come to question is not, "is it hot", but "why is it hot?" The answer to that MUST start with a better understanding of the sun and how it impacts our climate. For example, this year we have seen the most activity ever recorded on the surface of the sun. If it is abnormally warm next year, we should begin with a simple question, "how does last year's solar activity play into this?"
While there are many theories, interestingly none of them has been proven to the satisfaction if the majority of the community. Hmm... big ball of fusing plasma 8 light minutes away, and we blame SUVs for climate phenomena that have occured before, prior to the advent of the SUV.... interesting.
I don't always agree with Lomborg, but SciAm (which has, IMHO, become a rag in the last 10 years) did its readers a disservice by trying so hard to discredit him, rather than to address the concerns he brings up.
Fair use doesn't "say" anything, it's a set of extrapolations, precidents and doctrins spread out from the Magna Carta to the U.S. Constitution to modern day case law... or am I missing something there too?
The whole idea of five seconds, as I understood it, was that using something as small as five seconds made it so difficult to prove harm to the original copyright that you could find plenty of precident in your favor. That is, anyway, as I understood it.
A shorthand way of saying that is, "it's fair use." But, perhaps I should have said, "it is defensible as fair use."
I'm no pro, I'm stating MY understanding, but feel free to explain how this is not the case.
Most of your points on MySQL are out of date. Its featureset has progressed a great deal since, apparently, you last looked into it. Even way back when this was a hot topic (when PostgreSQL, another excellent open source DB, was an up-and-comer), MySQL developers were already saying that most of people's concerns were being addressed in upcoming releasesd... Those releases have since come and gone (mostly in the form of 4.0, though IMHO, 4.1 is MySQL's finest moment, and its current release status as alpha is kind of funny given that it's been rock stable for a year).
Just off the top of my head, you mention ACID. MySQL now offers a choice of back-end table managers that range from the original fast, but strictly non-ACID version to Berkely DB (which is fairly fast and supports transactions, but I think falls short of ACID in terms of rollback) and the fully ACID InnoDB, which is the (now open source) back end from the Progress database.
So take your pick, depending on your app. Do you want speed? Transactions? Full ACID? Better yet, you can make that choice on a table-by-table basis!
MySQL also has the best full-text-searching features I've seen in any DB, open or closed.
There are limitations, and I might choose another DB for certain specific tasks (e.g. Oracle for statisics in the DB) but MySQL is a great first choice for most projects.
Actually, I think the major reason this would be supported is that it will take more of a dent out of priated videos then it will out of theater tickets. You're right, it probably won't be a huge hit, but then I would expect other moves to attack piracy at the same time (roughly in the same way that Anime was cracked down on in the mid 90s).
Every major game takes out ads in trade rags. I was comparing overall marketing. I think you will find that EQ gets far less marketing than "emerging" games. The point I was making was that EQ does not survive because it is marketed, it survives because there are litteraly hundreds of thousands of players who keep eachother playing and bring in new people.
In order for a new game to work, they will have to look past first-week box sales and find ways to get active players to evangelize, while honestly enjoying the game.
"It's not the graphics (most long-term EQ players turn off all the bells and whistles they can); "
The reason that most long-term EQ players do this is because they only get one frame per second if they leave them on.
That is exactly the case. What is more, I have never seen a game with as realistic a modeling system as EQ has for which this is not the case. Mind you, we're not talking about standing by yourself in the middle of an empty zone, we're talking about high-end raiding (EQ more than keeps up even with all options on when you are alone). An average high-end raiding guild these days is probably around 50-60 people, and 70-80 is even required in some places. Imagine Quake with 80 combatants and another 20-100 non-player creatures wandering around, and you begin to see why serious EQ gamers look for the off switch on graphics options... If I could have a text-only interface that gave me all of the information I needed, I'd be all over it.
DAoC actually has a nice soution to this, which is kind of a Gordion Knot sort of approach. They don't have nearly as realistic a rendering system, but their graphics are very nicely done, and effectively cover up a lot of the shortcomings of their rendering. I like this approach, as it seems to be a fair middle ground. I just wish SOE would standardize their protocol and open up licensing rights for other companies go write UIs. But, doing that would require acknowledging that the UI is not a key element of their product's value, and I have yet to see a company realize that that dynamic shift is occuring in the video game space....
Good point, and one of the key lessons of the MMOG age will be that a small user community does NOT mean a dead game, I guess you could generalize my statement to the idea that EQ has been fairly static in terms of player base, and while the market wisdom says that means its dead, the market wisdom does not apply to games that represent an ongoing revenue source.
Heh. First off, my cow is not sacred. I don't want EQ to be the most popular MMORPG. Personally, I think a good modern-day war simulation would be better. I also think Sony is being very, very stupid for not offering the opportunity for people to run businesses inside the game. The day will come when there are more businesses and larger economies in these games than outside. Once that happens and the exchange rates between the two worlds are stabalized enough.... Well, what IS the reason commuting to work makes sense for the average white-collar worker?
Calling EverQuest addictive is a cheap cop-out. I've been playing for four years and would have stopped leveling long ago, in fact stopped playing entirely, were it not for the community. The hampster food pellets called "levels" are poorly designed as incentive. What's more SWG does the pellet thing better (more options to refine your character).
No, as someone here on Slashdot once said, the numbers game hooks you at first, because that is ultimately what drives human beings to achieve. However, the networks of friends and acquaintences, even rivalries are what keep you playing after the first couple of months when the honeymoon is over (around when I stopped playing every other video game I have ever tried, even though it may have had a better numbers game like Starcraft or Myth).
The game that truly replaces EQ will have to do so because it respects the community. We're savvy enough now to realize that dedication to customer service counts (expensive, most games try to work around this); range of content counts (original EQ had more content than any other new MMOG I've seen, and it has more than quadupled); and most of all, you have to sell it to the kinds of people who don't want snazzy graphics, but instead want to bring in 30 of their best friends and lock heads with a skilled encounter-smith.... this last one is where EQ has lost its edge, and NO ONE seems to be capitalizing on it!
WoW and Sigil are the games to watch, but I'm not holding my breath... I think it will be another 5-10 years before someone unseats EQ.
Slashdot Mirror
I clearly fouled up this post. I intended to say, "given this fine effort, application maintainers and contributors who think they would have something to offer, and know several languages... consider adding a major language to your app first."
I was NOT trying to belittle these fine people or their effort, just talking to app maintainers and contributors.
The simple, flame-war-free answer is that Sun could not bear the support burden of a C++ GUI toolkit and desktop system for a platform that had two major C++ compilers (Sun's and gcc). Now that the C++ ABI is more entrenched that might not be as much of an issue, but at the time it was a key factor.
Personally, I would have gone with Gnome for other reasons. The architecture is much more open in a component sense (e.g. smaller, replacable parts). Sun has also shown that human factors were huge concern to them, and KDE suffered from having been ahead of Gnome. Sun literally got to write the book on human factors for Gnome, and that ended a LOT of debate before it got started.
I like the way Gnome has shaped up. It started with a lot of catch-up to do with respect to KDE, which was already functional when Gnome was first started. But over the years I have seen that gap narrow tremendously, and I like the Gnome code a great deal more.
Still, both are worthy of praise and use... may we have two of the three best desktops in the world for a good long time to come!
Good, solid points... and much more defensible than most.
Like I said, this is a great project, and I am thrilled... I have no problem with ANY team that decides to do a localization.
My comments were just to app maintainers who may read Slashdot.
I don't have a problem with Farsi or advocacy. I was just pointing out that maintainers should FIRST work on implementing the major languages. For large systems like core KDE or Gnome, that's not a worry, but satellite projects can sometimes be tempted to work on "fad features" and that often hurts the application.
If your project supports Arabic, English, Hindi, Chinese and at least one European language other than English, then I would say go for it, but that's not usually the case for small projects.
That said, there is one language which I have heard a reasonable argument for doing which had almost no practical value... Klingon. This is a constructed language with very simple rules, so if you are looking for a first language to test your application's localization on, Klingon can be a good choice.
Will open source projects ignore this and implement obscure languages anyway? Sure, but hopefully I've made a couple of maintainers think about their priorities... after all, don't you WANT lots of people to use your software?
Ports to languages like Farsi are interesting, but maintainers of applications really need to focus on Arabic, Hindi, whatever the primary Chinese used for computers is, Spanish and English. If your application ships with these languages, you cover your bases VERY nicely. Let localized distributions help you out on the smaller languages (*cough*klingon*cough*).
Don't get me wrong, I applaud these people for their work, but package maintainers can easily get caught up in a sort of fad around certain translations, and sometimes that hurts if the biggest languages are not covered well.
On another front, Gnome also supports right-to-left languages, so don't feel you have to chose KDE... choose whichever supports your needs best from an application standpoint.
Measuring pollution in humans? Bad idea. I mean, imagine the confusion, "so bob, how's the weather today?"
"Well, it's not good. Three, maybe four humans and there's no wind to blow them out to sea."
"You sick, sick man...."
Thanks for the great examples. Glad to see someone who knows the field better than I do is paying attention and keeping me honest!
It's a HUGE job, and realistically, if they do it right, one that can never truly be done (because new models of language design require growth and adaptation). I'm just glad that someone is doing it.
Your points fall apart into baseless attacks here. Go back and look at what Parrot DOES have to show... I've only written a little Parrot code, but it has worked very well for my attempts to code some Perl primatives and for my work with the Python front-end (which is still fairly primative).
This is hard work, and I encourage you to help if you feel it's too slow.
That definition falls down in the face of most modern high level languages, and most older ones. All LISPs have an eval... how does that play in? Perl compiles to an intermediate representation, optimizes, then executes... that certainly does not match the model of a scripting language like Bash or VMS's shell.
When I hear "scripting language", I think of the batch file systems of yore, and recall what real scripting was. Languages like Ruby, Perl, Python and O'Caml are Very High Level Languages (VHLL), and not scripting languages.
The more apt term (and one that has been in use for quite some time) is very high level language (VHLL). A VHLL will tend to be one which abstracts hardware features, usually at the cost of performance, in order to simplify large programming tasks.
Not really, no. The x86 platform continues to be "your father's CMOS" emulated on top of increasingly more sophisticated designs, and other platforms don't really offer a substantially different programming model (architecture, and execution YES, but those are different things). Such changes as in-core parallelism, speculative execution and virtual register banks don't really have to impact how you think about the hardware. ANSI C really didn't change the language's standing with respect to hardware. ANSI C is no higher level than K&R... the largest changes were in fact around the prototyping and pre-processing models. Certainly ANSI C's impact was mostly in the full definition of a standard C library....
Not really, no. You start thete, and then move down to a level that suits your needs. Perl 5 for example will not need to move beyond what you describe, but Java most certainly will, as will C#, both languages that the Parrot developers are keeping the platform open to.
Some of these things are there (perhaps to your satisfaction, perhaps not), but again let me stress, that Parrot is an attempt to create an inclusive VM. If these features are needed for such a goal, then they will be added as they are needed. Perhaps you would like to help?
Wow, that's a lot of venom for so little fact... Let's disarm a bit of that:
Threading in parrot is still being worked out, but I think what you are looking at is the model being used by the Perl 5 project (currently Parrots biggest customer, along with Perl 6) and assuming that that model is "Parrot's" rather than "Perl's". Perl 5 NEEDS that threading model in order to have the same threading semantics on Parrot as it did stand-alone. Other languages will use threading differently, and Parrot will need to support those models.
Your definition of a "scripting" language is moot. Java is no more or less a "scripting" language than Python. C# no more or less than Ruby. There are several things that make a language what it is:
* basic calculation capabilities (turing completeness)
* how code is dealt with (or not) at runtime (eval, closures, code as data, etc.)
* support for programming models (e.g. OO features)
* syntax and grammar
* level of semantic complexity
* level of hardware abstraction
Modern high-level languages offer a certain take on these features. Perl, for example offers most of the above features with maximal semantic complexity and hardware abstraction. LISP on the other hand offers most of thse features as well, while remaining semantically very regular and simple. Java lies somewhere in between, but its support for features like treating code as data are strictly limited by design.
These are choices, and there is nothing wrong with any of them. To introduce "scripting" as a pejorative term is meaningless. Ultimately scripting refers to the wrote execution of a set of primative commands. In a sense any language with logic structures can be said to have gone beyond this primative stage of "language" design. Also by that same logic you could say that EVERY language meets these criteria. After all, hardware instructions are just primative commands which your program executes in a predictable way.
Lets talk about real language features, not this psuedo-distinction which is used to dismiss languages with more peasant roots than those you might prefer.
You also bring up C... lest we forget, C is one of the thinnest layers on top of assembly that you
can create. Making a byte-code interpreter that doesn't slow down your average C code is called "writing a compiler". Your bytecode would have to be something like GCC's RTL, and that would not give you the abstraction that makes VMs valuable in the first place. C is the language you use when you want to write machine code, but you need to remain fairly portable. No C#, Java or other VM will be able to aproach the efficiency of hand-coding in C until the compiler is able to understand the code well enough to have written it in the first place. That does not make the goal of a high-performance VM moot, it simply sets the upper bound for the limit function.
I really hope the author's smiley was to indicate that he understood that his string of buzzwords was meaningless.
What I hope is that Sun takes a good, long look at the only intermediate assembly that has been designed with language neutrality in mind, Parrot. While this article is over 2 years old, it's a decent starting point. Parrot has already been used to implement rudimentary versions of Perl 5, Perl 6, Python, Java, Scheme and a number of other languages. The proof of concept is done, and Sun could start with a wonderfully advanced next generation byte code language if they can avoid dismissing Parrot as, "a Perl thing" with their usual distain for things "not of Sun".... IBM on the other hand is usally more open to good ideas.
"Whether you "think" there is global warming or not"
Very little real debate takes place on that ground. Generally the questions are:
1. Is global temperature impacted by humans in a substantial way.
2. How does the current period of warming compare to previous (often more severe) periods in the past.
3. Given that all human attempts to reduce (for example) carbon monoxide and carbon dioxide emmisions would be for naught in the face of ONE large volcanic erruption, what changes could we make that might have a positive effect?
"is there global warming" is a naive question that even the author in question points out is NOT up for debate in his opinion.
He further goes on to address cost and benefit. I agree with his statement that money could be better spent, though I challenge him to separate costs when he addressess such topics. "Costs" in terms if reduced revenues should not be calculated into such an equation. Instead, only costs directly associated with complying with a treaty such as Kyoto should be counted. I doubt that would be enough to bring clean water to everyone, but it would be a lovely start!
"I recall criticisms by authors cited by Lomborg, who say that their work fails to support (or even contradicts) Lomborg's conclusions. To the extent that Lomborg claims their support, they say it is from sections taken out of context. This is hardly the work of an honest academic."
This is a common reaction, and not as much of a problem as you might think. If the man cites data from a valid source, I'll accept it. Conclusions have a context (and we must skeptically evaluate conclusions without bias). Data does not. People are often mad when their data is used to support conclusions with which they do not agee... too bad.
"[... that there is an impending disaster] proves that his "don't worry, be happy" conclusion is bunk."
No, it proves that there is an impending disaster, and one which should be evaluated for possible action.
Let's look at global warming just as an example. There is a wide spectrum of warming activism. On one end you have the folks who would say, "Global warming is a fact; we must act; SUVs should be taken off the roads!" These people are wrong, but that's not terribly surprising, after all they are reactionary extremists. On the other end of the spectrum you have the people who would say, "Global warming is a myth; we must not act; environmentalists are a menace!" Guess what -- yep, wrong too.
So, what is correct? I have no clue, and one of Lomborg's points in his response is that he doesn't either. All anyone can be sure of is that the people who tell you they have all the answers are full of it.
The problem is that of validation and miscommication for the most part. For example, when warming activists are told they are wrong, they run to their thermostats and point, saying that it's warm out! What they often miss is that it was very warm out 1500 years ago when a period of global warming destroyed countless species and wiped out at least one culture. What many scientists have come to question is not, "is it hot", but "why is it hot?" The answer to that MUST start with a better understanding of the sun and how it impacts our climate. For example, this year we have seen the most activity ever recorded on the surface of the sun. If it is abnormally warm next year, we should begin with a simple question, "how does last year's solar activity play into this?"
While there are many theories, interestingly none of them has been proven to the satisfaction if the majority of the community. Hmm... big ball of fusing plasma 8 light minutes away, and we blame SUVs for climate phenomena that have occured before, prior to the advent of the SUV.... interesting.
I don't always agree with Lomborg, but SciAm (which has, IMHO, become a rag in the last 10 years) did its readers a disservice by trying so hard to discredit him, rather than to address the concerns he brings up.
Fair use doesn't "say" anything, it's a set of extrapolations, precidents and doctrins spread out from the Magna Carta to the U.S. Constitution to modern day case law... or am I missing something there too?
The whole idea of five seconds, as I understood it, was that using something as small as five seconds made it so difficult to prove harm to the original copyright that you could find plenty of precident in your favor. That is, anyway, as I understood it.
A shorthand way of saying that is, "it's fair use." But, perhaps I should have said, "it is defensible as fair use."
I'm no pro, I'm stating MY understanding, but feel free to explain how this is not the case.
Most of your points on MySQL are out of date. Its featureset has progressed a great deal since, apparently, you last looked into it. Even way back when this was a hot topic (when PostgreSQL, another excellent open source DB, was an up-and-comer), MySQL developers were already saying that most of people's concerns were being addressed in upcoming releasesd... Those releases have since come and gone (mostly in the form of 4.0, though IMHO, 4.1 is MySQL's finest moment, and its current release status as alpha is kind of funny given that it's been rock stable for a year).
Just off the top of my head, you mention ACID. MySQL now offers a choice of back-end table managers that range from the original fast, but strictly non-ACID version to Berkely DB (which is fairly fast and supports transactions, but I think falls short of ACID in terms of rollback) and the fully ACID InnoDB, which is the (now open source) back end from the Progress database.
So take your pick, depending on your app. Do you want speed? Transactions? Full ACID? Better yet, you can make that choice on a table-by-table basis!
MySQL also has the best full-text-searching features I've seen in any DB, open or closed.
There are limitations, and I might choose another DB for certain specific tasks (e.g. Oracle for statisics in the DB) but MySQL is a great first choice for most projects.
Actually, I think the major reason this would be supported is that it will take more of a dent out of priated videos then it will out of theater tickets. You're right, it probably won't be a huge hit, but then I would expect other moves to attack piracy at the same time (roughly in the same way that Anime was cracked down on in the mid 90s).
This confuses me. I thought it was considered fair use unless you used more than 5 seconds or so of sound....
Wow, that explains why this didn't ring any bells for me. I never saw the new version of empire, only the original.
Every major game takes out ads in trade rags. I was comparing overall marketing. I think you will find that EQ gets far less marketing than "emerging" games. The point I was making was that EQ does not survive because it is marketed, it survives because there are litteraly hundreds of thousands of players who keep eachother playing and bring in new people.
In order for a new game to work, they will have to look past first-week box sales and find ways to get active players to evangelize, while honestly enjoying the game.
That is exactly the case. What is more, I have never seen a game with as realistic a modeling system as EQ has for which this is not the case. Mind you, we're not talking about standing by yourself in the middle of an empty zone, we're talking about high-end raiding (EQ more than keeps up even with all options on when you are alone). An average high-end raiding guild these days is probably around 50-60 people, and 70-80 is even required in some places. Imagine Quake with 80 combatants and another 20-100 non-player creatures wandering around, and you begin to see why serious EQ gamers look for the off switch on graphics options... If I could have a text-only interface that gave me all of the information I needed, I'd be all over it.
DAoC actually has a nice soution to this, which is kind of a Gordion Knot sort of approach. They don't have nearly as realistic a rendering system, but their graphics are very nicely done, and effectively cover up a lot of the shortcomings of their rendering. I like this approach, as it seems to be a fair middle ground. I just wish SOE would standardize their protocol and open up licensing rights for other companies go write UIs. But, doing that would require acknowledging that the UI is not a key element of their product's value, and I have yet to see a company realize that that dynamic shift is occuring in the video game space....
Good point, and one of the key lessons of the MMOG age will be that a small user community does NOT mean a dead game, I guess you could generalize my statement to the idea that EQ has been fairly static in terms of player base, and while the market wisdom says that means its dead, the market wisdom does not apply to games that represent an ongoing revenue source.
Heh. First off, my cow is not sacred. I don't want EQ to be the most popular MMORPG. Personally, I think a good modern-day war simulation would be better. I also think Sony is being very, very stupid for not offering the opportunity for people to run businesses inside the game. The day will come when there are more businesses and larger economies in these games than outside. Once that happens and the exchange rates between the two worlds are stabalized enough.... Well, what IS the reason commuting to work makes sense for the average white-collar worker?
EQ looks like a video game, but does it have to?
Calling EverQuest addictive is a cheap cop-out. I've been playing for four years and would have stopped leveling long ago, in fact stopped playing entirely, were it not for the community. The hampster food pellets called "levels" are poorly designed as incentive. What's more SWG does the pellet thing better (more options to refine your character).
No, as someone here on Slashdot once said, the numbers game hooks you at first, because that is ultimately what drives human beings to achieve. However, the networks of friends and acquaintences, even rivalries are what keep you playing after the first couple of months when the honeymoon is over (around when I stopped playing every other video game I have ever tried, even though it may have had a better numbers game like Starcraft or Myth).
The game that truly replaces EQ will have to do so because it respects the community. We're savvy enough now to realize that dedication to customer service counts (expensive, most games try to work around this); range of content counts (original EQ had more content than any other new MMOG I've seen, and it has more than quadupled); and most of all, you have to sell it to the kinds of people who don't want snazzy graphics, but instead want to bring in 30 of their best friends and lock heads with a skilled encounter-smith.... this last one is where EQ has lost its edge, and NO ONE seems to be capitalizing on it!
WoW and Sigil are the games to watch, but I'm not holding my breath... I think it will be another 5-10 years before someone unseats EQ.