The Java Virtual Machine (JVM) is, of course, a virtual machine. Java is a statically-typed, object-oriented programming language. It is most usually compiled to bytecode which is run on the JVM, but it compilers are available to compile it directly to native code as well either through byte code or directly.
When Java is the first thing you learn, you learn sloppy IMHO.
You learn sloppy if you are taught sloppy. It doesn't really matter if what you learn first is C, C++, Java, BASIC, Scheme, FORTRAN, Ruby, Haskell, or Erlang. There are some concepts that Java isn't ideal for teaching, but then, that's true of every language.
You just assume there is a garbage collector. You can allocate whatever you want, whenever you want, and not have to think about scope. If you ever do have to do some system work later on in your career - all of these notions will be new.
Yes, a complete education in programming needs to cover a wide range of environments, languages, and problem domains, and insofar as it misses some of those, the environments, languages, and problem domains overlooked will present notions that are new if encountered later.
This doesn't meant that learning Java first is bad because system work will be "new" after it. It does mean that learning Java exclusively may be limiting.
You'll have to think about pointers, and the size of an object in memory, and how long you should hold on to it before you free up that memory.
Actually, if you learn to program well in a garbage collected language, you'll need to think about this, too. Which is probably why introductory books on Ruby and Java that I've seen tend to discuss it.
The point though is that programming as a concept is completely alien to somebody who hasn't done it before, so the fact that some bits about a very simple Java program can't be explained without knowledge that students don't yet have is not something peculiar to Java, but is inherent in the nature of programming itself.
I don't think it is. I think that the problems are that: 1) Programs that perform I/O are inherently not "simple" programs—now, I/O is a requirement for useful programs, and might be pedagogically useful at an early stage to give people a feeling of making the computer "do something" productive, but its not simple, and it isn't central to understanding computing or program design, and 2) The structure of Java (this is true of C and Pascal as well, though to a slightly lesser extent) programs inherently is not "simple", it involves lots of overhead.
Then they should, because the first thing any student needs to learn is what a program is, i.e. something that processes input, and outputs the result.
I prefer HtDP's description: "[A program] is a rule that tells us and the computer how to produce data from some other data." (SICP has a similar perspective, though expressed less directly.)
Input and output (outside of the context in which inputs refer to function arguments and the like, and outputs refer to function return values) are—while important to practical programming, pretty much a distraction from the central focus of computer science.
And yet, when Microsoft does the same thing, it's called "embrace, extend, extinguish". Somehow, that didn't work for IBM (and remember, IBM was the 300 pound gorilla back then).
That's true, I guess, but not in the way you intended: the usual phrase for a market-dominating player is "800-lb gorilla", so a "300-lb gorilla" is a perfect term for a shadow of a formerly-dominant player. IBM had long been displaced as the leading maker of desktop computers (even PC-compatible computers), IIRC, at the time OS/2 came out, Tandy and Compaq were both selling more PCs than IBM. MS-DOS was more popular than any IBM operating system, even the IBM-licensed version of MS-DOS (PC-DOS). OS/2 on the software side and the PS/2 on the hardware side were pretty much the dying gasp of IBM in the PC market, not something it did at a time when it ruled the market.
Whereas the standard C "hello world" example will of course be perfectly obvious to any rank programming beginner due to the fact that people are born knowing all about functions, header files, and libraries, whereas objects and classes are something they have to be taught.
Actually, I find the whole "Hello, World!" magic discussion (whether about Java or otherwise) to say more about bad pedagogy and less about the language used: those first-courses or first-course-oriented books I've seen that start with "Hello, World!" examples in any language dissect the pieces of the example, rather than leaving everything as "magic".
And those that use languages with an immediate environment that shows evaluation results tend not to cover I/O much at all until they've covered a lot of other material.
In practice, you end up with the same number of parentheses in lisp as any other language, and you save on commas and semicolons.
Well, no, I don't think that's correct. Because syntactic forms as well as function applications in Lisp are generally delineated with parenthesis, you usually replace a lot of other markers found in other languages (begin/end markers, then/else/when/end etc. in conditionals, curlies, square brackets, etc.) with parens, as well as keeping the same number of parens for function applications. This means you usually end up with more parens and less of everything else—at least, for the same number of characters of code.
Of course, the ability to define new syntactic forms via macros may mean that you need less code in a Lisp variant.
As the author tried to explain, programmers need a solid foundation in data structures and algorithms before they should even begin looking at Java. The specific problem he calls out (which I actually feel only scratches the surface) is that Java offers such a featureful API that the programmer isn't forced to learn the basics.
This might be a problem if you don't learn anything but Java (but even then, probably not, see below)—though neither the first article, this article, or the comment threads attached to either pointed to any university that let you do that. Its not really a problem with learning Java first: a first course often touches on data structures and algorithms, but spends a substantial portion of its time teaching basic problem analysis and structured design of solutions, and even in the "golden age" when they were taught with Pascal or C (or now, when they are, at first rate institutions, apparently often taught with Scheme) these courses often made use of libraries, either industry standard, designed-for-general-pedagogy, or designed for the course specifically (often, a combination) to allow the students to focus on the parts of the problems they were intended to focus on an learn the process basics, that are more fundamental than data structures and algorithms.
But even for a curriculum that always used Java or other languages for which such libraries are not merely available but included in the standard distribution, this shouldn't be a problem even beyond the first course. Having libraries available, even standard, isn't a pedagogical problem: so long as the coursework involves and requires learning about and implementing data structures without relying on the implementations in the libraries. Heck, in first or second courses using Scheme or other Lisps, implementing more robust Lisp variants relying only on the handful of primitive operators at the core of Lisp from the host implementation is fairly common. Having more efficient implementations of the other features available in the host implementation doesn't hurt pedagogy because use of them is specifically forbidden in the assignment.
Now, certainly, having a limited teaching language may have utility, especially in first courses, for other reasons (How to Design Programs makes good use of successively-more-advanced pedagogical variants of Scheme, for instance), its not because having a robust library hurts, but because language features that are useful in other contexts (either because of support for legacy code, or notational adaptations to support certain flexibilities that aren't needed in early pedagogy, or otherwise) often make either notation or errors less clear than they could otherwise be for pedagogical purposes. But viewing the availability (or inclusion in standard distribution) of rich libraries as a bad thing seems unjustified in any case.
...without any specific examples or support to point to of "dumbing down". It mentions a specific case where Java was selected instead of Pascal as the first language, and asserts that it was purely because of "student demand" and implies that pedagogical concerns weren't considered. But the very early arguments I heard when Java was young about it potentially displacing Pascal as a teaching language centered around the fact that it retained the features of Pascal that made it a strong teaching language, while at the same time being industrially useful. Dewar and the author point to no way in which Java is less pedagogically appropriate, only notes that popular texts spend a lot of time discussing libraries rather than the core language (something that was true, even decades ago, of popular books on Pascal—though popular books, of necessity, focussed on particular pascal implementations -- usually Turbo Pascal -- because there was little standardization beyond the core language.
And from the review of the catalogs from a few major universities (Caltech, MIT, Stanford, UC Davis) I did at the time of the thread on the first article, it doesn't seem like either Java (as complained about in the first article) or graphics libraries and other "fun" in place of fundamentals (as complained about in this article) are as universally the focus of CS education, even in the first few classes where one might suspect "making it fun" to retain underclassman that might be insecure in the major and attract those undeclared and wavering that might be trying it out would be factors, if they were considered at all. Without some kind of concrete problem to point to, I'm left suspecting that Dewar was on the losing side of an academic turf war while on the faculty at NYU, and is attempting to extend his perception of that turf war and the effects he expected the other side to have to the whole of modern US academia.
I honestly believe that the US would not be lagging so far behind in sciences if we finished converting fully to the metric system.
We'd also probably have more (chicken) eggs if we could just somehow produce a whole lot more chickens, first.
(To be clear, I'm not saying you are wrong, only that it works both ways: I think we'd be more likely to convert fully to the metric system if the average level of math/science proficiency were higher.)
Hardly, as many of the world's brightest researchers end up in the US.
The US has an enormous concentration of capital, which goes to hire the best talent it can; its just cheaper, often, for that capital to pay to import that talent (including paying the cost of getting government to allow it to do that) than it would be for that capital to pay to develop it locally.
The reaction seems straightforward enough. The MapReduce paradigm has proved to be very effective for a company that lives and breathes scalability, while it apparently ignores a whole bunch of database work that's been going on in academia.
That's not the "problem" (from the perspective of the authors of TFA), really.
The problem is that provides an alternative to work that has been going on in industry, and in particular that it provides a way to end-run some of the limitations of traditional databases that may reduce demand for the particular alternative-model (column-based) database that the company that launched the blog on which TFA is posted is trying to sell as the way to work around the limitations of traditional row-based databases.
Of course, mostly MapReduce isn't about being a database, so the criticism in the article seems bizarre, but its mostly intended for the audience who might have a need for which MapReduce might seem like a viable approach and Vertica's "revolutionary" column-oriented database also might seem to be viable approach. While the two tools don't target the exact same needs, the places where they might be useful do overlap.
Which is why a blog whose initial post heralded the demise of the one-size fits all database is criticizing MapReduce for not being a traditional database. The problem isn't that its different, its that its not the version of "different" that Vertica is selling.
Or maybe talking the (free!) competition from a blog launched by a company trying to sell a different alternative to traditional databases (but one which outwardly looks more like a traditional RDBMS) for an overlapping problem domain (that is, column-oriented databases, which address some of the same distribution and parallelization issues that MapReduce addresses, and target some of the same areas [e.g., "big science"] where it has been suggested that MapReduce might be useful.)
1) They don't look like hammers, 2) They don't work like hammers, 3) You can already drive in a screw with a hammer, 4) They aren't good at ripping out nails, and 5) They aren't good at driving nails.
Brought to you by The Hammer Column, a blog written by experts in the hammer industry, and launched by Hammertron, makers of a revolutionary new kind of hammer.
MapReduce is a tool, one of whose principal applications is conducting queries on large bodies of data consisting of records of similar structure. It, therefore, competes with traditional DBMSs to a degree.
Responding to myself is bad form, but:
Obviously, this only makes sense taking "similar structure" extremely loosely; still, the point is that MapReduce was developed to fill a niche for which RDBMSs were being used previously, in the absence of a more specialized tool, so it clearly competes with them, to a degree, even while it isn't an DBMS. So there is a relationship.
Since when did MapReduce have anything to do with databases?
MapReduce is a tool, one of whose principal applications is conducting queries on large bodies of data consisting of records of similar structure. It, therefore, competes with traditional DBMSs to a degree.
Now, (largely because of the limitations the authors note), it generally is only used currently for the kind of applications where setting up a traditional RDBMS to handle them would be impractical: Google developed their implementation of MapReduce to handle a task which was at the time straining their existing RDBMS resources.
And, yeah, it requires more custom programming to make work at all than a DBMS, and probably isn't suitable for typical tasks. OTOH, If you are Google, what you are doing isn't a typical DBMS task or load, even if it is within the scope of things a DBMS could do, abstractly, performance considerations aside.
Sometimes rolling-your-own with just the features you need, and an implementation tailored to your particular challenges is more efficient that taking something off the shelf.
And given that there are now open implementations of MapReduce, for people with similar challenges, there isn't as much roll-your-own involved as there were for the people implementing MapReduce the first time, reducing the cost. Yeah, this means that traditional DBMSs have a challenge, though no doubt as MapReduce implementations mature, more of the traditional DBMS features and interfaces (including SQL or something like it) will be bolted on to the successful implementations.
I don't know why this article is so harshly critical of MapReduce.
The primary grounds for complaint seems to be "this isn't the way we do things in the database world". Each of the complaints (except #3) boils down to this (#1: The database community had arguments a few decades back and developed, at the time, a set of conventions; Map Reduce doesn't follow them and is, therefore, bad; #2: All databases use one of two kinds of indexes to accelerate data access; MapReduce doesn't and is, therefore, bad; #3: Databases do something like MapReduce, so MapReduce isn't necessary; #4: Modern databases tend to offer a variety of support utilities and features that MapReduce doesn't, so MapReduce is bad; #5: MapReduce isn't out-of-the-box compatible with existing tools designed to work with existing databases and is, therefore, bad.)
And its from The Database Column, a blog that from its own "About" page is comprised of experts from the database industry.
I suspect part of the reason they are harshly critical is that this is a technology whose adoption and use in large, data-centric tasks is (regardless of efficiency) a threat to the market value of the skills in which they've invested years and $$ developing expertise.
At the end, they note (as an afterthought) that they recognize that MapReduce is an underlying approach, and that there are projects ongoing to build DBMS's on top of MapReduce, a fact which, if considered for more than a second, explodes all of their criticism which is entirely premised on the idea that MapReduce is intended as a general purposes replacement for existing DBMSs, rather than a lower-level technology which is currently used stand-alone for applications for which current RDBMSs do not provide adequate performance (regardless of their other features), and on which DBMS implementations (with all the features they complain about MapReduce lacking) might, in the future, be built.
Science is not anti-religion. We don't waste our time trying to prove religion is false.
Ignoring Dawkins and numerous others, presumably. Science is not monolithic.
Religion is anti-science.
Well, except the vast number of religious people who are also scientists or support science, both lay people and clergy, and the others who are indifferent to it. "Religion" (even "Christianity") isn't monolithic, either.
Does it matter that somebody with the median score in high school math isn't particularly good at it, if he's working as a salesman or a mechanic?
It certainly matters if he's also, say, voting between different candidates who are making competing claims about economic policy, or (as in many US states), voting directly on proposed laws including bond measures.
It certainly matters if the health and stability of the economy depends in substantial part on the quality of decisions he (and people like him in the aggregate) make regarding personal finances (mortgages, car loans, etc.).
I don't think it is realistic to collect empirical evidence of the benefits of a diverse education.
I think it is realistic to ask that those who defend the US poor performance as a side effect of an education that is better in some other way to show that there is, in fact, an area where the US education is better, not just provide unsystematic, largely unsupported descriptions of fuzzy ways that it might be better.
You failed to mention OECD studies related to sports, art, music, or literature (though, you did touch on "reading", but the two are vastly different).
You are welcome to present any study you can find in which the US performs substantially above the average of OECD countries in any area. If you are going to argue that the repeatedly demonstrated weakness of US education in math, science, and problem solving is offset by strengths in other areas, fine, show evidence that these strengths actually exist.
In any case... it remains a Theory that diverse education is best.
Whether a diverse education is "best" doesn't even become a relevant question until it is demonstrated that the education that American students receive is somehow demonstrably more diverse, rather than that alleged "diversity" being a fuzzy, ill-defined, undemonstrated excuse waved around to avoid discussing and dealing with the real and demonstrated weaknesses of the US system. (It's also not a "theory" in the scientific sense, or even a hypothesis, without some operationalization of "best"; its simply an statement of ideology.)
However, the Theory was outlined very clearly by Plato in The Republic and much of his wisdom has served as a pretty descent framework for the American system through the last 200 years or so.
The "American system"—whether of government in general or education in particular—is in no way based upon Plato's philosophy, and is certainly not based on the model presented in The Republic.
If this was the problem in US science performance vs. other countries, you'd expect US students to report less interest in learning, and less perceived importance of, science. Studies of those perceptions (often, the same studies that show the low US performance in science, such as the 2006 PISA) don't show those resultsl; they show the US perceptions comparable to the norm across the OECD, despite the low performance.
1. Parents - more an dmore parents don't take an active role in their kids' education, and blame the schools for their kids' failure.
This is probably a real problem.
2. Basic literacy - more and more kids cannot even read at grade-level. And we expect them to understand concepts like evolution??
Literacy-related studies (like the 2003 PISA) show the US at about OECD average, despite being below average in Math, Science, and Problem Solving. This is probably not a source of the US deficiency.
3. Critical thinking - thanks ot NCLB, kids are taught to take a test, not think for themselves.
NCLB isn't the sole source of this problem, but the poor results on Problem Solving tests suggest that this is a real problem.
4. Qualified/dedicated teachers - thanks to unions, teachers have little motivation to actually give a shit about whether or not their students are actually learning anything.
School principals in the US report more control over hiring, firing, and salary decisions than the average across the OECD, so while qualified/dedicated teachers may be a problem, unionization probably is not the source of it. Ineffective unions, and poor pay and working conditions are more likely factors.
5. No Child Left Behind - the great unfunded mandate that promotes the fantasy that there is no such thing as a dumb, unmotivated kid. One-size-fits-all education only harms good students, and it sure as hell doesn't make the bad ones any better.
NCLB may be a problem, but the US in practice has greater gaps in performance than other OECD countries, and an average number of top performers. So while "one-size-fits-all" is a problem, I think it is more likely the widespread perception that those who don't perform well (which, in the US, is more strongly linked to socioeconomic conditions than is the case across the OECD) are "dumb, unmotivated kids" rather than people with different needs that need to be addressed differently is the source of poor overall performance than is any failure to accept that "dumb, unmotivate kids" exist.
Comparisons to OECD averages from the Programme for International Student Assessment (PISA) 2006 study, except where noted from the 2003 study (the 2006 study was unable to report reading results for the US due to printing errors in some of the booklets used for the reading test in the US.)
The World is Flat talks about how the American advantage is having a broad education that includes history and literature and art. it really a surprise to find that half of the country does poorly in Math and Science when students are encouraged to immerse themselves in a diverse landscape of experiences including sports and music?
That's all nice speculation, and no doubt (like much of what Friedman writes) backed by an anecdote or two, but there's little empirical evidence that the US deficiencies in one area of education are offset by US advantages elsewhere.
Looking at other studies, in the 2003 PISA study, for instance, the US scored right about the OECD average in reading, below OECD average in problem solving, below OECD average in math, and below OECD average in science.
If one wants to assert that the educational weaknesses in the US in math and science are the consequence of policies that produce strengths in other areas, empirical evidence of that strength would be welcome.
A more likely explanation for the weaknesses in science and math is a general weakness in education that manifest primarily through inequity. In the science-focussed 2006 PISA study, the US performed below average overall, but had an average proportion of top performers and an above average proportion of poor performers. The study also found that the US had an stronger than average correlation between socioeconomic background and performance, and unusually large gap between performance both of immediate immigrants and the general population and what it refers to as "second-generation immigrants" (what usually in the US are referred to as "first-generation" -- children whose parents are immigrants) and the general population.
It also notes that US students express a high personal value of science, a high personal motivation to learn science and, despite below average performance, one of the highest levels of confidence in their scientific proficiency of students in any of the studied countries. (Briefing paper here.)
I'd think it would be impossible to maintain closure on relational operations if tuples could not have null. Or rather it would be all to easy to do it in a way that made the theory sound, but useless.
Would you care to elaborate? As far as I can tell, closure on the relational operators is established pretty solidly, and doesn't depend on the weird, not-like-a-normal-value behavior of NULL, and NULL adds nothing to the utility of relational algebra, it simply makes it easier to to implement "relational" databases with fewer tables.
More than likely, all the students that you peer reviewed started their research with Google.
More than likely not; as he said he is at a law school, and as law students generally have available to them rather full-featured academic/professional search engines that are far more useful for in-field research than Google if you've spent the time to learn how to use them (and cost appropriately if you are using them outside of an academic environment), I would be surprised if the students getting good marks didn't start with one of those tools. Google simply doesn't have the chops for legal research; it doesn't have the specialized indexes that facilitate legal research, and more importantly much of the content that is needed for serious legal research isn't publicly available on the web, and certainly not in the comprehensively cross-referenced, summarized form that you can access it in specialized legal search tools. In many cases, the only people that have taken the time to transfer it from scattered, pre-electronic publications into electronic forms are the people that charge lots of money for well-indexed legal research products (in dead tree and electronic forms.)
Google may have the abstract goal of indexing all of human knowledge and making it easily searchable, but they are far from there yet, and there are certainly narrow areas where other people are far ahead. Law is one of those areas.
That law forbids booksellers from offering discounts of more than 5 percent off the list price, and Amazon was found to be exceeding that discount when the free shipping was factored in.
Wouldn't that mean the cover price on the book itself?
It would mean that the manufacturers suggested retail price of the book itself is what the 5% limit is computed from.
That sentence doesn't say anything about what the law says (or leaves ambiguous) about what may be considered a "discount". Certainly, there is a certain logic in considering the bundling of a valuable service with the purchase of the book at no charge as equivalent to a discount equal to the market value of the service on the cost of the book.
Slashdot Mirror
The Java Virtual Machine (JVM) is, of course, a virtual machine. Java is a statically-typed, object-oriented programming language. It is most usually compiled to bytecode which is run on the JVM, but it compilers are available to compile it directly to native code as well either through byte code or directly.
You learn sloppy if you are taught sloppy. It doesn't really matter if what you learn first is C, C++, Java, BASIC, Scheme, FORTRAN, Ruby, Haskell, or Erlang. There are some concepts that Java isn't ideal for teaching, but then, that's true of every language.
Yes, a complete education in programming needs to cover a wide range of environments, languages, and problem domains, and insofar as it misses some of those, the environments, languages, and problem domains overlooked will present notions that are new if encountered later.
This doesn't meant that learning Java first is bad because system work will be "new" after it. It does mean that learning Java exclusively may be limiting.
Actually, if you learn to program well in a garbage collected language, you'll need to think about this, too. Which is probably why introductory books on Ruby and Java that I've seen tend to discuss it.
I don't think it is. I think that the problems are that:
1) Programs that perform I/O are inherently not "simple" programs—now, I/O is a requirement for useful programs, and might be pedagogically useful at an early stage to give people a feeling of making the computer "do something" productive, but its not simple, and it isn't central to understanding computing or program design, and
2) The structure of Java (this is true of C and Pascal as well, though to a slightly lesser extent) programs inherently is not "simple", it involves lots of overhead.
I prefer HtDP's description: "[A program] is a rule that tells us and the computer how to produce data from some other data." (SICP has a similar perspective, though expressed less directly.)
Input and output (outside of the context in which inputs refer to function arguments and the like, and outputs refer to function return values) are—while important to practical programming, pretty much a distraction from the central focus of computer science.
That's true, I guess, but not in the way you intended: the usual phrase for a market-dominating player is "800-lb gorilla", so a "300-lb gorilla" is a perfect term for a shadow of a formerly-dominant player. IBM had long been displaced as the leading maker of desktop computers (even PC-compatible computers), IIRC, at the time OS/2 came out, Tandy and Compaq were both selling more PCs than IBM. MS-DOS was more popular than any IBM operating system, even the IBM-licensed version of MS-DOS (PC-DOS). OS/2 on the software side and the PS/2 on the hardware side were pretty much the dying gasp of IBM in the PC market, not something it did at a time when it ruled the market.
Probably it could be. Are there any concrete examples of schools with curricula that do that?
Actually, I find the whole "Hello, World!" magic discussion (whether about Java or otherwise) to say more about bad pedagogy and less about the language used: those first-courses or first-course-oriented books I've seen that start with "Hello, World!" examples in any language dissect the pieces of the example, rather than leaving everything as "magic".
And those that use languages with an immediate environment that shows evaluation results tend not to cover I/O much at all until they've covered a lot of other material.
Well, no, I don't think that's correct. Because syntactic forms as well as function applications in Lisp are generally delineated with parenthesis, you usually replace a lot of other markers found in other languages (begin/end markers, then/else/when/end etc. in conditionals, curlies, square brackets, etc.) with parens, as well as keeping the same number of parens for function applications. This means you usually end up with more parens and less of everything else—at least, for the same number of characters of code.
Of course, the ability to define new syntactic forms via macros may mean that you need less code in a Lisp variant.
This might be a problem if you don't learn anything but Java (but even then, probably not, see below)—though neither the first article, this article, or the comment threads attached to either pointed to any university that let you do that. Its not really a problem with learning Java first: a first course often touches on data structures and algorithms, but spends a substantial portion of its time teaching basic problem analysis and structured design of solutions, and even in the "golden age" when they were taught with Pascal or C (or now, when they are, at first rate institutions, apparently often taught with Scheme) these courses often made use of libraries, either industry standard, designed-for-general-pedagogy, or designed for the course specifically (often, a combination) to allow the students to focus on the parts of the problems they were intended to focus on an learn the process basics, that are more fundamental than data structures and algorithms.
But even for a curriculum that always used Java or other languages for which such libraries are not merely available but included in the standard distribution, this shouldn't be a problem even beyond the first course. Having libraries available, even standard, isn't a pedagogical problem: so long as the coursework involves and requires learning about and implementing data structures without relying on the implementations in the libraries. Heck, in first or second courses using Scheme or other Lisps, implementing more robust Lisp variants relying only on the handful of primitive operators at the core of Lisp from the host implementation is fairly common. Having more efficient implementations of the other features available in the host implementation doesn't hurt pedagogy because use of them is specifically forbidden in the assignment.
Now, certainly, having a limited teaching language may have utility, especially in first courses, for other reasons (How to Design Programs makes good use of successively-more-advanced pedagogical variants of Scheme, for instance), its not because having a robust library hurts, but because language features that are useful in other contexts (either because of support for legacy code, or notational adaptations to support certain flexibilities that aren't needed in early pedagogy, or otherwise) often make either notation or errors less clear than they could otherwise be for pedagogical purposes. But viewing the availability (or inclusion in standard distribution) of rich libraries as a bad thing seems unjustified in any case.
...without any specific examples or support to point to of "dumbing down". It mentions a specific case where Java was selected instead of Pascal as the first language, and asserts that it was purely because of "student demand" and implies that pedagogical concerns weren't considered. But the very early arguments I heard when Java was young about it potentially displacing Pascal as a teaching language centered around the fact that it retained the features of Pascal that made it a strong teaching language, while at the same time being industrially useful. Dewar and the author point to no way in which Java is less pedagogically appropriate, only notes that popular texts spend a lot of time discussing libraries rather than the core language (something that was true, even decades ago, of popular books on Pascal—though popular books, of necessity, focussed on particular pascal implementations -- usually Turbo Pascal -- because there was little standardization beyond the core language.
And from the review of the catalogs from a few major universities (Caltech, MIT, Stanford, UC Davis) I did at the time of the thread on the first article, it doesn't seem like either Java (as complained about in the first article) or graphics libraries and other "fun" in place of fundamentals (as complained about in this article) are as universally the focus of CS education, even in the first few classes where one might suspect "making it fun" to retain underclassman that might be insecure in the major and attract those undeclared and wavering that might be trying it out would be factors, if they were considered at all. Without some kind of concrete problem to point to, I'm left suspecting that Dewar was on the losing side of an academic turf war while on the faculty at NYU, and is attempting to extend his perception of that turf war and the effects he expected the other side to have to the whole of modern US academia.
We'd also probably have more (chicken) eggs if we could just somehow produce a whole lot more chickens, first.
(To be clear, I'm not saying you are wrong, only that it works both ways: I think we'd be more likely to convert fully to the metric system if the average level of math/science proficiency were higher.)
The US has an enormous concentration of capital, which goes to hire the best talent it can; its just cheaper, often, for that capital to pay to import that talent (including paying the cost of getting government to allow it to do that) than it would be for that capital to pay to develop it locally.
That's not the "problem" (from the perspective of the authors of TFA), really.
The problem is that provides an alternative to work that has been going on in industry, and in particular that it provides a way to end-run some of the limitations of traditional databases that may reduce demand for the particular alternative-model (column-based) database that the company that launched the blog on which TFA is posted is trying to sell as the way to work around the limitations of traditional row-based databases.
Of course, mostly MapReduce isn't about being a database, so the criticism in the article seems bizarre, but its mostly intended for the audience who might have a need for which MapReduce might seem like a viable approach and Vertica's "revolutionary" column-oriented database also might seem to be viable approach. While the two tools don't target the exact same needs, the places where they might be useful do overlap.
Which is why a blog whose initial post heralded the demise of the one-size fits all database is criticizing MapReduce for not being a traditional database. The problem isn't that its different, its that its not the version of "different" that Vertica is selling.
Or maybe talking the (free!) competition from a blog launched by a company trying to sell a different alternative to traditional databases (but one which outwardly looks more like a traditional RDBMS) for an overlapping problem domain (that is, column-oriented databases, which address some of the same distribution and parallelization issues that MapReduce addresses, and target some of the same areas [e.g., "big science"] where it has been suggested that MapReduce might be useful.)
1) They don't look like hammers,
2) They don't work like hammers,
3) You can already drive in a screw with a hammer,
4) They aren't good at ripping out nails, and
5) They aren't good at driving nails.
Brought to you by The Hammer Column, a blog written by experts in the hammer industry, and launched by Hammertron, makers of a revolutionary new kind of hammer.
Responding to myself is bad form, but:
Obviously, this only makes sense taking "similar structure" extremely loosely; still, the point is that MapReduce was developed to fill a niche for which RDBMSs were being used previously, in the absence of a more specialized tool, so it clearly competes with them, to a degree, even while it isn't an DBMS. So there is a relationship.
MapReduce is a tool, one of whose principal applications is conducting queries on large bodies of data consisting of records of similar structure. It, therefore, competes with traditional DBMSs to a degree.
Now, (largely because of the limitations the authors note), it generally is only used currently for the kind of applications where setting up a traditional RDBMS to handle them would be impractical: Google developed their implementation of MapReduce to handle a task which was at the time straining their existing RDBMS resources.
And, yeah, it requires more custom programming to make work at all than a DBMS, and probably isn't suitable for typical tasks. OTOH, If you are Google, what you are doing isn't a typical DBMS task or load, even if it is within the scope of things a DBMS could do, abstractly, performance considerations aside.
Sometimes rolling-your-own with just the features you need, and an implementation tailored to your particular challenges is more efficient that taking something off the shelf.
And given that there are now open implementations of MapReduce, for people with similar challenges, there isn't as much roll-your-own involved as there were for the people implementing MapReduce the first time, reducing the cost. Yeah, this means that traditional DBMSs have a challenge, though no doubt as MapReduce implementations mature, more of the traditional DBMS features and interfaces (including SQL or something like it) will be bolted on to the successful implementations.
The primary grounds for complaint seems to be "this isn't the way we do things in the database world". Each of the complaints (except #3) boils down to this (#1: The database community had arguments a few decades back and developed, at the time, a set of conventions; Map Reduce doesn't follow them and is, therefore, bad; #2: All databases use one of two kinds of indexes to accelerate data access; MapReduce doesn't and is, therefore, bad; #3: Databases do something like MapReduce, so MapReduce isn't necessary; #4: Modern databases tend to offer a variety of support utilities and features that MapReduce doesn't, so MapReduce is bad; #5: MapReduce isn't out-of-the-box compatible with existing tools designed to work with existing databases and is, therefore, bad.)
And its from The Database Column, a blog that from its own "About" page is comprised of experts from the database industry.
I suspect part of the reason they are harshly critical is that this is a technology whose adoption and use in large, data-centric tasks is (regardless of efficiency) a threat to the market value of the skills in which they've invested years and $$ developing expertise.
At the end, they note (as an afterthought) that they recognize that MapReduce is an underlying approach, and that there are projects ongoing to build DBMS's on top of MapReduce, a fact which, if considered for more than a second, explodes all of their criticism which is entirely premised on the idea that MapReduce is intended as a general purposes replacement for existing DBMSs, rather than a lower-level technology which is currently used stand-alone for applications for which current RDBMSs do not provide adequate performance (regardless of their other features), and on which DBMS implementations (with all the features they complain about MapReduce lacking) might, in the future, be built.
Ignoring Dawkins and numerous others, presumably. Science is not monolithic.
Well, except the vast number of religious people who are also scientists or support science, both lay people and clergy, and the others who are indifferent to it. "Religion" (even "Christianity") isn't monolithic, either.
It certainly matters if he's also, say, voting between different candidates who are making competing claims about economic policy, or (as in many US states), voting directly on proposed laws including bond measures.
It certainly matters if the health and stability of the economy depends in substantial part on the quality of decisions he (and people like him in the aggregate) make regarding personal finances (mortgages, car loans, etc.).
I think it is realistic to ask that those who defend the US poor performance as a side effect of an education that is better in some other way to show that there is, in fact, an area where the US education is better, not just provide unsystematic, largely unsupported descriptions of fuzzy ways that it might be better.
You are welcome to present any study you can find in which the US performs substantially above the average of OECD countries in any area. If you are going to argue that the repeatedly demonstrated weakness of US education in math, science, and problem solving is offset by strengths in other areas, fine, show evidence that these strengths actually exist.
Whether a diverse education is "best" doesn't even become a relevant question until it is demonstrated that the education that American students receive is somehow demonstrably more diverse, rather than that alleged "diversity" being a fuzzy, ill-defined, undemonstrated excuse waved around to avoid discussing and dealing with the real and demonstrated weaknesses of the US system. (It's also not a "theory" in the scientific sense, or even a hypothesis, without some operationalization of "best"; its simply an statement of ideology.)
The "American system"—whether of government in general or education in particular—is in no way based upon Plato's philosophy, and is certainly not based on the model presented in The Republic.
If this was the problem in US science performance vs. other countries, you'd expect US students to report less interest in learning, and less perceived importance of, science. Studies of those perceptions (often, the same studies that show the low US performance in science, such as the 2006 PISA) don't show those resultsl; they show the US perceptions comparable to the norm across the OECD, despite the low performance.
This is probably a real problem.
Literacy-related studies (like the 2003 PISA) show the US at about OECD average, despite being below average in Math, Science, and Problem Solving. This is probably not a source of the US deficiency.
NCLB isn't the sole source of this problem, but the poor results on Problem Solving tests suggest that this is a real problem.
School principals in the US report more control over hiring, firing, and salary decisions than the average across the OECD, so while qualified/dedicated teachers may be a problem, unionization probably is not the source of it. Ineffective unions, and poor pay and working conditions are more likely factors.
NCLB may be a problem, but the US in practice has greater gaps in performance than other OECD countries, and an average number of top performers. So while "one-size-fits-all" is a problem, I think it is more likely the widespread perception that those who don't perform well (which, in the US, is more strongly linked to socioeconomic conditions than is the case across the OECD) are "dumb, unmotivated kids" rather than people with different needs that need to be addressed differently is the source of poor overall performance than is any failure to accept that "dumb, unmotivate kids" exist.
Comparisons to OECD averages from the Programme for International Student Assessment (PISA) 2006 study, except where noted from the 2003 study (the 2006 study was unable to report reading results for the US due to printing errors in some of the booklets used for the reading test in the US.)
That's all nice speculation, and no doubt (like much of what Friedman writes) backed by an anecdote or two, but there's little empirical evidence that the US deficiencies in one area of education are offset by US advantages elsewhere.
Looking at other studies, in the 2003 PISA study, for instance, the US scored right about the OECD average in reading, below OECD average in problem solving, below OECD average in math, and below OECD average in science.
If one wants to assert that the educational weaknesses in the US in math and science are the consequence of policies that produce strengths in other areas, empirical evidence of that strength would be welcome.
A more likely explanation for the weaknesses in science and math is a general weakness in education that manifest primarily through inequity. In the science-focussed 2006 PISA study, the US performed below average overall, but had an average proportion of top performers and an above average proportion of poor performers. The study also found that the US had an stronger than average correlation between socioeconomic background and performance, and unusually large gap between performance both of immediate immigrants and the general population and what it refers to as "second-generation immigrants" (what usually in the US are referred to as "first-generation" -- children whose parents are immigrants) and the general population.
It also notes that US students express a high personal value of science, a high personal motivation to learn science and, despite below average performance, one of the highest levels of confidence in their scientific proficiency of students in any of the studied countries. (Briefing paper here.)
Would you care to elaborate? As far as I can tell, closure on the relational operators is established pretty solidly, and doesn't depend on the weird, not-like-a-normal-value behavior of NULL, and NULL adds nothing to the utility of relational algebra, it simply makes it easier to to implement "relational" databases with fewer tables.
More than likely not; as he said he is at a law school, and as law students generally have available to them rather full-featured academic/professional search engines that are far more useful for in-field research than Google if you've spent the time to learn how to use them (and cost appropriately if you are using them outside of an academic environment), I would be surprised if the students getting good marks didn't start with one of those tools. Google simply doesn't have the chops for legal research; it doesn't have the specialized indexes that facilitate legal research, and more importantly much of the content that is needed for serious legal research isn't publicly available on the web, and certainly not in the comprehensively cross-referenced, summarized form that you can access it in specialized legal search tools. In many cases, the only people that have taken the time to transfer it from scattered, pre-electronic publications into electronic forms are the people that charge lots of money for well-indexed legal research products (in dead tree and electronic forms.)
Google may have the abstract goal of indexing all of human knowledge and making it easily searchable, but they are far from there yet, and there are certainly narrow areas where other people are far ahead. Law is one of those areas.
It would mean that the manufacturers suggested retail price of the book itself is what the 5% limit is computed from.
That sentence doesn't say anything about what the law says (or leaves ambiguous) about what may be considered a "discount". Certainly, there is a certain logic in considering the bundling of a valuable service with the purchase of the book at no charge as equivalent to a discount equal to the market value of the service on the cost of the book.