If you are not an expert but would like more understanding on this topic, then I'd recommend Steven Pinker's, The Language Instinct.

http://www.amazon.com/Language-Instinct-How-Mind-Creates/dp/0060976519

One of his books discusses a series of experiments where babies were shown to be able to understand all phonemes but by the age of six-months only the phonemes of the parent's language are available. They did experiments with both adults and babies.

Also, Pinker talks about a group of people with no history that linguists have posited to once exist based upon common roots in modern languages that trace back to a period in history and then stop. Kind of a missing language link of people if you will. Not sure how that fits in here.

You all seem to be missing Greg's point. Greg was claiming that "We've got a lot of players into raiding now."

Maybe what I should have countered with was "prove it".

Link the RAID achievements vs. the number of level 80s and show us that level 80s who play on average 10 hours a week have lots of raid achievements.

"You can "know the fights" by looking them up on wowpedia.org or youtube. Or tankspot. Or bosskillers. Or a half dozen other sites."

"I want to raid but I'm not sure how," or "It's too hard." "

Your statement is directly at odds with Greg's.

Here's how hard it is for me to use video.

1.) As tank I've had to use ALL of the sites you've listed to "know how." No one site works.
2.) Many of the videos are out of date.
3.) Videos are for a class you are not playing. Good luck trying to tank a fight as a warrior when the video is paladin.
4.) Videos have characters far better geared.
5.) Most of the videos have the UI so tweaked and custom rigged it makes them difficult to understand and they require watching repeated times.

So I disagree with him saying that users don't feel the "know how is hard". It is hard, especially for tanks.

And I'm still surprised at how many players do not have Deadly Boss Mod set.

If a player has to spend 30 minutes to an hour scouring the web to "know how", maybe it has been two months since that raid, then this directly contradicts Greg's statement that "I want to raid but I'm not sure how," or "It's too hard."

Why do you think the tank ratio is so low? Because it's too hard.

". Average gearscore is about 5.3k."

I'm curious as to how you got this number?

"Greg Street: We've got a lot of players into raiding now. I don't encounter too many players these days who say, "I want to raid but I'm not sure how," or "It's too hard." "

Seriously? You can't even get into an Ice Crown raid unless your gear score is 5K and most people are going to want you to already know the fights.

If by "raiding" he means the Dungeon Tool, he's probably right there, but other than that forget it.

It is nigh impossible to reasonably PUG a raid.

Howard's Mom, 'Howard, I'm going to the store. Which peas should I get to go with the brisket!"

Howard, "Not NOW Mom! I'm BUSY!"

Howard's, Mom, "Just what's so IMPORTANT Mr. Smarty Pants that you have to spend all day playing video games in your room. Should you be in school?"

Howard, "I'm NOT in School Ma!, I work at the University, and for your information I'm not playing games, I conducting very delicate research on the latest robotic technology. Now will you PLEASE leave me alone!"

Bolivia is one of the poorest country in the worlds with a recent history of mineral and oil resources, politics, and how little of the money provides economic wealth to the people of Bolivia. Instead Bolivia has children under the age of 11 going into mines because of their size.

http://www.greenleft.org.au/node/44181

Bassey is from Nigeria. Both Bolivia, whose radical government hosted the conference, and Nigeria are poor countries that have suffered from the curse of having carbon resources extracted by Western multinationals at the cost of terrible environmental destruction and social dislocation. At Cochabamba, Bolivia's President Evo Morales, said the profit-driven extraction of resources had to end if the world was to avoid catastrophic climate change. For that to happen, the private ownership of resources had to end -- and capitalism with it. This is a hard path for carbon-resource-dependent Third World countries like Bolivia and Nigeria, but is far easier for a rich, developed country like Australia. And the best way to manage the transition away from environmentally destructive mining is for the industry to be in public hands.

Well said.

"All in all it may be best not even to worry about things like video games as we can be certain that the run away cause of all crime comes back to drugs. Get rid of drugs and 90% or more of all crime will vanish."

While I'd choose a different oversimplification, historically poverty has a higher correlation to crime than does drugs, still your intuition is dead on. This is identical in spirit to Amdhal's law of optimization where optimizing 90% of only 1% of a performance problem is still only optimizing 0.9%, not 90%. Which can be more simply stated as "make the common case fast."

Expanding on your discussion then, today when a person has allergies or medical dispensations of a drastic order they wear bracelets proclaiming said characteristic to aid medical treatment. Should people who are known to have bad reactions to "blank" be encouraged or required to publicly proclaim them? We have decided this is the case with convicted pedophiles, and yet not other criminal tendencies? Pedophilia is considered some kind of uncurable, genetic-like defect but other criminal behavior is not? Why not? Like you say, Society has not handled this well. We have moved beyond the moral notion that "if you do the crime, you do the time" to a new notion that "if you do a crime behavior, forever that behavior." Is that really right and desired, I wonder?

The question facing us in the information age is do we have the courage to learn to use personal information? Such as to undergo gene testing and the like, mistakes and all, so as to help ourselves and others act accordingly? What if gene and other testing uncovers someone has never acted on a tendency, but fits some pedophile-like tendency profile? The medical industry is working towards requiring everyone to succumb to gene testing at birth to better afford efficacy in treatment with drugs, radiation therapy, etc. I believe someday soon the science will be able to tell if someone will have an addiction to certain drugs using genetics. Wouldn't we be better served as a society to let people know apriori if they will likely have adverse reactions to drugs or other environments? At some point a bracelet listing drug reactions would be impractical.

One can definitely see both sides of the power argument: efficacy vs. abuse of information.

Power always cuts both ways and can be used for better or naught. Do we have the courage to learn to use the information we now, or will soon, have? Or do we just continue to deny? We have the "courage" to make weapons of mass destruction...but how 'bout the courage to use mass personal information of efficacy?

Interesting debate, and I'd second your sentiment that "Society has not responded well to this type of situation."

There is a myth out there that object oriented code produces better quality code then procedural programming.

I say myth because scientifically it has never been proven that code quality improves with compiler discipline.

All claims about less bugs per lines of code, easier to maintain, etc are purely anecdotal and speculative. When I studied this back in the early 1990s the primary impedance to any objective analysis comparing like for like were cost prohibitive. Any effort that involved a change in language also incorporated a change in design. People who wrote the original implementation were replaced, etc. etc.

One could look at this as a teaching moment.

Someone needs to step up and prove that compiler or language discipline increases code quality holding the developer constant.

The claim is that a programmer using a different compiler or language produces better quality code. It has been shown scientifically that a C compiler will mostly produce better performing code than code written in assembly. It has never been proven that compiler discipline can make a better programmer. If it has been proven than someone should be easily able to point that proof the to GCC crowd for them to use as an arbitrator for where to draw the C++ line.

The only argument that makes sense with respect to object oriented languages is that they afford a toolkit for upfront design. The large project architect has tools to layout the design for the implementers to essentially fill in the blank. Stroustrup predicates his entire C++ book on this point.

However, it doesn't appear the design features of C++ are the objective here. The objective here is code quality via better syntax, and is this is a claim that has never proven. Its a modern myth.

This is really not a discussion about C++ vs. C, but rather the modern myth that any given developer produces better quality code by compiler discipline.

There is no requirement that a functional language allow self modifying code, only that it is expressed as the composition of functions, is stateless and avoids mutable data.

FP without lambda functions, eh?

2: functional programming and self modifying code have nothing to do with one another.

This is the equivalent of saying lamda functions have nothing to do with functional programming.

1: if you understand what you are doing, asynchronous programming is easy. All you have to do is prevent screwing up the shared state between threads. Since functional languages have no state to share, you can avoid 99% of the pitfalls of dealing with threading.

Therein lies the rub and I'm glad you put it out there. Take any class of computer science students you wish and test them on asynchronous programming and synchronous programming. Guess which one will have the lower scores? Not for all people though, and presumably you are one of those for which asynchronous programming comes natural and easy too. Therein lies the rub. This concept also applies to functional programming vs imperative and came up in a code review I had recently for some Perl code. The reviewer asked my why I used "for loops" as opposed to "map". I never use map. I said because it has been proven time-and-time again that people do not understand "map" as well as they do "for loops", especially the side effects in Perl (not truly functional). There is no performance difference either way, but there is a human difference. I argue my code is more maintainable at the expense of a few lines of ASCII text. You have no idea if the person following you finds what you find to be understandable equally understandable and in the case of "map" using a for loop is trivial; the cost to me is nothing and the opportunity for maintainability greater.

Concepts A number of concepts and paradigms are specific to functional programming, and generally foreign to imperative programming (including object oriented programming). However, programming languages are often hybrids of several programming paradigms so programmers using "mostly imperative" languages may have utilized some of these concepts.[24] Comparison of functional and imperative programming. Functional programming is very different from imperative programming. The most significant differences stem from the fact that functional programming avoids side effects, which are used in imperative programming to implement state and I/O. Pure functional programming disallows side effects completely. Disallowing side effects provides for referential transparency, which makes it easier to verify, optimize, and parallelize programs, and easier to write automated tools to perform those tasks. Higher order functions are rarely used in older imperative programming. Where a traditional imperative program might use a loop to traverse a list, a functional style would often use a higher-order function, map, that takes as arguments a function and a list, applies the function to each element of the list, and returns a list of the results.

http://en.wikipedia.org/wiki/Self_modifying_code#High_level_languages

Some high level languages/ interpreters such as SNOBOL4, the Lisp programming language...

If one is really going to claim that Lisp is no more "self-modifying" than OO, I'd invite you to defend this on Wikipedia.

A good FP design dynamically creates and composes anonymous lamba functions on the fly, myself and professors at Berkeley would argue the very essence of FP. Never have I seen this spelled out as a requirement for OO.

If you really want to be honest about this, visit CPAN and do a catalog of all the FP in the thousands of modules there. Every developer has FP at their finger tips: how many do it? Perl's eval function does allow one to create lamba functions, but is this a common design pattern? Most Perl eval code is for exception handling, not for processing strings of code.

In all seriousness there are two concepts are are especially onerous and difficult to do well in computer science:

1.) Asynchronous code (threads).
2.) Self modifying code (functional programming).

Both concepts are difficult for typical developers to get right. What the world needs is a revolutionary approach to these two topics such that average developers have the necessary tools to produce quality code for multi-core machines.

Someone needs to take design patterns to the concrete level and create design pattern libraries that model asynchronous and self-modifying code in robust ways that the common API programmer can use.

In my opinion trying to bring robustness to asynchronous code by using self-modifying code is going the wrong direction: compounding one onerous concept with one just as equally onerous.

/rant on

LISP? My claim has always been that people who think in functional programming come from out space and are secretly trying to take over the world by twisting computer languages to be something completely alien.

I mean, LISP is to programming languages like Babylon 5 is to SciFi. Cdr and car? /rant off

LOL.

OO, the politically correct version of "G[O]T[O]".

So much OO code, so much spaghetti.

Compound classic OO programming with Javascript's bizarre notion of "objects" and we've come full circle.

Back in the 1980s and 1990s when the efficacy of OO was still being debated as to all claims of improved productivity, the only thing that got proved by studies was that in fact, rewriting something from scratch improves code. You can take an OO design and rewrite it in procedural code and come up with less lines, and less bugs. You can take a procedural design and rewrite it in OO code and come up with less lines and less bugs.

OO is not provably superior in productivity to procedural code except in people's dreams. As my advisor pointed out in grad school, computer languages and methodologies are akin to religion. Once people glom onto them you can't shake them loose.

A good programmer will be good in procedural or OO, and likewise a bad programmer will still be bad. It is only the hubris of academics that methodology fads, like Design Patterns, can make code more robust or pick your metric. They never prove it.

I'm involved in an OO redesign now where they are using a concept fad called a "blackboard". LOL. Which is nothing more than a finite state machine design where all long running state is passed around on the "blackboard". After years and years of "encapsulation", they have, in fact come to realize that having a bezillion object copies of what is in fact is GLOBAL data, (No, not global data, YES global data!), they are going to now have data un-encapsulated so they can serialize state of long running transactions. Every object copies everything off the blackboard and the updates it when they are done and updates the blackboard. Copies, copies everywhere. But because objects are not, in fact, using the data on the blackboard, serialization is problematic because processes with object copies of GLOBAL data are in unknown states of running at any given time. Blindly using encapsulation is an Achilles heel of many an OO design.

Your comment about over "object" achievement reminded me of this. Encapsulation is not always the right design if in fact the application doesn't merit it. But people get taught blindly, as with religion, that encapsulation is always good for all things big and small and you can never get enough of it.