Deciding is out of their lives, by personal philosophy
What do we do? How about we stop trying to cater to these drones who have abandoned their membership in the human race. If you don't think, you don't matter.
I'm not trying to replace prior art searches (though they seem seriously ineffective) so much as prevent patents on ideas so obvious that nobody even bothered to write them down in a form that an examiner can cite as prior art.
Publishing larger searchable databases of prior art attacks the problem from another direction, but RMS and others have pointed out that prior art the examiner looked at is largely ineffective in a later legal challenge, because courts presume examiners did their job correctly (though we've all seen many examples to the contrary).
USPTO only gets USD 750.00 from an application (utility - basic filing fee), but USD 7390.00 for issuing and later maintenance if they accept one. They mention a lot of other fees, and I'm not sure which if any they collect for rejected applications.
More significantly, examiners don't get any credit towards their quotas for rejections after the first, so if the applicant tries again there's a lot of pressure to accept it.
The requirement is just that the description be clear and complete. I've been a developer for eleven years and read RFCs for kicks, yet the few patents I've tried to read didn't make any sense--they completely fail to promote progress. I suspect they're deliberately obtuse, so examiners (who have strict quotas to meet) can't really tell whether the invention is obvious and rubber-stamp them by default.
The USPTO's task is to reject applications for patents on non-novel and obvious inventions, which examiners often seem to be unable or unwilling to do. Sure, the reinventing teams are pure overhead, but so are the examiners we have now.
Patents add a great deal of friction to the economy, so we only benefit from protcting the most impressive inventions that otherwise wouldn't have been published. Nobody deserves the power to harass their competitors merely because they expended effort.
Hire some qualified practicioners in each field (under strict NDAs). Give them a statement of the problem being solved. If they come up with the same solution within a few days, it's so blatantly obvious that the "inventor" is really trying to patent the problem instead of a solution. While you're at it, start enforcing this:
It is required that the description be sufficient so that any person of ordinary skill in the pertinent art, science, or area could make and use the invention without extensive experimentation.--
USPTO
instead of the mountain of gibberish they've accepted to date, and drop the USD 2500.00 "request for ex parte reexamination" fee they demand for pointing out their own mistakes.
Remember, a patent only promotes progress if the cost of licensing it (plus their share of the USPTO overhead) is less than the cost of every licensee having to independently discover it. Granting monopolies on "inventions" that anyone competent would immediately produce in the ordinary course of their work doesn't benefit anyone productive.
This works unless changing a person's name has side effects on other members (or vice versa), but in that case the name doesn't behave like an attribute so it shouldn't be usable as one. It's more lines than yours but is reusable and behaves much more like a builtin type. (You may have to move >> and << outside the class if your compiler's Koenig lookup is broken.)
You don't need setX/getX in the owning object, just change x from an int to a class that implements operator = and operator int. If modifying x requires access to the owning object, it's not behaving like an attribute, so making its interface resemble one is misleading.
Each allocation must be returned to the heap whether using malloc/free or GC.
Not individually. Once a copying collector has relocated live objects into tospace, it can immediately reuse all of fromspace for new allocations. malloc/free require extra bookkeeping (besides risking dangling references) in return for making small portions of the heap reusable immediately.
Finalization is uncommon (only applies to objects that manage non-memory resources), and all the collector has to do is walk a short list of objects in fromspace that had finalizers. You have to queue finalizers anyway, unless you can afford to interrupt your code's critical paths to run them immediately.
But you're right, an object can be traced more than once, though a generational collector can keep the overhead quite low. Almost all collections only trace objects that are still live but haven't yet been promoted out of the first generation (there are tricks for handling old objects' occasional references to young objects), and almost all objects are either dead right away or live for a very long time. If I had to guess, I'd say overhead per object grows logarithmically with the number of first-generation collections the object lives through (which is usually zero).
malloc/free has O(dead objects) overhead, while GC has O(live objects) overhead. Which one is faster depends entirely on the overhead per object, and how many objects are alive and dead. The improved locality a copying collector (which defragments memory) brings further complicates the result.
It's a minor nuisance, but it prevents accidental dependence on non-published interfaces and implementation details of a shared library (especially in C, where "private" isn't an option). And symbols can be exported and imported via the linker without putting anything unportable in the C++ source.
Any implementation that does what the Javadocs say it should do is compatible by definition. The issues you mentioned are undocumented, and so application programmers can't rely on any particular semantics.
Eureka! You've just invented time travel. But the awful truth is that you're not alone. In fact, scientists have been inventing time travel since 1814.
But if you have a time machine, it really doesn't matter who invented it first. All that matters is who gets to the Patent Office first. And by "first" we mean on opening day. Because nothing suits a time machine like US Patent Number 1.
Don't pro spamhauses get paid based on the number of addresses they attack (or at least claim to)? Do they care at all whether there's any chance an address will increase the miniscule response rate?
you can generally pick up and read somebody else's Java code, segment by segment, without having to grok the uber-design of the project
IMHO that's not a strength. Code that doesn't express the system's überdesign shouldn't be there at all (or at least in a library with a conceptually unified design of its own). And in well-factored code it won't be true--what's the value of being able to tell this block contains simple logic and a few method calls if you don't understand what the methods do?
Especially in this market, why are you even hiring "mediocre" (I'd say "unqualified") developers who can't handle packaging complexity or building toolkits to express the best solution to a problem?
I'd rather write just enough to let the compiler automatically insert all the trivial boilerplate it takes to make the code executable. Methods and exceptions are good examples--you get the "call this object's override" and "find the nearest handler on the stack" behaviors without explicitly mentioning them. A good macro system lets you add syntax like this to a language that didn't have those features.
You're right, my hasty googling misled me. The POSIX.1g realtime extension actually specifies pselect, a variant that changes the process' signal mask and allows ns-precision timeouts. I have no idea why they preferred the bitfield-based design.
Network effects are extremely strong in computing. Without standards, the first mover tends to crowd everything else out, and the barrier to entering the market with an innovative new implementation rapidly becomes nearly insurmountable.
Prescriptive standards (when specified competently, which is by no means easy or certain) enable competing implementations to coexist; descriptive standards would too but those are becoming rare as desperate vendors bet on strategic incompatibility.
A dry bathtub tends to indicate that your plumbing works, not that it's broken.
A store's stock is just the integral of the delivery rate minus the sales rate (clipped between zero and available floor space). They could sell a pallet a day and you'd never know it, unless you see them restock whole the shelf at once. This is common enough to have its own jargon--"flying off the shelves", "can't keep it in stock", "reserve yours today", "act now--quantities limited".
Unless you're prepared to duplicate TCP's carefully designed flow control, you're either going to underutilize the path or saturate the slowest link (on an ordinary network without traffic shaping, that amounts to a DoS attack).
Once you solve this problem, you basically have TCP with a very large receive window, which is only an improvement if a selective ACK is dropped while the advertised window is full. In fact waiting until EOF to request retransmissions imposes an idle period on the sender after sending EOF, while TCP can pipeline retransmissions along with new data.
Ah, I had misread that as an assertion that shared state was another way to cause a == b.
Sun's current release might do that, but it isn't part of the API. Another implementation might not, since creating garbage is so cheap that it's probably not optimal anymore.
Slashdot Mirror
Great. Now I want to fork Whitespace and create a ZERO WIDTH NO-BREAK SPACE compiler.
What do we do? How about we stop trying to cater to these drones who have abandoned their membership in the human race. If you don't think, you don't matter.
Publishing larger searchable databases of prior art attacks the problem from another direction, but RMS and others have pointed out that prior art the examiner looked at is largely ineffective in a later legal challenge, because courts presume examiners did their job correctly (though we've all seen many examples to the contrary).
More significantly, examiners don't get any credit towards their quotas for rejections after the first, so if the applicant tries again there's a lot of pressure to accept it.
The requirement is just that the description be clear and complete. I've been a developer for eleven years and read RFCs for kicks, yet the few patents I've tried to read didn't make any sense--they completely fail to promote progress. I suspect they're deliberately obtuse, so examiners (who have strict quotas to meet) can't really tell whether the invention is obvious and rubber-stamp them by default.
The USPTO's task is to reject applications for patents on non-novel and obvious inventions, which examiners often seem to be unable or unwilling to do. Sure, the reinventing teams are pure overhead, but so are the examiners we have now.
Patents add a great deal of friction to the economy, so we only benefit from protcting the most impressive inventions that otherwise wouldn't have been published. Nobody deserves the power to harass their competitors merely because they expended effort.
Hire some qualified practicioners in each field (under strict NDAs). Give them a statement of the problem being solved. If they come up with the same solution within a few days, it's so blatantly obvious that the "inventor" is really trying to patent the problem instead of a solution. While you're at it, start enforcing this:
instead of the mountain of gibberish they've accepted to date, and drop the USD 2500.00 "request for ex parte reexamination" fee they demand for pointing out their own mistakes.
Remember, a patent only promotes progress if the cost of licensing it (plus their share of the USPTO overhead) is less than the cost of every licensee having to independently discover it. Granting monopolies on "inventions" that anyone competent would immediately produce in the ordinary course of their work doesn't benefit anyone productive.
This works unless changing a person's name has side effects on other
members (or vice versa), but in that case the name doesn't behave like
an attribute so it shouldn't be usable as one. It's more lines than
yours but is reusable and behaves much more like a builtin type.
(You may have to move >> and << outside the class if your compiler's
Koenig lookup is broken.)
#include <sstream>
struct person_name {
std::string first, last;
person_name() { }
person_name(std::string const &first, std::string const &last): first(first), last(last) { }
person_name(std::string const &name) { *this = name; }
person_name const &operator =(std::string const &name) {
std::istringstream(name) >> *this;
return *this;
}
operator std::string() const {
return static_cast<std::ostringstream &>(std::ostringstream() << *this).str();
}
static std::ostream &operator <<(std::ostream &os, person_name const &name) {
return os << name.first << ' ' << name.last;
}
static std::istream &operator >>(std::istream &is, person_name &name) {
return is >> name.first >> name.last;
}
};
class person {
public:
person_name name;
};
You don't need setX/getX in the owning object, just change x from an int to a class that implements operator = and operator int. If modifying x requires access to the owning object, it's not behaving like an attribute, so making its interface resemble one is misleading.
Not individually. Once a copying collector has relocated live objects into tospace, it can immediately reuse all of fromspace for new allocations. malloc/free require extra bookkeeping (besides risking dangling references) in return for making small portions of the heap reusable immediately.
Finalization is uncommon (only applies to objects that manage non-memory resources), and all the collector has to do is walk a short list of objects in fromspace that had finalizers. You have to queue finalizers anyway, unless you can afford to interrupt your code's critical paths to run them immediately.
But you're right, an object can be traced more than once, though a generational collector can keep the overhead quite low. Almost all collections only trace objects that are still live but haven't yet been promoted out of the first generation (there are tricks for handling old objects' occasional references to young objects), and almost all objects are either dead right away or live for a very long time. If I had to guess, I'd say overhead per object grows logarithmically with the number of first-generation collections the object lives through (which is usually zero).
malloc/free has O(dead objects) overhead, while GC has O(live objects) overhead. Which one is faster depends entirely on the overhead per object, and how many objects are alive and dead. The improved locality a copying collector (which defragments memory) brings further complicates the result.
Access to memory-mapped devices, or any other kinds of nonportable crap, belongs in the JVM implementation itself.
It's a minor nuisance, but it prevents accidental dependence on non-published interfaces and implementation details of a shared library (especially in C, where "private" isn't an option). And symbols can be exported and imported via the linker without putting anything unportable in the C++ source.
Any implementation that does what the Javadocs say it should do is compatible by definition. The issues you mentioned are undocumented, and so application programmers can't rely on any particular semantics.
A better story:
... except those of us who don't answer such challenges, because making filtering your mail everyone else's problem is wrong.
Don't pro spamhauses get paid based on the number of addresses they attack (or at least claim to)? Do they care at all whether there's any chance an address will increase the miniscule response rate?
One man told such a story to the Darwin Awards folks....
IMHO that's not a strength. Code that doesn't express the system's überdesign shouldn't be there at all (or at least in a library with a conceptually unified design of its own). And in well-factored code it won't be true--what's the value of being able to tell this block contains simple logic and a few method calls if you don't understand what the methods do?
Especially in this market, why are you even hiring "mediocre" (I'd say "unqualified") developers who can't handle packaging complexity or building toolkits to express the best solution to a problem?
I'd rather write just enough to let the compiler automatically insert all the trivial boilerplate it takes to make the code executable. Methods and exceptions are good examples--you get the "call this object's override" and "find the nearest handler on the stack" behaviors without explicitly mentioning them. A good macro system lets you add syntax like this to a language that didn't have those features.
You're right, my hasty googling misled me. The POSIX.1g realtime extension actually specifies pselect, a variant that changes the process' signal mask and allows ns-precision timeouts. I have no idea why they preferred the bitfield-based design.
Prescriptive standards (when specified competently, which is by no means easy or certain) enable competing implementations to coexist; descriptive standards would too but those are becoming rare as desperate vendors bet on strategic incompatibility.
poll is standard (POSIX.1). select is just an old BSDism.
A store's stock is just the integral of the delivery rate minus the sales rate (clipped between zero and available floor space). They could sell a pallet a day and you'd never know it, unless you see them restock whole the shelf at once. This is common enough to have its own jargon--"flying off the shelves", "can't keep it in stock", "reserve yours today", "act now--quantities limited".
Unless you're prepared to duplicate TCP's carefully designed flow control, you're either going to underutilize the path or saturate the slowest link (on an ordinary network without traffic shaping, that amounts to a DoS attack).
Once you solve this problem, you basically have TCP with a very large receive window, which is only an improvement if a selective ACK is dropped while the advertised window is full. In fact waiting until EOF to request retransmissions imposes an idle period on the sender after sending EOF, while TCP can pipeline retransmissions along with new data.
Ah, I had misread that as an assertion that shared state was another way to cause a == b.
Sun's current release might do that, but it isn't part of the API. Another implementation might not, since creating garbage is so cheap that it's probably not optimal anymore.