I've still yet to be shown an example of a Java program that runs faster than an equivalent C or C++ program
And what unholy twist of the mind would lead you to expect two equivalent programs to have a significant speed difference? If anything, I'd expect two equivalent programs to have more-or-less the same translation into machine-level instructions. Which means the same order of calculation time for the same problem instance.
one extreme example was Java: 8 hours, C: 30 seconds
Which leads me immediately to doubt how "equivalent" your programs were. When it comes to order-comparisons or pure benchmarking, "equivalent" does not simply mean "produces the same result as". You have to compare the same algorithm over the same data structures.
No, it shouldn't. One language is not generically faster than another language, ever. Trust me, there is not a problem out there for which you cannot write a Java program that is at the very least reasonably fast and a C(++) program that is so slow that glaciers are speed monsters by comparison.
And VS [...] should be able to outrun Java.
Leaving aside that you are now comparing a set of compilers to a language (which is a pointless comparison), this statement is as inherently flawed as the previous one -- for the same reason.
That time only has to be expended once. Whether or not that effort is significant with respect to the entire calculation depends on what the calculation is.
*Sigh*. Are we ever going to see the end of this bullshit? No, probably not.
Look, try to follow along (I'll leave a dotted line, it shouldn't be that hard). Speed of execution doesn't depend on the language. It depends on how the implementation was written, the sequence of machine instructions that is generated from the source code and (in case an intermittent machine such as a JVM is used, or in case of parallellization) how that code is executed.
A modern JVM incorporates at least a JIT compiler and probably the newer HotSpot generation compilers. These compilers do not translate bytecode over and over again, line by line, into native instructions. These compilers translate large chunks of the code and leave that code in memory as long as possible for execution. That in turn means that once the JVM is started (JVMs in normal execution mode usually do suffer from ridiculous startup times) and the code to be executed is translated, a program originally written in Java incurs no particular lag time in execution in comparison to an equivalent program written in C, C++, Pascal, APL, Fortran or any of the other languages you care to mention that are traditionally compiled to native code.
The only question then is whether the program was written in such a way that it does a lot of memory allocation and reallocation during the actual calculation or not. These are the considerations that rule the average execution times of a program, not which language it was written in.
It's a good resource, and a fascinating experiment in collaborative content generation.
Absolutely. And it's not Anglocentric either; I've contributed to the Dutch edition myself. Either way, the good news is we've done it; the counter for funds received over at Wikimedia is now at $23,382.17, so I expect them to be up and running again soon.
He has as much claim to anything as Turing. This as a result of little gift from Turing, who came up with a translation mechanism from lambda terms to Turing machines and back.
Don't agree. Alan Turing worked on models of computation, not on the theoretical basis of a working machine. You need both Turing's model and Von Neumann's Fetch-Decode-Execute cycle to come up with the kind of machine/program combination that we use nowadays.
As for Zuse, he most certainly did all of it on his own. But his model of computation is so fundamentally different from the model that backs the box you're looking at right now that you cannot really claim that he had anything to do with it. He certainly has a claim in his own right to being the father of some sort of computing -- his work was so completely unrelated to the work being done by Von Neumann and Turing that it deserves credit as standing alone, being original and probably even being a shame that nobody ever pursued it after WWII.
The EUCD deals with circumvention of protection that deals with copyright issues. For example copying which is a right the copyright holder has. Accessing a work is NOT something exlusive to the copyright holder and hence not an issue of copyrights.
Except that the process of accessing a DVD entails making a copy in memory of successive sections of it. Just like with computer programs, where a copy in active memory is made from what is stored on the harddisk, which is itself a copy of what was on the installation medium.
Oh, so close and yet so far -- you were only a letter off. No, Norway is not a member of the EEC (precursor to the EC and as such to the EU) either. Norway IS a member of the European Economic Area (EEA), which is a free-trade zone that consists of the European Union and all of the EFTA that hasn't been absorbed into the EU yet.
But it may only last untill EUCD is implemented...
That doesn't seem particulalry likely. The central reason that Johansen was never found guilty was that he didn't write or distribute this software with the purpose of violating copyrights (as in making copies and redistributing) but for enabling premissible use (i.e. making the damn things readble under Linux after you spent good money on them). That use remains permissible and Artible 6, sub 4 of that same Directive states that both governments and industry must see to it that it remains possible to take such permissible actions and that circumventing copyright protections for such purposes can never be a violation.
However, the Government of Norway had little choice but to join the European Economic Space,
Area. In English, it's called the European Economic Area (I know it's confusing at times; it's called "space" (Ruimte) in Dutch as well). And Norway had every freedom not to join -- it's just that at the time Norway was expecting that it WOULD shortly be joining the EU. That is, after all, what the Area was all about: a stepping-stone to full EU (then EC) membership.
into seeing the problem in the wrong place.
"[...] and for deployment we run our website using Java app servers on Solaris behind Apache."
This isn't the problem.
(creating several 100Ks of in memory objects for each logon
This is.
So what does Slashdot think? What would you do if you, were in the same boat?"
Don't know what/. thinks, but I think you need a serius rethink of your application's design. It sounds to me like you're throwing away exactly the advantage that servlets can give you by creating lots of objects for each logon.
Asphalt. Asphalt is incredibly expensive stuff (replacing the top layer costs something like ?200 per m^2) and it crumbles like crazy.
Besides, the problem is proportional to the volume. Freeways/highways get more traffic, exacerbating the decay of the road. But since there is so much traffic, the pressure on quality is higher, so upkeep is more important. By comparison, a country road gets less traffic, which means that the delays between maintenance cycles is higher. That doesn't mean they saty in good condition, but the decay is less and with the lower traffic volume it also takes longer for a big issue to arise witht he quality of the road.
A much smarter method, in my opinion, would be to check vehicle mileage of registered vehicles, and tax based on that.
That depeds on how you want to arrange your taxes. Currently, in the Netherlands at least, you pay tax simply for owning an active vehicle (i.e. one that is registered as being in use) -- so you pay whether you use it or not. In the system you are proposing, you'd pay based on use, but you'd pay the same amount per kilometer no matter where that kilometer was driven (busy highway with high maintenance, country road with low upkeep or private terrain not payed for by any government agency). By comparison, a tracking system would allow differentiation towards which road, which kind of road, what time, etc. It also means you could pay no taxes for distance on private terrain and be billed against a lower tax tariff if you drive a lot in places with a lower tax (consider that in the current system, you pay taxes of your domicile region on motor vehicles, even if you drive most in places with far lower taxes). It all depends on what you want to arrange.
Yes, you're correct. That's why the OP is not -- patents cannot be scrubbed in this way after they are issued.
Even easier loophole: THe patent covers something that by it's nature would be used in off-the-shelf components. Build aforementioned components and sell. Patent is void.
Actually, that's not a loophole. Nor need you go through the motions of producing the thing to make the patent go away. Under European patent law, one of the prerequisites for an invention being patentable is that it is not obvious (e.g. the audio CD was patentable, but the CD-ROM was not because this new application was obvious). If you can tell beforehand that an invention would be off-the-shelf by its very nature (i.e. be a commercial success), then it is obvious.
If it is, or it *can* *be*, implemented on a computer bought "off the shelf" and optionally modified only by parts bought "off the shelf" [e.g. "I added an eithernet card"] then it can not be patented.
Something like that, yes. Note that the modification board you buy off the shelf including the software embedded in it may be patented.
If it has been patented, and the state of "the comercial shelf" from which parts are normally bought [e.g. comp-USA etc] advances to the point where the above rule would make it un-patentable, the patent has reached its terminal lifespan and is no longer valid.
Err, no. Patents are valid for a fixed timespan (depending on the country for which the patent was issued). Advancement of the state-of-the-art after issuance does not affect the patent (which is logical, since the patent is publically available and therefore itself an advancement of the state of the art to the level of the patent).
Of course, state of the art cannot advance around the patent to include the patent's contents -- the whole point of a patent is that the patent-holder can block exactly that. Of course, there's nothing stopping anybody from reaching the same end result in a different way, making the patent obsolete rather than invalid.
LOL, no, I want it to be meaningfull, and I think it currently isn't.
Then you need a remedial course in the basics of intellectual property law -- the meaning of "as such" in the EPC is basic stuff. Any IP introduction for engineers will do.
I want the versions that clearly state an invention must contain something novel outside of software.
Then you want the unnecessary.
Can you find a anything requiring novelty to exist outside of the software?
In the current proposal before the EP? Yes, for the, what is it now, fourth time: Article 4a of the draft Directive. Not to mention the EPC itself, of course.
The only reason to change the rules
They aren't changing the rules.
Can you find anything stating that programs are not technical / a feild of technology / have technical character?
Of course not -- it's not generally true.
The limitations you are reffering to don't work if programs are technical.
Yes, they do. The limitations are in place and you cannot pretend they are not just because you want to. The text of the proposal is the text, the text is not what you make up on the fly. Not to mention that the proposal does not amend or contravene the EPC, so the conditions of that treaty remain in force. As is the intention of the proposal.
I saw it. The grounds for patentability also require novelty. The problem is that when the novelty is purely in the code then they are patenting pure software.
No, that is not so. Either they are patenting the result of combining novel software with specific hardware, or they have obtained an illegal patent -- in which case a short trip to the court will make that patent evaporate, just like with all such patents. There are safeguards against mistakes being made, you see -- a bad patent need not simply stand.
The 'yet' makes no sense because there is absolutely no conflict. The a device is patentable. A method run on that device is not.
Again, not true. An INVENTION might be patentable, a device in and of itself is not necessarily patentable. Again, there is no direct requirement for an invention to be a physical thing, and a physical thing is not patentable by definition. That aside, an abacus is an implementation of a model of numbers if nothing else. The reason it is patentable is because models are not patentable as such, but implementations of those models can be. Again, you cannot pick and choose in which parts of the EPC you honor -- the "as such" has a meaning and this is it. More to the point, if there were no Article 52.3 EPC, an abacus would not be patentable.
There are [...] and day.
Undoubtedly. However, that has not given you any real insight into the workings of the different patent laws that are in effect or in proposal in Europe.
Question: Are you a programmer?
Programmer and more to the point master of science in computing science -- with a number of courses on intellectual property law as part of my education.
No, it isn't. You want it to be meaningless, but that is something completely different.
But the directive defines programming is technical. It defines any "new" code is a technical contribution.
No, it doesn't. You're reading the draft as it was before JURI amended it -- in the current proposal, both Recital 12 and Article 4a clearly state literally the opposite of what you are saying here.
You are mixing the "technical effects" and the "physical".
Of course I am. "Technical effect beyond the normal physical interactions between a program and the computer, [etc.]" limits patentability immensely, way beyond the realm of pure software like wordprocessors. That's the point: wordprocessors, spreadsheets, anything that lives within a normal computer and is not written specifically to be used on one special piece of hardware is a program as such and not patentable. That's the point.
They define that programs are technical and technical effects can be purely software, like wordprocessing. They are just applying plain-old prior art limitations to patenting pure software "inventions".
They also say that being software or involving a computer in and of itself is not grounds for patentability -- you cannot pick and choose those parts of the Directive that you want to see and ignore the rest.
They have rejected absolutely every amendment that even hints of any physical requirement (other than that it must run on something, including ordinary hardware).
I disagree. I think Article 4a nicely limits patentability to that which meets the type of physical requirement you are looking for.
????? The "yet" in there makes no sense.
Yes, it does -- the point is the meaning of the phrase "as such".
Of course I said an abacus is patentable. An abacus is a thing, a patentable tool. An abacus is not a method. The directive would allow a patent on the method of taking a square root on an abacus.
An abacus is a tool that implements a method for keeping count, namely by moving of beads (markers, tokens, etc.) from one stack to another in such a way that the stacks represent digits. That is the idea and the method -- and yet an abacus is still patentable, because you cannot patent ideas as such. But you can patent applications of such ideas. In other words, "as such" is far from meaningless -- it is the very essence of patentability, since it allows that you can patent inventions even though every invention is based on an idea.
Like I said [...] ordinary hardware).
Look, I'm going to suggest we quit this discussion. Basically, our difference stems from the fact that you want this proposal to say one particular thing whereas I don't believe that it even can say that thing. So we're just going to keep going around in circles and not getting anywhere.
I do not think that this is correct. Patents are for inventions. Inventions are for ideas.
No, he's correct in principle (in Europe, at least). Patents here are not granted for general or generic ideas, but for specific implementations of those ideas. The point of it is that you have to show feasibility of industrial application (basically, you have to prove that your proposal works and is good for something before you can patent it and that you are not just talking out of your underside; otherwise you'd get people patenting warp drive, wormhole inducers and other crap like that).
Methinks a large part of the problem here is that you can take "algorithm" to mean two different things. Warshall's matrix multiplication algorithm is firmly based in mathematics -- it is in essence mathematics, in fact. But a set of instructions on how (in what order) to write a collection of bits to a network card can also be called an algorithm (literally the old recipe analogy), as unmathematical as it may be. Within the current proposal on patentability of software before the EP, the idea is that the first is not patentable, the second might be (well, more or less -- let's not get into specific details here about why this is a bad example).
Slashdot Mirror
I've still yet to be shown an example of a Java program that runs faster than an equivalent C or C++ program
And what unholy twist of the mind would lead you to expect two equivalent programs to have a significant speed difference? If anything, I'd expect two equivalent programs to have more-or-less the same translation into machine-level instructions. Which means the same order of calculation time for the same problem instance.
one extreme example was Java: 8 hours, C: 30 seconds
Which leads me immediately to doubt how "equivalent" your programs were. When it comes to order-comparisons or pure benchmarking, "equivalent" does not simply mean "produces the same result as". You have to compare the same algorithm over the same data structures.
C++ should be able to run circles around Java.
No, it shouldn't. One language is not generically faster than another language, ever. Trust me, there is not a problem out there for which you cannot write a Java program that is at the very least reasonably fast and a C(++) program that is so slow that glaciers are speed monsters by comparison.
And VS [...] should be able to outrun Java.
Leaving aside that you are now comparing a set of compilers to a language (which is a pointless comparison), this statement is as inherently flawed as the previous one -- for the same reason.
That time only has to be expended once. Whether or not that effort is significant with respect to the entire calculation depends on what the calculation is.
*Sigh*. Are we ever going to see the end of this bullshit? No, probably not.
Look, try to follow along (I'll leave a dotted line, it shouldn't be that hard). Speed of execution doesn't depend on the language. It depends on how the implementation was written, the sequence of machine instructions that is generated from the source code and (in case an intermittent machine such as a JVM is used, or in case of parallellization) how that code is executed.
A modern JVM incorporates at least a JIT compiler and probably the newer HotSpot generation compilers. These compilers do not translate bytecode over and over again, line by line, into native instructions. These compilers translate large chunks of the code and leave that code in memory as long as possible for execution. That in turn means that once the JVM is started (JVMs in normal execution mode usually do suffer from ridiculous startup times) and the code to be executed is translated, a program originally written in Java incurs no particular lag time in execution in comparison to an equivalent program written in C, C++, Pascal, APL, Fortran or any of the other languages you care to mention that are traditionally compiled to native code.
The only question then is whether the program was written in such a way that it does a lot of memory allocation and reallocation during the actual calculation or not. These are the considerations that rule the average execution times of a program, not which language it was written in.
That there was no referendum on EU membership in the UK is one thing, I think there should have been one.
There was, in 1975. 67,3% voted in favor of EEC membership.
Nah, nah, got you beat! I sent them EUR150! ;-)
It's a good resource, and a fascinating experiment in collaborative content generation.Absolutely. And it's not Anglocentric either; I've contributed to the Dutch edition myself. Either way, the good news is we've done it; the counter for funds received over at Wikimedia is now at $23,382.17, so I expect them to be up and running again soon.
He has as much claim to anything as Turing. This as a result of little gift from Turing, who came up with a translation mechanism from lambda terms to Turing machines and back.
Are you sure? I thought Plankalkul included both iteration and selection constructs....
Don't agree. Alan Turing worked on models of computation, not on the theoretical basis of a working machine. You need both Turing's model and Von Neumann's Fetch-Decode-Execute cycle to come up with the kind of machine/program combination that we use nowadays.
As for Zuse, he most certainly did all of it on his own. But his model of computation is so fundamentally different from the model that backs the box you're looking at right now that you cannot really claim that he had anything to do with it. He certainly has a claim in his own right to being the father of some sort of computing -- his work was so completely unrelated to the work being done by Von Neumann and Turing that it deserves credit as standing alone, being original and probably even being a shame that nobody ever pursued it after WWII.
Except that the process of accessing a DVD entails making a copy in memory of successive sections of it. Just like with computer programs, where a copy in active memory is made from what is stored on the harddisk, which is itself a copy of what was on the installation medium.
Methinks you're mixing up the two things he has published.
Oh, so close and yet so far -- you were only a letter off. No, Norway is not a member of the EEC (precursor to the EC and as such to the EU) either. Norway IS a member of the European Economic Area (EEA), which is a free-trade zone that consists of the European Union and all of the EFTA that hasn't been absorbed into the EU yet.
That doesn't seem particulalry likely. The central reason that Johansen was never found guilty was that he didn't write or distribute this software with the purpose of violating copyrights (as in making copies and redistributing) but for enabling premissible use (i.e. making the damn things readble under Linux after you spent good money on them). That use remains permissible and Artible 6, sub 4 of that same Directive states that both governments and industry must see to it that it remains possible to take such permissible actions and that circumventing copyright protections for such purposes can never be a violation.
Area. In English, it's called the European Economic Area (I know it's confusing at times; it's called "space" (Ruimte) in Dutch as well). And Norway had every freedom not to join -- it's just that at the time Norway was expecting that it WOULD shortly be joining the EU. That is, after all, what the Area was all about: a stepping-stone to full EU (then EC) membership.
which is EU+NorwayI'm sure Iceland for one appreciates this one....
Correction: 2 - 0. DVD Jon was already acquitted once in first instance, this was the appeal.
This isn't the problem.
(creating several 100Ks of in memory objects for each logonThis is.
So what does Slashdot think? What would you do if you, were in the same boat?"Don't know what /. thinks, but I think you need a serius rethink of your application's design. It sounds to me like you're throwing away exactly the advantage that servlets can give you by creating lots of objects for each logon.
Asphalt. Asphalt is incredibly expensive stuff (replacing the top layer costs something like ?200 per m^2) and it crumbles like crazy.
Besides, the problem is proportional to the volume. Freeways/highways get more traffic, exacerbating the decay of the road. But since there is so much traffic, the pressure on quality is higher, so upkeep is more important. By comparison, a country road gets less traffic, which means that the delays between maintenance cycles is higher. That doesn't mean they saty in good condition, but the decay is less and with the lower traffic volume it also takes longer for a big issue to arise witht he quality of the road.
That depeds on how you want to arrange your taxes. Currently, in the Netherlands at least, you pay tax simply for owning an active vehicle (i.e. one that is registered as being in use) -- so you pay whether you use it or not. In the system you are proposing, you'd pay based on use, but you'd pay the same amount per kilometer no matter where that kilometer was driven (busy highway with high maintenance, country road with low upkeep or private terrain not payed for by any government agency). By comparison, a tracking system would allow differentiation towards which road, which kind of road, what time, etc. It also means you could pay no taxes for distance on private terrain and be billed against a lower tax tariff if you drive a lot in places with a lower tax (consider that in the current system, you pay taxes of your domicile region on motor vehicles, even if you drive most in places with far lower taxes). It all depends on what you want to arrange.
Yes, you're correct. That's why the OP is not -- patents cannot be scrubbed in this way after they are issued.
Even easier loophole: THe patent covers something that by it's nature would be used in off-the-shelf components. Build aforementioned components and sell. Patent is void.Actually, that's not a loophole. Nor need you go through the motions of producing the thing to make the patent go away. Under European patent law, one of the prerequisites for an invention being patentable is that it is not obvious (e.g. the audio CD was patentable, but the CD-ROM was not because this new application was obvious). If you can tell beforehand that an invention would be off-the-shelf by its very nature (i.e. be a commercial success), then it is obvious.
Something like that, yes. Note that the modification board you buy off the shelf including the software embedded in it may be patented.
If it has been patented, and the state of "the comercial shelf" from which parts are normally bought [e.g. comp-USA etc] advances to the point where the above rule would make it un-patentable, the patent has reached its terminal lifespan and is no longer valid.Err, no. Patents are valid for a fixed timespan (depending on the country for which the patent was issued). Advancement of the state-of-the-art after issuance does not affect the patent (which is logical, since the patent is publically available and therefore itself an advancement of the state of the art to the level of the patent).
Of course, state of the art cannot advance around the patent to include the patent's contents -- the whole point of a patent is that the patent-holder can block exactly that. Of course, there's nothing stopping anybody from reaching the same end result in a different way, making the patent obsolete rather than invalid.
Then you need a remedial course in the basics of intellectual property law -- the meaning of "as such" in the EPC is basic stuff. Any IP introduction for engineers will do.
I want the versions that clearly state an invention must contain something novel outside of software.Then you want the unnecessary.
Can you find a anything requiring novelty to exist outside of the software?In the current proposal before the EP? Yes, for the, what is it now, fourth time: Article 4a of the draft Directive. Not to mention the EPC itself, of course.
The only reason to change the rulesThey aren't changing the rules.
Can you find anything stating that programs are not technical / a feild of technology / have technical character?Of course not -- it's not generally true.
The limitations you are reffering to don't work if programs are technical.Yes, they do. The limitations are in place and you cannot pretend they are not just because you want to. The text of the proposal is the text, the text is not what you make up on the fly. Not to mention that the proposal does not amend or contravene the EPC, so the conditions of that treaty remain in force. As is the intention of the proposal.
I saw it. The grounds for patentability also require novelty. The problem is that when the novelty is purely in the code then they are patenting pure software.No, that is not so. Either they are patenting the result of combining novel software with specific hardware, or they have obtained an illegal patent -- in which case a short trip to the court will make that patent evaporate, just like with all such patents. There are safeguards against mistakes being made, you see -- a bad patent need not simply stand.
The 'yet' makes no sense because there is absolutely no conflict. The a device is patentable. A method run on that device is not.Again, not true. An INVENTION might be patentable, a device in and of itself is not necessarily patentable. Again, there is no direct requirement for an invention to be a physical thing, and a physical thing is not patentable by definition. That aside, an abacus is an implementation of a model of numbers if nothing else. The reason it is patentable is because models are not patentable as such, but implementations of those models can be. Again, you cannot pick and choose in which parts of the EPC you honor -- the "as such" has a meaning and this is it. More to the point, if there were no Article 52.3 EPC, an abacus would not be patentable.
There are [...] and day.Undoubtedly. However, that has not given you any real insight into the workings of the different patent laws that are in effect or in proposal in Europe.
Question: Are you a programmer?Programmer and more to the point master of science in computing science -- with a number of courses on intellectual property law as part of my education.
No, it isn't. You want it to be meaningless, but that is something completely different.
But the directive defines programming is technical. It defines any "new" code is a technical contribution.No, it doesn't. You're reading the draft as it was before JURI amended it -- in the current proposal, both Recital 12 and Article 4a clearly state literally the opposite of what you are saying here.
You are mixing the "technical effects" and the "physical".Of course I am. "Technical effect beyond the normal physical interactions between a program and the computer, [etc.]" limits patentability immensely, way beyond the realm of pure software like wordprocessors. That's the point: wordprocessors, spreadsheets, anything that lives within a normal computer and is not written specifically to be used on one special piece of hardware is a program as such and not patentable. That's the point.
They define that programs are technical and technical effects can be purely software, like wordprocessing. They are just applying plain-old prior art limitations to patenting pure software "inventions".They also say that being software or involving a computer in and of itself is not grounds for patentability -- you cannot pick and choose those parts of the Directive that you want to see and ignore the rest.
They have rejected absolutely every amendment that even hints of any physical requirement (other than that it must run on something, including ordinary hardware).I disagree. I think Article 4a nicely limits patentability to that which meets the type of physical requirement you are looking for.
????? The "yet" in there makes no sense.Yes, it does -- the point is the meaning of the phrase "as such".
Of course I said an abacus is patentable. An abacus is a thing, a patentable tool. An abacus is not a method. The directive would allow a patent on the method of taking a square root on an abacus.An abacus is a tool that implements a method for keeping count, namely by moving of beads (markers, tokens, etc.) from one stack to another in such a way that the stacks represent digits. That is the idea and the method -- and yet an abacus is still patentable, because you cannot patent ideas as such. But you can patent applications of such ideas. In other words, "as such" is far from meaningless -- it is the very essence of patentability, since it allows that you can patent inventions even though every invention is based on an idea.
Like I said [...] ordinary hardware).Look, I'm going to suggest we quit this discussion. Basically, our difference stems from the fact that you want this proposal to say one particular thing whereas I don't believe that it even can say that thing. So we're just going to keep going around in circles and not getting anywhere.
No, he's correct in principle (in Europe, at least). Patents here are not granted for general or generic ideas, but for specific implementations of those ideas. The point of it is that you have to show feasibility of industrial application (basically, you have to prove that your proposal works and is good for something before you can patent it and that you are not just talking out of your underside; otherwise you'd get people patenting warp drive, wormhole inducers and other crap like that).
Methinks a large part of the problem here is that you can take "algorithm" to mean two different things. Warshall's matrix multiplication algorithm is firmly based in mathematics -- it is in essence mathematics, in fact. But a set of instructions on how (in what order) to write a collection of bits to a network card can also be called an algorithm (literally the old recipe analogy), as unmathematical as it may be. Within the current proposal on patentability of software before the EP, the idea is that the first is not patentable, the second might be (well, more or less -- let's not get into specific details here about why this is a bad example).
Err -- it's not supposed to look like Gnome. GTK = GIMP Tool Kit, not Gnome Tool Kit.