Support for variant symbolic links is exciting. That makes it really easy to support 64/32-bit modes on Opteron systems. Similarly, it makes it easy to support variant ABIs for (e.g.) C++ runtime environments without encoding ABI versions into library names, but do look out for combinatorial explosion...
Until very recently, every Windows machine was shipped with a JVM. Read what I had posted - I did not say machines where necessarily shipped with VMs - I said they were often pre-installed in organisations so that users could run Java software.
Again, you still have the problem of identifying for any particular program which of several JVMs it should use, and installing that one if it has not been already.
"Meanwhile, most machines have libstdc++.so and a variety of other libraries -- along with a plethora of C++ programs."
Yes, but *which* libstdc++.so? If you are installing software, this matters.
If it is handled completely by apt-get, it can't be a language problem, can it?
"So, I have the latest one from Sun, and the latest one from IBM, and whichever one Oracle wants its installer to run on"
These are all compatible. For virtually all software, there is no difference. That is the whole point of Java.
That's the whole myth of Java. The fact is that they aren't really compatible, and Oracle's installer only works on certain JVMs. Why do people say, "Write once, test everywhere"? In practice, nobody tests everywhere, they say which JVM their program works with.
"the spurious early 90s claims that C++ code is slower than C code."
Its not spurious - the speed difference, particularly in matters of inheritance and method lookup, was the subject of a lot of academic study.
Who do you think you're fooling? (Are you deluded yourself?) There are no secrets to how the language is implemented, and what code is generated. Anybody wasting time on "academic study" was just trying to muddy the water.
(Yes, there were bad early implementations that linked in data and/or code unnecessarily, bloating the memory footprint, or failed to optimize inline functions properly. Somehow I don't think a Java person would want to dwell on the subject of bad early implementations.)
"These "virtual methods with dynamic lookups" are nothing but calls through function pointers."
No, they are look-up tables, and the lookup has to be done at run time.
Ooh, an array-lookup per virtual call, and at runtime. Shiver me timbers! Virtual function calls are used where a C program would use switch statements, with just about the same runtime cost (and, indeed, instruction sequence). But you knew this already, or should have.
"Memory leaks are a management failure."
In the previous post, it was stated that they had to be actively produced by the coder due to the new features of C++.
It's a management failure if coders continue writing C when they have access to C++ language and library features. Indeed, that was one of the problems in the Netscape code base.
"the reason Java offers no alternative..."
Just not true. I can ensure that memory is tidied up any time I like, by manually removing references to objects. Look:
myObject = null;
That will do it!
That looks manual to me, about equivalent to a "delete" statement. Furthermore, and more to the point, it only works when the only resource is memory. There are niches where memory is the only resource, and GC and GC-dependent languages can work fine in them (subject to locality problems). Break out of those niches, and you find yourself managing lots of other resources. In Java, as in LISP, you must do it "by hand", no different from C.
Anticipating the usual "two-step", you will argue that other resources are manipulated so infrequently that this doesn't matter. Of course, in certain niches that's more or less true.
Most people who use java either use the pre-installed VMs for applets, or have the VMs installed for them in their work environment. I suppose to run C++ programs you need nothing whatever installed? No libaries? Just the linux kernel on a bare machine?
I don't know of any machine but a Sun that comes with a JVM. Meanwhile, most machines have libstdc++.so and a variety of other libraries -- along with a plethora of C++ programs. Of course you are not obliged to notice what language they're written in.
As for your comment about versions, that is just silly. You get the latest stable VM from Sun or IBM or whatever, and it runs the java binary. Apart from highly specialised system software, this simply just works. Your comment about 'half a dozen other VMs' is daft exaggeration - that has never been the case, and you know it. Java is one of the most backward-compatible systems ever developed.
So, I have the latest one from Sun, and the latest one from IBM, and which ever one Oracle wants its installer to run on, and some older versions for the programs that break when you try to run with the new one.
Mozilla is not interpreted. XUL is a language for describing user interfaces. Virtually all of Mozilla is C++. Mozilla does not seem slow because teams of skilled developers have worked on it, and because processor speeds have improved about 5x since it was first launched.
You seem to parroting, again, the spurious early 90s claims that C++ code is slower than C code. Much of the Mozilla UI is XUL. Lots of it isn't. It was slow, now it isn't, but it's still C++ (sort of) and XUL.
"The compilers generate the same code for the same constructs, C or C++. C++ coders have access to a very rich standard library (not to mention other libraries) in which it would actually be extra work to write code with buffer overruns."
True, but as you say below, C++ users don't use the same constructs! They use virtual methods with dynamic lookups, operator overloading, class libraries and run-time type information. These are not C constructs.
Now you are confusing source code with machine code. These "virtual methods with dynamic lookups" are nothing but calls through function pointers. "Operator overloading and class libraries" are just ordinary function calls, except where they are inline and more resemble macros. The source code is different, the machine code is the same.
People make more mistakes writing code without effective library support, as they must in C. A good language and library help prevent those mistakes without adding overhead. The better source code resolves to the same code that a better coder would have had to write out the hard way.
If C++ is so good, then why is is that so much C++ code does suffer buffer overruns? Why are there memory leaks?
You must be talking about Microsoft code. Memory leaks are a management failure. At Microsoft a memory leak is considered no big deal, because it all gets cleaned up in the next system crash. Now that's garbage collection!
You are seriously overestimating the way most C++ is written. Most C++ was, for a long time, written very much like C, and used C libraries.
It still is, particularly in Microsoft-land -- and in Mozilla, actually.
Nobody can help that lots of bad code is written. Probably each of Java and C++ has more bad code written in it than the other. The difference is that in Java you frequently have no choice but to write bad code, because the language offers no alternative.
Getting back on topic, though, the reason Java offers no alternative is that it lacks the resource-management tools that C++ has, viz. destructors and automatic scoped local-variable and member destruction.
The original report (anonymously) parrots common propaganda in favor of garbage collection. In fact, people who think Java is slow think so because when they run real Java programs, they find that real Java programs really do run slowly. The question why has lots of good, easily articulated answers, having to do with virtual memory locality, and cache locality, and cache poisoning, and even hard-to-avoid misconfiguration. (Do you know how much memory to tell your Java runtime to allow each of your programs to use?)
Nobody complains that C++ programs are slow, because they aren't. Nobody is obliged to notice they are C++ programs, because they are easy to install, and they just work. They don't call much attention to themselves, because they rarely suffer from the security flaws common to C programs. (Some people think C++ iostreams are slow, but gcc-3.4's iostreams are as fast as, and often much faster than, libc equivalents; the slowness turned out to be just a bad implementation, now fixed.)
In principle a really good garbage collector might not be slow, for certain common kinds of jobs, However, Java runtimes generally can't use those garbage collectors; they have to use the slow ones instead. Haskell is supposed to be (uniquely) very good at helping its GC maintain locality, but that doesn't matter much because Haskell is slow anyway.
The presence of garbage collection actually prevents the language from offering the kind of automated, encapsulated resource management uniquely possible in C++, leaving coders to use essentially C-like management for resources other than memory. Does garbage collection really carry its weight? It has been years since I last coded a "delete" statement. What could GC possibly do for me, to make up for eliminating the most useful library idioms I have?
GC propaganda is common in academic Computer Science departments, but real programs are built by engineers who are not fooled. LISP has failed to take the world by storm, decade after decade, for sound reasons, just like so many more-modern languages also crippled by GC and LISP apologia. GC doesn't just automate memory management; dependence on it automatically confines the language to niche uses.
You can tell a bad benchmark because it seems to show that languages you already know are slow aren't.
That Pascal was so pervasive, so thoroughly entrenched, taught in universities, implemented everywhere, and yet has washed away so nearly completely gives me hope. Java is in the same position today, is even more pigheadedly designed, and suffers the additional handicap of being proprietary and having no public conformance standard.
I'm confident nobody will be using Java, either, ten years from now.
It would be stupid to make a CLR backend for Gcc. Native code is a Good Thing, in the Free Software world. When MS comes around enforcing their patents on CLI, those people suckered into writing their code in C# will be glad to have a way to run it that can't be threatened by Microsoft.
You can't even get the GNOMies to consider compiling the core libraries with G++. If they did, the core code could be enabled to field exceptions from user callbacks in other languages (including C++ and Java, and probably C# if anybody would bother to write a native Gcc front-end for it). Then there would be a lot less pressure to force that stuff into the core.
Of course the core libraries, and the apps too, would all be a lot less leaky and crashy if they were actually written in C++, but superstition rules all.
Hm, that's not what Nat said in the interview I read last month, or what I have been getting from the Advogato diary entries of the developers. Here's hoping you're right.
The state doesn't put up those "slower traffic keep right" signs. The auto club buys and places them, with the cooperation of the state.
I once drove from Portland to Seattle (~200 mi) and averaged 90 mph, including driving at the speed limit (55, then) through the speed traps. Of course I had to go over 100 mph the rest of the time to make up the difference...
First, tracing the origins of code is exactly zero help in a patent fight. Either you're infringing or you're not, and the only question is whether the original patent is valid. That depends, generally, on code that has nothing to do with the project under attack.
Second, we still have no public record of the resolution of AT&T vs UCB, only one-sided anecdotes. In any case, SCO vs. IBM resembles it not at all (as much as SCO tries to paint it so), and none of the affirmative defenses UCB used (and won with) apply (a fact that SCO's dupes seem to count on).
There is no such thing as "intellectual property", and using the term can only confuse you. Lawyers may like confused clients -- and confused defendants, even better -- but confusing yourself doesn't help Free Software.
The most important lesson they teach in what used to be the War College is, "Don't fight the last war". The next attack will be over something else entirely, because IBM has already shown that attacking the Linux kernel via copyright is too hard. The smart money is on patent attacks, most likely on some key non-kernel component (e.g. GNOME).
Who says we're stuck with dotnet? Most Free Software machines have no JVM installed, and most will have no more reason to have a CLI either. Just about anything you can do with either (i.e. anything except talk to other, proprietary, components), you can do better natively, in a language not specifically crippled to advance crabbed corporate interests.
The real lesson of this "superfast Python" is not that dotnet is a fast platform; it's the more prosaic observation that regular Python still has a great deal of room for improvement. Those Python weenies ought to get on it, and save adding LISPy new features for later.
Packaging policy has more effect on the user experience than any of the topics normally mentioned in a review. Only one distribution really distinguishes itself, there.
I wrote about this some time back, in "It's All in the Packaging". Of course, it was written before there was a Gentoo. Gentoo has policies but not (particularly) packages, yet similar considerations apply.
Any language which isn't procedural is "academia only".
Hardly. Still, academia's criteria for language merit certainly do discount the ability (and inability) to abstract and encapsulate resource management, as we have seen demonstrated repeatedly right here. A non-procedural language that also provides the tools to abstract out resource management is certainly possible. The problem is just that there aren't any yet. (Mercury might be an exception.) When a better language that can solve the problems that C++ does comes along, we will all embrace it eagerly. Unfortunately, Lisp ain't it, and neither is O'Caml, nor Erlang.
Actually, ["with-this-and-that" etc.] solve a fairly large proportion of resource management problems.
Of course, in C++ as well. However, let us not be distracted from the point: they remain utterly insufficient to encapsulate management of library implementation resources. We can invent dozens of other tricks that also don't solve the problem, but to mention them would only amount to more wriggling.
Most abstractions don't leak. Some people like to say all do, but that is because they only notice the ones that do, and (in Joel's case) because they spend much of their time working around buggy vendor libraries. (Bugs leak.) When was the last time the quantum behavior of transistors leaked into your code?
you almost never see declarative programmers (ML, Haskell, Prolog, Scheme, whatever) having to do this. That's why I think it's the mix of GC and imperative programming which causes these odd issues rather than just GC.
In fact, most programs in those languages never need to manage anything but memory. Academia is like that. When they do have to manage other resources, they do it manually, pretty much like C, and Java. The problem is not, at base, GC. C has no GC, and C programmers suffer the same resource management problems as functional programmers do -- with the same leaks, and the same ill-localized handler code. GC is an attempt (successful, for purely academic uses) to paper over the hole.
Lisp's "with-this-and-that" and C#'s "using" construct also just paper over the hole -- they simply cannot help encapsulate management of resources that must live after the function that created them returns, so cannot be used to help write a library that yields constructs that depend on a limited resource, and manages it without further manual help from the client. Java's "finally" does no encapsulation either, it's just another notation for manual management.
While GC isn't, at base, the problem, it does interfere with
(somebody said "preclude") the constructs that are necessary to solve the problem. Tying resource lifetime to object lifetime is the only effective means I know of to enable a solution, the "resource acquisition-is-initialization" discipline. Splitting out memory management means that there is no place to bind the other resource management apparatus.
The problem really is fundamental. No amount of writhing or wiggling can fill in the hole. The only question is, are you honest enough to look at the problem without blinking? In my experience, among functional programmers, Lisp people are the least willing to face it honestly, and the OCaml people are the most willing.
Lisps' with-open-file and the like are a good adaptation to the lack of more complete facilities. That you mention them, though, emphasizes that lack. Although they allow you to bound the use of a resource lexically, stackwise, they don't allow you to encapsulate lifetime other than lexically. In particular, they don't help you to (e.g.) open the file as part of a library function that returns an object, and arrange to have the file closed automatically when the object, some time later, is no longer needed, even if that object's own lifetime is lexically bound.
This inability to encapsulate resource management is fundamental in Lisp, so no amount of tricksiness helps much.
The ultimate result is that when a Lisp program manages resources, it manages them manually, pretty much like C.
As with most such presentations, this article sweeps under the rug most of the reasons why languages dependent on garbage collection have always failed to find much deployment in industrial settings.
A previous poster noted that most GC algorithms are distinctly unfriendly to virtual memory systems. They usually have similar problems with cache locality, which can result in an enormous slowdown, regardless of the time actually spent in the GC itself. A practical problem is that GC regimes are notoriously non-portable, so that each new language implementation needs to have the (increasingly complex) GC re-done again.
A more fundamental problem is that memory is only one of many resources a typical industrial program must manage. GC takes over memory management, but leaves the other scarce resources -- file descriptors, sockets, mutexes, database connections -- to be managed manually, as in C. (Java has this problem,
for instance.) "Finalization" simply cannot provide the necessary guarantees.
Given a resource management regime that can handle all these other important resources, as is commonly practiced in C++, memory becomes just another resource. Management is encapsulated the same way for all. A language that lacks the tools necessary to implement such a regime needs GC, so the presence of GC may actually (as in the case of Java) indicate a fundamental weakness in the language.
(Anybody who thinks languages like Haskell or ML are fundamentally more powerful than C++ must be unaware of the Boost Lambda library, and of FC++, a set of header files that implements Haskell language semantics for C++ programs. They get along fine without GC, as well.)
What about me? I get 70+ MB of viruses every day, apparently because some virus writer decided to target people on the Gcc development lists. Besides our bombardment with the viruses, everybody else who gets the viruses sees our addresses in the return address.
I use nkvir-rc under procmail to filter them, which leaves only a few dozen bounce messages per day from sites that got viruses with my return address on them. I have amended nkvir-rc to work properly with Maildir-style mailboxes. (Probably the next released version will have these improvements.)
I don't know about the other bundled compilers, but the 3.4 C++ compiler and library are the best ever in Gcc, by far.
If you run across them, be sure to thank Paolo Carlini, Petur Runolfsson, and Jerry Quinn for making 3.4 iostreams as fast as (and often faster than) Glibc's stdio. Thank them, too for making filebuf support large files (>2G) natively without any code or build changes needed, on any target that allows them.
Worth noting, too, is that this is the first release in which the library is part of the ABI. Every previous release since 2.95 has had to increment the libstdc++.so version number, but future 3.4 (and maybe 3.5) releases should be backward compatible. Ask your distribution maintainers to ship 3.4-built versions of all C++ libraries they package, so that they will be compatible with programs built with this and future releases.
The other funny thing is that it seems as if when he installed ALSA and got it working, he just missed setting the default volume, so when he rebooted, it was set back to zero. Then he gave up, even though ALSA was the only way that had ever worked for him, and he never installed with ALSA again.
We do have to admit that it's pretty stupid for the default configuration to have zero volume.
There's no substitute for power to operate a refrigeration system, and lots of it. If you can't afford batteries, you need enough solar panels for the peak draw from the cooling
system, which would cost a lot more, and you might not have
room for so many.
You might be lucky, and have access to lots of ground water.
If so, you might be able to pump it through the system
with much less power than a regular cooling system needs.
If you have a big enough installation and live in a place
that is cold enough in winter, you can make your own
Taylor slush pond/tank. For one of those, you spray
brine in the air in winter and collect the runoff into
a deep pond or tank, circulating it until spring or
until it's almost frozen solid, and then circulate cold
water from it all summer.
This is like Python, except it's less portable (because JVMs are less widely ported than Python), and has a bigger memory footprint (because it uses JVM garbage collection instead of
Python reference-counting), and it uses libraries with
different actual semantics and different bugs on different platforms (because they're the Java libraries).
It sounds to me like anywhere you think you want this, you would be better off with actual Python.
What you want is a Relax-NG Schema. DTDs only define the
barest bones of XML structure. Validating against a schema
lets you verify all kinds of things that a DTD can't even
express.
(Don't be confused by W3C Schemas. That format stinks.)
Is a schema important for documentation? It depends on how much structure you need, which largely depends on how many uses you have for the documents. My employer actually puts the documentation itself in the schema, and generates manuals from the same text that validates important input files.
Slashdot Mirror
Support for variant symbolic links is exciting. That makes it really easy to support 64/32-bit modes on Opteron systems. Similarly, it makes it easy to support variant ABIs for (e.g.) C++ runtime environments without encoding ABI versions into library names, but do look out for combinatorial explosion...
Again, you still have the problem of identifying for any particular program which of several JVMs it should use, and installing that one if it has not been already.
"Meanwhile, most machines have libstdc++.so and a variety of other libraries -- along with a plethora of C++ programs."
Yes, but *which* libstdc++.so? If you are installing software, this matters.
If it is handled completely by apt-get, it can't be a language problem, can it?
"So, I have the latest one from Sun, and the latest one from IBM, and whichever one Oracle wants its installer to run on"
These are all compatible. For virtually all software, there is no difference. That is the whole point of Java.
That's the whole myth of Java. The fact is that they aren't really compatible, and Oracle's installer only works on certain JVMs. Why do people say, "Write once, test everywhere"? In practice, nobody tests everywhere, they say which JVM their program works with.
"the spurious early 90s claims that C++ code is slower than C code."
Its not spurious - the speed difference, particularly in matters of inheritance and method lookup, was the subject of a lot of academic study.
Who do you think you're fooling? (Are you deluded yourself?) There are no secrets to how the language is implemented, and what code is generated. Anybody wasting time on "academic study" was just trying to muddy the water.
(Yes, there were bad early implementations that linked in data and/or code unnecessarily, bloating the memory footprint, or failed to optimize inline functions properly. Somehow I don't think a Java person would want to dwell on the subject of bad early implementations.)
"These "virtual methods with dynamic lookups" are nothing but calls through function pointers."
No, they are look-up tables, and the lookup has to be done at run time.
Ooh, an array-lookup per virtual call, and at runtime. Shiver me timbers! Virtual function calls are used where a C program would use switch statements, with just about the same runtime cost (and, indeed, instruction sequence). But you knew this already, or should have.
"Memory leaks are a management failure."
In the previous post, it was stated that they had to be actively produced by the coder due to the new features of C++.
It's a management failure if coders continue writing C when they have access to C++ language and library features. Indeed, that was one of the problems in the Netscape code base.
"the reason Java offers no alternative..."
Just not true. I can ensure that memory is tidied up any time I like, by manually removing references to objects. Look:
myObject = null;
That will do it!
That looks manual to me, about equivalent to a "delete" statement. Furthermore, and more to the point, it only works when the only resource is memory. There are niches where memory is the only resource, and GC and GC-dependent languages can work fine in them (subject to locality problems). Break out of those niches, and you find yourself managing lots of other resources. In Java, as in LISP, you must do it "by hand", no different from C.
Anticipating the usual "two-step", you will argue that other resources are manipulated so infrequently that this doesn't matter. Of course, in certain niches that's more or less true.
I don't know of any machine but a Sun that comes with a JVM. Meanwhile, most machines have libstdc++.so and a variety of other libraries -- along with a plethora of C++ programs. Of course you are not obliged to notice what language they're written in.
As for your comment about versions, that is just silly. You get the latest stable VM from Sun or IBM or whatever, and it runs the java binary. Apart from highly specialised system software, this simply just works. Your comment about 'half a dozen other VMs' is daft exaggeration - that has never been the case, and you know it. Java is one of the most backward-compatible systems ever developed.
So, I have the latest one from Sun, and the latest one from IBM, and which ever one Oracle wants its installer to run on, and some older versions for the programs that break when you try to run with the new one.
Mozilla is not interpreted. XUL is a language for describing user interfaces. Virtually all of Mozilla is C++. Mozilla does not seem slow because teams of skilled developers have worked on it, and because processor speeds have improved about 5x since it was first launched.
You seem to parroting, again, the spurious early 90s claims that C++ code is slower than C code. Much of the Mozilla UI is XUL. Lots of it isn't. It was slow, now it isn't, but it's still C++ (sort of) and XUL.
"The compilers generate the same code for the same constructs, C or C++. C++ coders have access to a very rich standard library (not to mention other libraries) in which it would actually be extra work to write code with buffer overruns."
True, but as you say below, C++ users don't use the same constructs! They use virtual methods with dynamic lookups, operator overloading, class libraries and run-time type information. These are not C constructs.
Now you are confusing source code with machine code. These "virtual methods with dynamic lookups" are nothing but calls through function pointers. "Operator overloading and class libraries" are just ordinary function calls, except where they are inline and more resemble macros. The source code is different, the machine code is the same.
People make more mistakes writing code without effective library support, as they must in C. A good language and library help prevent those mistakes without adding overhead. The better source code resolves to the same code that a better coder would have had to write out the hard way.
If C++ is so good, then why is is that so much C++ code does suffer buffer overruns? Why are there memory leaks?
You must be talking about Microsoft code. Memory leaks are a management failure. At Microsoft a memory leak is considered no big deal, because it all gets cleaned up in the next system crash. Now that's garbage collection!
You are seriously overestimating the way most C++ is written. Most C++ was, for a long time, written very much like C, and used C libraries.
It still is, particularly in Microsoft-land -- and in Mozilla, actually.
Nobody can help that lots of bad code is written. Probably each of Java and C++ has more bad code written in it than the other. The difference is that in Java you frequently have no choice but to write bad code, because the language offers no alternative.
Getting back on topic, though, the reason Java offers no alternative is that it lacks the resource-management tools that C++ has, viz. destructors and automatic scoped local-variable and member destruction.
Nobody complains that C++ programs are slow, because they aren't. Nobody is obliged to notice they are C++ programs, because they are easy to install, and they just work. They don't call much attention to themselves, because they rarely suffer from the security flaws common to C programs. (Some people think C++ iostreams are slow, but gcc-3.4's iostreams are as fast as, and often much faster than, libc equivalents; the slowness turned out to be just a bad implementation, now fixed.)
In principle a really good garbage collector might not be slow, for certain common kinds of jobs, However, Java runtimes generally can't use those garbage collectors; they have to use the slow ones instead. Haskell is supposed to be (uniquely) very good at helping its GC maintain locality, but that doesn't matter much because Haskell is slow anyway.
The presence of garbage collection actually prevents the language from offering the kind of automated, encapsulated resource management uniquely possible in C++, leaving coders to use essentially C-like management for resources other than memory. Does garbage collection really carry its weight? It has been years since I last coded a "delete" statement. What could GC possibly do for me, to make up for eliminating the most useful library idioms I have?
GC propaganda is common in academic Computer Science departments, but real programs are built by engineers who are not fooled. LISP has failed to take the world by storm, decade after decade, for sound reasons, just like so many more-modern languages also crippled by GC and LISP apologia. GC doesn't just automate memory management; dependence on it automatically confines the language to niche uses.
You can tell a bad benchmark because it seems to show that languages you already know are slow aren't.
C is already passé, outside of restricted domains like Unix kernels and GNOME. Unfortunately, C++ inherited "signed char".
That Pascal was so pervasive, so thoroughly entrenched, taught in universities, implemented everywhere, and yet has washed away so nearly completely gives me hope. Java is in the same position today, is even more pigheadedly designed, and suffers the additional handicap of being proprietary and having no public conformance standard. I'm confident nobody will be using Java, either, ten years from now.
It would be stupid to make a CLR backend for Gcc. Native code is a Good Thing, in the Free Software world. When MS comes around enforcing their patents on CLI, those people suckered into writing their code in C# will be glad to have a way to run it that can't be threatened by Microsoft.
Of course the core libraries, and the apps too, would all be a lot less leaky and crashy if they were actually written in C++, but superstition rules all.
Hm, that's not what Nat said in the interview I read last month, or what I have been getting from the Advogato diary entries of the developers. Here's hoping you're right.
I once drove from Portland to Seattle (~200 mi) and averaged 90 mph, including driving at the speed limit (55, then) through the speed traps. Of course I had to go over 100 mph the rest of the time to make up the difference...
Second, we still have no public record of the resolution of AT&T vs UCB, only one-sided anecdotes. In any case, SCO vs. IBM resembles it not at all (as much as SCO tries to paint it so), and none of the affirmative defenses UCB used (and won with) apply (a fact that SCO's dupes seem to count on).
There is no such thing as "intellectual property", and using the term can only confuse you. Lawyers may like confused clients -- and confused defendants, even better -- but confusing yourself doesn't help Free Software.
The most important lesson they teach in what used to be the War College is, "Don't fight the last war". The next attack will be over something else entirely, because IBM has already shown that attacking the Linux kernel via copyright is too hard. The smart money is on patent attacks, most likely on some key non-kernel component (e.g. GNOME).
The real lesson of this "superfast Python" is not that dotnet is a fast platform; it's the more prosaic observation that regular Python still has a great deal of room for improvement. Those Python weenies ought to get on it, and save adding LISPy new features for later.
A Python front end for Gcc could be fun.
I wrote about this some time back, in "It's All in the Packaging". Of course, it was written before there was a Gentoo. Gentoo has policies but not (particularly) packages, yet similar considerations apply.
Hardly. Still, academia's criteria for language merit certainly do discount the ability (and inability) to abstract and encapsulate resource management, as we have seen demonstrated repeatedly right here. A non-procedural language that also provides the tools to abstract out resource management is certainly possible. The problem is just that there aren't any yet. (Mercury might be an exception.) When a better language that can solve the problems that C++ does comes along, we will all embrace it eagerly. Unfortunately, Lisp ain't it, and neither is O'Caml, nor Erlang.
Actually, ["with-this-and-that" etc.] solve a fairly large proportion of resource management problems.
Of course, in C++ as well. However, let us not be distracted from the point: they remain utterly insufficient to encapsulate management of library implementation resources. We can invent dozens of other tricks that also don't solve the problem, but to mention them would only amount to more wriggling.
Most abstractions don't leak. Some people like to say all do, but that is because they only notice the ones that do, and (in Joel's case) because they spend much of their time working around buggy vendor libraries. (Bugs leak.) When was the last time the quantum behavior of transistors leaked into your code?
In fact, most programs in those languages never need to manage anything but memory. Academia is like that. When they do have to manage other resources, they do it manually, pretty much like C, and Java. The problem is not, at base, GC. C has no GC, and C programmers suffer the same resource management problems as functional programmers do -- with the same leaks, and the same ill-localized handler code. GC is an attempt (successful, for purely academic uses) to paper over the hole.
Lisp's "with-this-and-that" and C#'s "using" construct also just paper over the hole -- they simply cannot help encapsulate management of resources that must live after the function that created them returns, so cannot be used to help write a library that yields constructs that depend on a limited resource, and manages it without further manual help from the client. Java's "finally" does no encapsulation either, it's just another notation for manual management.
While GC isn't, at base, the problem, it does interfere with (somebody said "preclude") the constructs that are necessary to solve the problem. Tying resource lifetime to object lifetime is the only effective means I know of to enable a solution, the "resource acquisition-is-initialization" discipline. Splitting out memory management means that there is no place to bind the other resource management apparatus.
The problem really is fundamental. No amount of writhing or wiggling can fill in the hole. The only question is, are you honest enough to look at the problem without blinking? In my experience, among functional programmers, Lisp people are the least willing to face it honestly, and the OCaml people are the most willing.
This inability to encapsulate resource management is fundamental in Lisp, so no amount of tricksiness helps much. The ultimate result is that when a Lisp program manages resources, it manages them manually, pretty much like C.
A previous poster noted that most GC algorithms are distinctly unfriendly to virtual memory systems. They usually have similar problems with cache locality, which can result in an enormous slowdown, regardless of the time actually spent in the GC itself. A practical problem is that GC regimes are notoriously non-portable, so that each new language implementation needs to have the (increasingly complex) GC re-done again.
A more fundamental problem is that memory is only one of many resources a typical industrial program must manage. GC takes over memory management, but leaves the other scarce resources -- file descriptors, sockets, mutexes, database connections -- to be managed manually, as in C. (Java has this problem, for instance.) "Finalization" simply cannot provide the necessary guarantees.
Given a resource management regime that can handle all these other important resources, as is commonly practiced in C++, memory becomes just another resource. Management is encapsulated the same way for all. A language that lacks the tools necessary to implement such a regime needs GC, so the presence of GC may actually (as in the case of Java) indicate a fundamental weakness in the language.
(Anybody who thinks languages like Haskell or ML are fundamentally more powerful than C++ must be unaware of the Boost Lambda library, and of FC++, a set of header files that implements Haskell language semantics for C++ programs. They get along fine without GC, as well.)
I use nkvir-rc under procmail to filter them, which leaves only a few dozen bounce messages per day from sites that got viruses with my return address on them. I have amended nkvir-rc to work properly with Maildir-style mailboxes. (Probably the next released version will have these improvements.)
If you run across them, be sure to thank Paolo Carlini, Petur Runolfsson, and Jerry Quinn for making 3.4 iostreams as fast as (and often faster than) Glibc's stdio. Thank them, too for making filebuf support large files (>2G) natively without any code or build changes needed, on any target that allows them.
Worth noting, too, is that this is the first release in which the library is part of the ABI. Every previous release since 2.95 has had to increment the libstdc++.so version number, but future 3.4 (and maybe 3.5) releases should be backward compatible. Ask your distribution maintainers to ship 3.4-built versions of all C++ libraries they package, so that they will be compatible with programs built with this and future releases.
We do have to admit that it's pretty stupid for the default configuration to have zero volume.
You might be lucky, and have access to lots of ground water. If so, you might be able to pump it through the system with much less power than a regular cooling system needs.
If you have a big enough installation and live in a place that is cold enough in winter, you can make your own Taylor slush pond/tank. For one of those, you spray brine in the air in winter and collect the runoff into a deep pond or tank, circulating it until spring or until it's almost frozen solid, and then circulate cold water from it all summer.
It sounds to me like anywhere you think you want this, you would be better off with actual Python.
What you want is a Relax-NG Schema. DTDs only define the barest bones of XML structure. Validating against a schema lets you verify all kinds of things that a DTD can't even express.
(Don't be confused by W3C Schemas. That format stinks.)
Is a schema important for documentation? It depends on how much structure you need, which largely depends on how many uses you have for the documents. My employer actually puts the documentation itself in the schema, and generates manuals from the same text that validates important input files.
But nobody bothered to ask me. Their loss.