Notably absent from this list is Apache, so I assume that they have worked out a special arrangement w/ Sun, since Tomcat is the servlet/jsp engine embedded in the J2EE RI.
Tomcat does not come close to implementing the J2EE spec, so why would Apache need a license from Sun?
Sun has never claimed that Java is "open" in the Open Source sense of the word.
No, but Sun has claimed that Java is "open" in the "open standards", and that is just not true. An "open standard" is a standard anybody can implement, with no licensing restrictions. ANSI C is an open standard. IEEE Scheme is an open standard. Java is not an open standard.
I cannot agree with your statement regarding the "legal minefield" of Java technology. What IP/Licensing cases (except JBoss/Apache - which was an affirmation of the LGPL) can you recall from the past year?
Actually, the fact that Sun is quietly putting these restrictions into their licenses and not asserting them is what makes them particularly worrisome. IP rights like that become particularly destructive if people (like you) come to believe that the standard can be implemented freely only to find out later that they were wrong.
What they can claim, is that the technology is developed implemented, and deployed in an open, industry accepted manner.
In different words, Sun gets other people to do technical development work for them for free and then creates a proprietary standard out of it. Sun is playing word games with the term "open". Frankly, at this point, I have to believe that they are deliberately deceptive rather than merely confused.
Keep in mind that many of the fortune 500 who are embracing Linux/OSS also have large investments in Java technology.
Yes, and the same Fortune 500 companies also have large investments in Microsoft Windows and IBM mainframes. Whether they invest in something is largely unrelated to whether it's proprietary, free, or open. And Fortune 500 companies have so much money to throw around that their purchases don't even tell you whether something is cost effective or even works. In different words, there is no logical connection between a company's use of Linux and a company's use of Java.
Copyright 1994-2004 Sun Microsystems, Inc. ("Sun") hereby grants you a fully-paid, non-exclusive, non-transferable, worldwide, limited license (without the right to sublicense), under the Sun's applicable intellectual property rights to view, download, use and reproduce the Specification
only for the purpose of internal evaluation, which shall be understood to include developing applications intended to run on an implementation of the Specification provided that such applications do not themselves implement any portion(s) of the Specification.
That explicitly tells you that you can't implement the specification without a license from Sun.
I suspect all the major J2EE providers have a license from Sun. The only successful attempt at an open source implementation was bullied by Sun into agreeing to Sun's legal terms (and even that implementation still required Sun's proprietary Java 2 implementation to run on anyway).
Sun is deliberately deceiving people when they claim that Java is open on the one hand and then publish specifications under such licenses on the other. Sun is creating a legal minefield around Java. Don't get lured in--it will blow up in your face.
You have forgotten that fraud, stock manipulation, and/or empty promises pay off--for a while. If you can time it right, you can get very wealthy from them. In fact, any meteoric rise in stock values is almost certainly too good to be based on reality, whether it's SCO, Microsoft, or your favorite Internet startup.
Wrong on the first count, right in the second but the very need for optimizations should give you a clue to what my concern is about that.
I guarantee you that your C pointer code will be uniformly no better than Fortran array code.
And, no, I don't understand what "your concern" is about, other than holding on to a totally obsolete, unsafe programming language that you happen to know.
You're confusing two entirely seperate issues. Debugging is an entirely different issue to being able to predict the behaviour of code. Without knowing the underlying basis of the code, I cannot do the latter. [...] Debugging can be fractionally easier in a 4G language, but that's not a substitute, or even the same ballpark, as being able to predict how a correctly written statement will execute.
You don't even understand the problem. It's not about debugging, it's about fault isolation. C doesn't have any. Once your code or any library you call has as much as referenced one past the end of an array, the language guarantees absolutely nothing anymore. There isn't even any indication that anything has gone wrong.
You have gotten so used to C's misfeatures that you don't even understand that things could be different.
Wow. So C isn't trendy enough. I get it now. Good grief.
Yes, indeed, C isn't "trendy" enough in the same way gas lighting isn't trendy enough: it's dangerous and it's completely obsolete.
No, you're not reading the thread. Go look at this which is the first mention of "high performance computing" and clearly refers to my comment about faster CPUs.
C is no good for "high performance computing", no matter which sense of the term you use. It isn't good for writing high performance desktop apps and it isn't good for writing high performance scientific apps (the more usual use of the term).
Note that a lot of the criticism involves non-open source technologies. J2EE, for example, manages to be as bloated and proprietary as anything from Microsoft. And, well, it's not exactly surprising that mainframes are expensive to buy and operate compared to Intel boxes no matter what they run--companies don't buy mainframes to save money on hardware or IT staff.
Most of the Linux successes involve humble, cheap little PC servers running no-frill software like Apache, PHP, or Perl. Microsoft and Sun need grand strategies, new APIs, and "breakthrough" technologies to get the job done, not to mention upgrading every other year, while Linux just gets the job done with boring, old, but proven software. Of course, you won't find that in any corporate-sponsored comparison.
Maybe Indian women aren't as shallow. Maybe there are enough that don't go for the biggest pecs and most expensive car but are actually happy dating someone with a steady, well-paying job who they can have a conversation with.
C is a good language for high-performance computing, as are most third generation languages. I'm baffled as to why you'd think "C gets in the way",
Because C pointers don't help with writing faster code, but their existence in the language inhibits a lot of optimizations.
Remember the context of this that lead to my original comment was the suggestion that people should ditch C and C++ for Python and Perl because some-how Python and Perl are "better".
No, it suggested using high-level languages in general. Which high level language is better depends on the application. Python is probably better for most desktop apps. C# and O'CAML are better for general purpose programming. Fortran (modern versions) is better for high performance numerical computing.
I love C's simplicity.
C appears to be simple because it has few constructs, but its semantics are horrendously complex. Think about all the different things a pointer can point to and how those things behave differently as the program executes.
I love knowing what my code is going to do and being able to predict its strengths and weaknesses.
But you "can't predict what your code is going to do"--that is, in fact, one of C's biggest weaknesses. Any bug in any library or anywhere in your code means that all bets are off as to the behavior of the rest of the program. Unlike most other high-level languages, C and C++ provide no means of isolating errors and recovering from them reliably.
I think well written C is, by itself, beautiful. Don't knock it, it's good stuff.
C was "good stuff" in the days of bell bottoms, PDP-11s, and 64k i-spaces. Even then, 20 years after Lisp and Algol and 10 years after Simula, C was "good stuff" only in a sort of second-hand chic way--look how much I can do with this dirt cheap compiler.
Personally, I like C. And to be honest, I always thought the advantage in having a faster CPU was that my programs could run faster.
Yeah, so why do you program in C? C is not a good language for high-performance computing. With a lot of work, you can often get decent performance out of it, but C gets in the way rather than helping you.
I agree: the use of C/C++ for most Linux applications just doesn't make a lot of sense. It's more effort to develop in than a HLL, a lot harder to debug, and usually, it isn't even any faster. Python would probably be a good choice for many desktop apps.
However, when it comes to statically type checked, non-C/C++ languages on Linux, there isn't much choice:
Java: no fully compliant open source implementations; some serious design flaws.
C#: not a standard part of major Linux distributions; some concerns (probably unjustified, but still) about Microsoft patents.
Eiffel: open source compiler does not support separate compilation; some serious design flaws in its type system.
Modula-3, Oberon: not widely used.
O'CAML: great language but probably too complex and sophisticated for your average Linux hacker; lacks some facilities essential for high performance computing.
Overall, C# looks like the most promising to me: it combines the best features and simplicity of Java with most of the efficiency and C-interoperability of C++. Let's hope Mono will make it into all major Linux distributions soon.
They are being screwed and after a decade or so this logic is showing it's shortsightedness as the patrimony erodes. Today, our economy is more or less at a developing country's mercy, competing with underpaid (compared to our standards) labour, basically producing low tech gadgetry with little intrinsic value.
Wealth breeds complacency, but as long as they get what they want out of life, why worry? Once it doesn't work anymore, their children will start taking education more seriously again because they'll realize that they have to.
I can understand when Americans whine about this sort of thing because they don't have the historical perspective, but Italy, in particular, has been through many cycles of this over the millennia, and Italians should really know better than to worry about it.
Uh, I'll give you Fortran, but I'd be surprised to see a Prolog or Haskell implementation that isn't rife with pointers. Haskell, in particular, has a call-by-need semantics that means every piece of data could potentially be a pointer to a closure.
Well, and once you move from 32bit to 64bit machines, those kinds of implementations may have to change if they want to avoid blowing up their heap by a factor of two. Or maybe they don't if their authors decide it doesn't matter. The point is that Prolog and Haskell don't expose pointer semantics and can be implemented efficiently without it. For Prolog, for example, the situation is similar to some of the tricks people developed for implementing it on a PDP-10 (big words, little memory).
The stack is dominated by data, not by those two pointers, so that is insignificant (if it were signficant, it woul be easy to avoid, too).
What in the world are you talking about? I'm talking about the stack on an AMD64, where push and pop instructions always deal with 8-byte quantities.What do "push" and "pop" have to do with "the stack"?
"The stack" refers to the UNIX stack, the stack on which registers and local variables are saved. It is accessed using a wide variety of instructions, including stack-relative addressing, not just push/pop, and it isn't limited to 64bit quantities.
That depends on how [page tables] are represented.
Sorry, I thought we were talking about AMD64.
You made a general statement about 64bit computing and I made a general response. As I was saying, more importantly, the amortized cost of the larger page table entries is tiny.
I think you're talking about scientific (loops-and-arrays) code that has been carefully optimized.
That's not just scientific code, it's database code, graphics code, data mining code, data structure libraries, kernel data structures, and any other place where performance matters.
(Incidentally, why do you think UNIX uses so many integer IDs, historically with fewer than 32 bits? File descriptors, signals, exit codes, process ids, and all that. They could all be pointers, like they are on Windows, but they aren't.)
I'll grant you that a 64-bit processor shouldn't be detrimental to that code. But there's a whack of OO-style code out there that is not dominated by arrays, and that code pays for 64 bits even if it doesn't need them.
Sure, there is a lot of badly written C code (pointer style code), ill-conceived programming paradigms (what passes for OOP), and a lot of incompetently designed programming languages (e.g., Java). But any overhead from 64bit computing is the least of your worries with that kind of software.
Overall, my points are simple:
Yes, things do change "magically" on the Opteron even for 32bit applications running in 32bit mode under a 64bit kernel: the applications get significantly more memory, and the kernel itself can manage much larger amounts of resources.
No, you don't always take a hit from compiling stuff in 64bit mode--carefully written 32bit applications will not significantly increase their memory usage when recompiled for 64bit machines.
Realistically, "outsourcing" just is the situation when software development is cheaper in India but their US-based management doesn't want to move there. The long term resolution to that is obviously not that software development comes back to the US, the long term resolution is that management also moves to India (or wherever).
It's really not that different from what happened in the electronics industry after all: initially, parts came from Japan, then whole devices, and now the companies themselves are Japanese. And it was the same with cars and computer hardware.
What should the US do? There is really only one choice: if it wants to retain its strong economic position, the US needs to start the next revolution in a different field. Maybe that's biotech, nanotechnology (whatever that is) or the commercialization of space. But anybody who wants to claim a leadership position can't lean back and say "we'd just like to lean back for a while and relax on the strength of the jobs we already created".
No, you're hosed when you use pointers, as you mention. Which is a LOT, no matter what language or programming style you use.
Quite wrong. Many languages have neither pointers nor object references (Fortran, Prolog, Haskell, etc.).
For instance, your stack now must be twice as large because each stack slot is 8 bytes instead of 4.
The stack is dominated by data, not by those two pointers, so that is insignificant (if it were signficant, it woul be easy to avoid, too).
Your page tables only hold half as many entries.
That depends on how they are represented. But it also really just doesn't matter because 4 bytes is a tiny fraction of the size of each allocated page, so even with a naive representation, the amortized cost is negligible.
In the Java world, typically half the heap is pointers and the other half is ints. (The other types are negligible.) So you should expect your heap to grow by 25% and put that much more pressure on your memory system.
In languages like C, C#, or Fortran, in high-performance, memory-critical code, the heap will be dominated by large chunks of non-pointer data (usually, multidimensional arrays or arrays of value classes).
Java doesn't let you define those, so people don't use them. That's why you see such lousy memory statistics. It's just one of the many ways in which Java sucks badly at high performance computing. No amount of tweaking the JITs (and Java JITs have become quite good) will fix such fundamental language problems.
However, in practice, apps recompiled for AMD64 extensions tend to run a bit faster than IA32 apps on the same hardware, because the benefit of the extra registers outweighs the costs of bloated pointers.
For high-performance native 64bit applications, people who know how to write for 64bit machines know what to do to avoid the hit.
For the rest of the applications, it just doesn't matter. It's just one thing among many about performance that mainstream programmers don't understand. So, most programmers will go on blithely programming an Athlon64 as if it were a PDP-11--so what. The kind of dregs we get for application software is already usually an order of magnitude less efficient than it should be, but as long as it runs on cheap hardware, it just isn't worth worrying about.
But they can't (and shouldn't) receive any of my tax dollars, like the predominantly leftist state universities and colleges do.
The rules by which public universities are operated are set by the legislatures, the people we all elect. If you don't like it, vote different people into office.
So::cough::diversity::cough::, we should allow the majority to rule? Like as in::cough::diversity::cough:: democracy?
No, that's not what I said. What I said is that our educational system supports a great variety of viewpoints and if you happen to espouse some oddball minority viewpoint, you can attend some university that caters to your particular fetishes.
But while our educational system can make those choices available, it can't guarantee that your choice will result in a good education.
There are plenty of schools that cater to whatever bizarre philosophies you espouse: Such as?.. Christian Oh, yeah, they're a buncha freaks, man.
Again, you seem to have trouble with simple reading comprehension; I simply pointed out that Christianity is a pretty bizarre concept to design a modern university curriculum around. But if you like, you can attend a Christian university. Just don't complain if you have trouble finding a good job afterwards.
FWIW, I was once a lefty, too. That lasted until I discovered rational thought, cause/effect relationships, and a conscience.
I'm not sure what that "too" is supposed to refer to; I have no political affiliation. But I point out B.S. when I see it, like the B.S. you keep spewing out.
Lefties blather on about "diversity", but wet the bed every time they're faced with an alternative to their holy doctrine of moral and cultural equivalence.
(American) "Lefties" don't have a "doctrine of moral and cultural equivalence". Quite to the contrary, they have quite clear and definitive moral and cultural stances, as you can clearly see from their rejection of your morality and culture.
Leadership is determined by who's got more out there, not by who's following whose standard.
No, the term "leadership" by itself is commonly understood to refer to "technical leadership", i.e., who sets the standard, not who moves more product. If there is any ambiguity, just be clear about it. In this case, from context, it should be clear that the term was used to talk about technical leadership.
By your definition, AMD could never ever achieve leadership position because it's usinng Intel's instructions.
The instructions Intel defined ten years ago don't help us determine who leads the industry now technically. What matters is recent changes, who made them, and who copied them.
AMD may be a threat, but it has not ousted Intel, not by a long shot.
And AMD may never "oust" Intel. But they can still be in a technical leadership position.
Repeat after me 64-bits does not magically change anything.
Even if you run just 32bit applications under 64bit Linux kernels on the Opteron, your 32bit applications magically get almost the full 4G address space to themselves, because the 64bit kernel can relocate itself out of the user's address space. That alone is enough justification for a 64bit x86 for many server applications.
The reasons these chips will most likely run apps faster is due to
Yes, and you know what those changes are there for? They are there because the chip supports 64bit instructions. Theoretically, you could put them into a 32bit-only chip, but that would make little sense. x86 chips can, after all, already address more than 4G of memory, so even the address lines are there. So, if you go through all the trouble of turning your chip into a full 64bit architecture, you might as well add the instructions to take advantage of it.
Think of it this way: the "64bit" moniker for the Opterons really tells you that they have been built as the next generation, fast 32bit architecture that uses wider data paths, and the 64bit instructions are just icing on the cake.
Yes, you heard right... slower. [...] More bits per instruction means
But you don't move more bits per instruction if you don't have to. The Opteron chips run 32bit code faster than previous Athlons. 64bit processors, even those without a legacy 32bit architecture attached, have instructions for manipulating 32bit data just fine. It is just that when your program needs to work with 64 bits at a time, it can do so more efficiently.
In fact, in well-written 64 bit code, the amount of additional memory used and data moved by the application should be small. Of course, in some C/C++ programming styles, pointers are everywhere, and those kinds of applications will almost double their memory usage and bandwidth--but that is fixable.
At this rate Windows will become as fragmented as Linux;-)
What do you think is "fragmented" about Linux? The Linux kernel is the same on every distribution. All major distributions have the same file system layout. The main thing distributions differ in is package management and pre-installed software, but Windows doesn't even really have package management, and the pre-installed software that ships with Windows differs from one PC model to the next.
And Windows manages to be this fragmented just in the consumer space. In addition to Windows XP/Home, we also have Windows XP/Professional, Windows XP/Embedded, the still-supported older versions (2000, NT, ME, 98), and Windows CE and its varieties (PPC, etc.).
Seems to me Windows is already far more "fragmented" than Linux.
The news piece ends by quoting Eidos CEO Mike McGarvey as suggesting: "A studio of about 150 people, split into three teams, is about the ideal size and it's hard to see how it makes sense for the cottage industry types. They may have more of a future in post-production as a service-based business."
McGarvey will be surprised when open source will start eating his lunch. First, industry insiders thought open source couldn't develop compilers, then kernels, then desktops, and they were proven wrong each time. It takes open source a decade or two to catch up, but it ultimately always does. The real question is: how long will Eidos make it?
they can do whatever they want, and so can you
on
What You Can't Say
·
· Score: 2, Insightful
Many universities are private institutions: they have wide latitude in designing their curricula, and they certainly can ban speech they don't like in many venues.
Furthermore, you have a choice in universities. If Berkeley restricts your speech too much, just attend some other school. There are plenty of schools that cater to whatever bizarre philosophies you espouse: Christian, racially pure, extremely right wing, libertarian, you name it. Of course, those schools are also the ones that aren't very highly regarded, and that's no coincidence.
If you want to attend Yale, Harvard, Stanford, etc., you have to put up with their culture. It's your choice.
Social scientists, philosophers, historians, and psychologists--the kind of "soft scientists" Graham would probably not give the time of day to--actually think about these issues long and hard and write essays that are far more probing and deep than Graham's fluff.
What's worse than a soft scientist? A soft amateur, which is what Graham seems to amount to in this piece.
A subsidy assumes you will invest your windfall, and in turn support me by buying from me when it comes time to spend what I've just given you. That's capitalism, not charity.
Product subsidies are government interference in the market. They are contrary to both capitalism and free markets.
No, product subsidies are not "charity"; "political corruption" would be a better term for them, in particular when it comes to farm subsidies.
You think the farming community in America wants the rest of the world to know they're being propped up? No way.
The rest of the world already knows--they'd have to be blind and deaf not to know: American agricultural subsidies are driving farmers around the world out of business and preventing other nations from developing.
It's Americans that still cling to idyllic but inaccurate notions that US farming has anything to do anymore with either capitalism or tradition. And population poor but powerful agricultural states just love to create that impression--it pays out handsomely for the land owners there.
I'll say it again. Food Stamps are to provide incentive to spend money on food...this props up the farming and food industry.
They were never meant to be welfare. This is another example of how the average American misunderstands welfare, etc.
Well, so food stamps are welfare--welfare for individual and corporate farmers. And, no, farmers need not be indigent to receive this kind of welfare. They also don't need to be indigent to receive their subsidies.
(What about computer stamps and computer subsidies to strengthen that sector of the economy?)
That's pretty much how Apple does it today, with the exception that Apple has been taking more advantage of some commodity components like drives (they always have) and highly integrated ICs.
Some commodity components? Judging by what happens when I boot Linux on my Mac, the machine is almost completely like a PC: graphics card, bus, drives, keyboard, mouse, etc. The main thing that seems custom about it is the case, the BIOS, and the use of a PPC chip, plus the little bit of hardware glue that probably entails.
Slashdot Mirror
Notably absent from this list is Apache, so I assume that they have worked out a special arrangement w/ Sun, since Tomcat is the servlet/jsp engine embedded in the J2EE RI.
Tomcat does not come close to implementing the J2EE spec, so why would Apache need a license from Sun?
Sun has never claimed that Java is "open" in the Open Source sense of the word.
No, but Sun has claimed that Java is "open" in the "open standards", and that is just not true. An "open standard" is a standard anybody can implement, with no licensing restrictions. ANSI C is an open standard. IEEE Scheme is an open standard. Java is not an open standard.
I cannot agree with your statement regarding the "legal minefield" of Java technology. What IP/Licensing cases (except JBoss/Apache - which was an affirmation of the LGPL) can you recall from the past year?
Actually, the fact that Sun is quietly putting these restrictions into their licenses and not asserting them is what makes them particularly worrisome. IP rights like that become particularly destructive if people (like you) come to believe that the standard can be implemented freely only to find out later that they were wrong.
What they can claim, is that the technology is developed implemented, and deployed in an open, industry accepted manner.
In different words, Sun gets other people to do technical development work for them for free and then creates a proprietary standard out of it. Sun is playing word games with the term "open". Frankly, at this point, I have to believe that they are deliberately deceptive rather than merely confused.
Keep in mind that many of the fortune 500 who are embracing Linux/OSS also have large investments in Java technology.
Yes, and the same Fortune 500 companies also have large investments in Microsoft Windows and IBM mainframes. Whether they invest in something is largely unrelated to whether it's proprietary, free, or open. And Fortune 500 companies have so much money to throw around that their purchases don't even tell you whether something is cost effective or even works. In different words, there is no logical connection between a company's use of Linux and a company's use of Java.
That explicitly tells you that you can't implement the specification without a license from Sun.
I suspect all the major J2EE providers have a license from Sun. The only successful attempt at an open source implementation was bullied by Sun into agreeing to Sun's legal terms (and even that implementation still required Sun's proprietary Java 2 implementation to run on anyway).
Sun is deliberately deceiving people when they claim that Java is open on the one hand and then publish specifications under such licenses on the other. Sun is creating a legal minefield around Java. Don't get lured in--it will blow up in your face.
You have forgotten that fraud, stock manipulation, and/or empty promises pay off--for a while. If you can time it right, you can get very wealthy from them. In fact, any meteoric rise in stock values is almost certainly too good to be based on reality, whether it's SCO, Microsoft, or your favorite Internet startup.
Wrong on the first count, right in the second but the very need for optimizations should give you a clue to what my concern is about that.
I guarantee you that your C pointer code will be uniformly no better than Fortran array code.
And, no, I don't understand what "your concern" is about, other than holding on to a totally obsolete, unsafe programming language that you happen to know.
You're confusing two entirely seperate issues. Debugging is an entirely different issue to being able to predict the behaviour of code. Without knowing the underlying basis of the code, I cannot do the latter. [...] Debugging can be fractionally easier in a 4G language, but that's not a substitute, or even the same ballpark, as being able to predict how a correctly written statement will execute.
You don't even understand the problem. It's not about debugging, it's about fault isolation. C doesn't have any. Once your code or any library you call has as much as referenced one past the end of an array, the language guarantees absolutely nothing anymore. There isn't even any indication that anything has gone wrong.
You have gotten so used to C's misfeatures that you don't even understand that things could be different.
Wow. So C isn't trendy enough. I get it now. Good grief.
Yes, indeed, C isn't "trendy" enough in the same way gas lighting isn't trendy enough: it's dangerous and it's completely obsolete.
No, you're not reading the thread. Go look at this which is the first mention of "high performance computing" and clearly refers to my comment about faster CPUs.
C is no good for "high performance computing", no matter which sense of the term you use. It isn't good for writing high performance desktop apps and it isn't good for writing high performance scientific apps (the more usual use of the term).
Note that a lot of the criticism involves non-open source technologies. J2EE, for example, manages to be as bloated and proprietary as anything from Microsoft. And, well, it's not exactly surprising that mainframes are expensive to buy and operate compared to Intel boxes no matter what they run--companies don't buy mainframes to save money on hardware or IT staff.
Most of the Linux successes involve humble, cheap little PC servers running no-frill software like Apache, PHP, or Perl. Microsoft and Sun need grand strategies, new APIs, and "breakthrough" technologies to get the job done, not to mention upgrading every other year, while Linux just gets the job done with boring, old, but proven software. Of course, you won't find that in any corporate-sponsored comparison.
Maybe Indian women aren't as shallow. Maybe there are enough that don't go for the biggest pecs and most expensive car but are actually happy dating someone with a steady, well-paying job who they can have a conversation with.
C is a good language for high-performance computing, as are most third generation languages. I'm baffled as to why you'd think "C gets in the way",
Because C pointers don't help with writing faster code, but their existence in the language inhibits a lot of optimizations.
Remember the context of this that lead to my original comment was the suggestion that people should ditch C and C++ for Python and Perl because some-how Python and Perl are "better".
No, it suggested using high-level languages in general. Which high level language is better depends on the application. Python is probably better for most desktop apps. C# and O'CAML are better for general purpose programming. Fortran (modern versions) is better for high performance numerical computing.
I love C's simplicity.
C appears to be simple because it has few constructs, but its semantics are horrendously complex. Think about all the different things a pointer can point to and how those things behave differently as the program executes.
I love knowing what my code is going to do and being able to predict its strengths and weaknesses.
But you "can't predict what your code is going to do"--that is, in fact, one of C's biggest weaknesses. Any bug in any library or anywhere in your code means that all bets are off as to the behavior of the rest of the program. Unlike most other high-level languages, C and C++ provide no means of isolating errors and recovering from them reliably.
I think well written C is, by itself, beautiful. Don't knock it, it's good stuff.
C was "good stuff" in the days of bell bottoms, PDP-11s, and 64k i-spaces. Even then, 20 years after Lisp and Algol and 10 years after Simula, C was "good stuff" only in a sort of second-hand chic way--look how much I can do with this dirt cheap compiler.
Personally, I like C. And to be honest, I always thought the advantage in having a faster CPU was that my programs could run faster.
Yeah, so why do you program in C? C is not a good language for high-performance computing. With a lot of work, you can often get decent performance out of it, but C gets in the way rather than helping you.
However, when it comes to statically type checked, non-C/C++ languages on Linux, there isn't much choice:
Overall, C# looks like the most promising to me: it combines the best features and simplicity of Java with most of the efficiency and C-interoperability of C++. Let's hope Mono will make it into all major Linux distributions soon.
They are being screwed and after a decade or so this logic is showing it's shortsightedness as the patrimony erodes. Today, our economy is more or less at a developing country's mercy, competing with underpaid (compared to our standards) labour, basically producing low tech gadgetry with little intrinsic value.
Wealth breeds complacency, but as long as they get what they want out of life, why worry? Once it doesn't work anymore, their children will start taking education more seriously again because they'll realize that they have to.
I can understand when Americans whine about this sort of thing because they don't have the historical perspective, but Italy, in particular, has been through many cycles of this over the millennia, and Italians should really know better than to worry about it.
Well, and once you move from 32bit to 64bit machines, those kinds of implementations may have to change if they want to avoid blowing up their heap by a factor of two. Or maybe they don't if their authors decide it doesn't matter. The point is that Prolog and Haskell don't expose pointer semantics and can be implemented efficiently without it. For Prolog, for example, the situation is similar to some of the tricks people developed for implementing it on a PDP-10 (big words, little memory).
What in the world are you talking about? I'm talking about the stack on an AMD64, where push and pop instructions always deal with 8-byte quantities.What do "push" and "pop" have to do with "the stack"?
"The stack" refers to the UNIX stack, the stack on which registers and local variables are saved. It is accessed using a wide variety of instructions, including stack-relative addressing, not just push/pop, and it isn't limited to 64bit quantities.
Sorry, I thought we were talking about AMD64.
You made a general statement about 64bit computing and I made a general response. As I was saying, more importantly, the amortized cost of the larger page table entries is tiny.
I think you're talking about scientific (loops-and-arrays) code that has been carefully optimized.
That's not just scientific code, it's database code, graphics code, data mining code, data structure libraries, kernel data structures, and any other place where performance matters.
(Incidentally, why do you think UNIX uses so many integer IDs, historically with fewer than 32 bits? File descriptors, signals, exit codes, process ids, and all that. They could all be pointers, like they are on Windows, but they aren't.)
I'll grant you that a 64-bit processor shouldn't be detrimental to that code. But there's a whack of OO-style code out there that is not dominated by arrays, and that code pays for 64 bits even if it doesn't need them.
Sure, there is a lot of badly written C code (pointer style code), ill-conceived programming paradigms (what passes for OOP), and a lot of incompetently designed programming languages (e.g., Java). But any overhead from 64bit computing is the least of your worries with that kind of software.
Overall, my points are simple:
Realistically, "outsourcing" just is the situation when software development is cheaper in India but their US-based management doesn't want to move there. The long term resolution to that is obviously not that software development comes back to the US, the long term resolution is that management also moves to India (or wherever).
It's really not that different from what happened in the electronics industry after all: initially, parts came from Japan, then whole devices, and now the companies themselves are Japanese. And it was the same with cars and computer hardware.
What should the US do? There is really only one choice: if it wants to retain its strong economic position, the US needs to start the next revolution in a different field. Maybe that's biotech, nanotechnology (whatever that is) or the commercialization of space. But anybody who wants to claim a leadership position can't lean back and say "we'd just like to lean back for a while and relax on the strength of the jobs we already created".
No, you're hosed when you use pointers, as you mention. Which is a LOT, no matter what language or programming style you use.
Quite wrong. Many languages have neither pointers nor object references (Fortran, Prolog, Haskell, etc.).
For instance, your stack now must be twice as large because each stack slot is 8 bytes instead of 4.
The stack is dominated by data, not by those two pointers, so that is insignificant (if it were signficant, it woul be easy to avoid, too).
Your page tables only hold half as many entries.
That depends on how they are represented. But it also really just doesn't matter because 4 bytes is a tiny fraction of the size of each allocated page, so even with a naive representation, the amortized cost is negligible.
In the Java world, typically half the heap is pointers and the other half is ints. (The other types are negligible.) So you should expect your heap to grow by 25% and put that much more pressure on your memory system.
In languages like C, C#, or Fortran, in high-performance, memory-critical code, the heap will be dominated by large chunks of non-pointer data (usually, multidimensional arrays or arrays of value classes).
Java doesn't let you define those, so people don't use them. That's why you see such lousy memory statistics. It's just one of the many ways in which Java sucks badly at high performance computing. No amount of tweaking the JITs (and Java JITs have become quite good) will fix such fundamental language problems.
However, in practice, apps recompiled for AMD64 extensions tend to run a bit faster than IA32 apps on the same hardware, because the benefit of the extra registers outweighs the costs of bloated pointers.
For high-performance native 64bit applications, people who know how to write for 64bit machines know what to do to avoid the hit.
For the rest of the applications, it just doesn't matter. It's just one thing among many about performance that mainstream programmers don't understand. So, most programmers will go on blithely programming an Athlon64 as if it were a PDP-11--so what. The kind of dregs we get for application software is already usually an order of magnitude less efficient than it should be, but as long as it runs on cheap hardware, it just isn't worth worrying about.
But they can't (and shouldn't) receive any of my tax dollars, like the predominantly leftist state universities and colleges do.
::cough::diversity::cough::, we should allow the majority to rule? Like as in ::cough::diversity::cough:: democracy?
The rules by which public universities are operated are set by the legislatures, the people we all elect. If you don't like it, vote different people into office.
So
No, that's not what I said. What I said is that our educational system supports a great variety of viewpoints and if you happen to espouse some oddball minority viewpoint, you can attend some university that caters to your particular fetishes.
But while our educational system can make those choices available, it can't guarantee that your choice will result in a good education.
There are plenty of schools that cater to whatever bizarre philosophies you espouse: Such as?.. Christian Oh, yeah, they're a buncha freaks, man.
Again, you seem to have trouble with simple reading comprehension; I simply pointed out that Christianity is a pretty bizarre concept to design a modern university curriculum around. But if you like, you can attend a Christian university. Just don't complain if you have trouble finding a good job afterwards.
FWIW, I was once a lefty, too. That lasted until I discovered rational thought, cause/effect relationships, and a conscience.
I'm not sure what that "too" is supposed to refer to; I have no political affiliation. But I point out B.S. when I see it, like the B.S. you keep spewing out.
Lefties blather on about "diversity", but wet the bed every time they're faced with an alternative to their holy doctrine of moral and cultural equivalence.
(American) "Lefties" don't have a "doctrine of moral and cultural equivalence". Quite to the contrary, they have quite clear and definitive moral and cultural stances, as you can clearly see from their rejection of your morality and culture.
Leadership is determined by who's got more out there, not by who's following whose standard.
No, the term "leadership" by itself is commonly understood to refer to "technical leadership", i.e., who sets the standard, not who moves more product. If there is any ambiguity, just be clear about it. In this case, from context, it should be clear that the term was used to talk about technical leadership.
By your definition, AMD could never ever achieve leadership position because it's usinng Intel's instructions.
The instructions Intel defined ten years ago don't help us determine who leads the industry now technically. What matters is recent changes, who made them, and who copied them.
AMD may be a threat, but it has not ousted Intel, not by a long shot.
And AMD may never "oust" Intel. But they can still be in a technical leadership position.
Repeat after me 64-bits does not magically change anything.
Even if you run just 32bit applications under 64bit Linux kernels on the Opteron, your 32bit applications magically get almost the full 4G address space to themselves, because the 64bit kernel can relocate itself out of the user's address space. That alone is enough justification for a 64bit x86 for many server applications.
The reasons these chips will most likely run apps faster is due to
Yes, and you know what those changes are there for? They are there because the chip supports 64bit instructions. Theoretically, you could put them into a 32bit-only chip, but that would make little sense. x86 chips can, after all, already address more than 4G of memory, so even the address lines are there. So, if you go through all the trouble of turning your chip into a full 64bit architecture, you might as well add the instructions to take advantage of it.
Think of it this way: the "64bit" moniker for the Opterons really tells you that they have been built as the next generation, fast 32bit architecture that uses wider data paths, and the 64bit instructions are just icing on the cake.
Yes, you heard right... slower. [...] More bits per instruction means
But you don't move more bits per instruction if you don't have to. The Opteron chips run 32bit code faster than previous Athlons. 64bit processors, even those without a legacy 32bit architecture attached, have instructions for manipulating 32bit data just fine. It is just that when your program needs to work with 64 bits at a time, it can do so more efficiently.
In fact, in well-written 64 bit code, the amount of additional memory used and data moved by the application should be small. Of course, in some C/C++ programming styles, pointers are everywhere, and those kinds of applications will almost double their memory usage and bandwidth--but that is fixable.
At this rate Windows will become as fragmented as Linux ;-)
What do you think is "fragmented" about Linux? The Linux kernel is the same on every distribution. All major distributions have the same file system layout. The main thing distributions differ in is package management and pre-installed software, but Windows doesn't even really have package management, and the pre-installed software that ships with Windows differs from one PC model to the next.
And Windows manages to be this fragmented just in the consumer space. In addition to Windows XP/Home, we also have Windows XP/Professional, Windows XP/Embedded, the still-supported older versions (2000, NT, ME, 98), and Windows CE and its varieties (PPC, etc.).
Seems to me Windows is already far more "fragmented" than Linux.
The news piece ends by quoting Eidos CEO Mike McGarvey as suggesting: "A studio of about 150 people, split into three teams, is about the ideal size and it's hard to see how it makes sense for the cottage industry types. They may have more of a future in post-production as a service-based business."
McGarvey will be surprised when open source will start eating his lunch. First, industry insiders thought open source couldn't develop compilers, then kernels, then desktops, and they were proven wrong each time. It takes open source a decade or two to catch up, but it ultimately always does. The real question is: how long will Eidos make it?
Many universities are private institutions: they have wide latitude in designing their curricula, and they certainly can ban speech they don't like in many venues.
Furthermore, you have a choice in universities. If Berkeley restricts your speech too much, just attend some other school. There are plenty of schools that cater to whatever bizarre philosophies you espouse: Christian, racially pure, extremely right wing, libertarian, you name it. Of course, those schools are also the ones that aren't very highly regarded, and that's no coincidence.
If you want to attend Yale, Harvard, Stanford, etc., you have to put up with their culture. It's your choice.
Social scientists, philosophers, historians, and psychologists--the kind of "soft scientists" Graham would probably not give the time of day to--actually think about these issues long and hard and write essays that are far more probing and deep than Graham's fluff.
What's worse than a soft scientist? A soft amateur, which is what Graham seems to amount to in this piece.
A subsidy assumes you will invest your windfall, and in turn support me by buying from me when it comes time to spend what I've just given you. That's capitalism, not charity.
Product subsidies are government interference in the market. They are contrary to both capitalism and free markets.
No, product subsidies are not "charity"; "political corruption" would be a better term for them, in particular when it comes to farm subsidies.
You think the farming community in America wants the rest of the world to know they're being propped up? No way.
The rest of the world already knows--they'd have to be blind and deaf not to know: American agricultural subsidies are driving farmers around the world out of business and preventing other nations from developing.
It's Americans that still cling to idyllic but inaccurate notions that US farming has anything to do anymore with either capitalism or tradition. And population poor but powerful agricultural states just love to create that impression--it pays out handsomely for the land owners there.
I'll say it again. Food Stamps are to provide incentive to spend money on food...this props up the farming and food industry.
They were never meant to be welfare. This is another example of how the average American misunderstands welfare, etc.
Well, so food stamps are welfare--welfare for individual and corporate farmers. And, no, farmers need not be indigent to receive this kind of welfare. They also don't need to be indigent to receive their subsidies.
(What about computer stamps and computer subsidies to strengthen that sector of the economy?)
That's pretty much how Apple does it today, with the exception that Apple has been taking more advantage of some commodity components like drives (they always have) and highly integrated ICs.
Some commodity components? Judging by what happens when I boot Linux on my Mac, the machine is almost completely like a PC: graphics card, bus, drives, keyboard, mouse, etc. The main thing that seems custom about it is the case, the BIOS, and the use of a PPC chip, plus the little bit of hardware glue that probably entails.