You can "pump" the difficulty of finding a bug arbitarilly. Make a bug that only happens in an illegal state that can only be entered because of a second bug. If you like you can hide one of these bugs in the compiler. Repeat until blue in the face.
In practice, even difficult bugs are usually only second order. Plus disciplined programming using strongly typed languages helps a lot. So one could perhaps claim that "all bugs should be shallow" and that any failure to be shallow wis in fact a tools failure.
The other fly in this ointment is that a lot of bugs happen because of incomplete specifications. Before you can find the bug you have to first recognize that the spec is incomplete. For new code, there may be no person who can recognize that. Of course you can quibble the hard ones in this category away by relabelling them "feature requests" but some of them result from building in constraints that are inessential to solving the problem at hand, and those are really bugs.
Indeed - lets look at that:
What is claimed is:
> 1. A method in a computer system for processing a message having a sequence of packets, the method > comprising:
> providing a plurality of components, each component being a software routine for converting data > with an input format into data with an output format;
Every file convertor ever written does this part. Nothing new here.
> for the first packet of the message,
This is standard patentese - it does not mean anything
> identifying a sequence of components for processing the packets of the message such that the
> output format of the components of the sequence match the input format of the next component in
> the sequence; and
So, this is claiming the ability to recognize a sequence of components that need to run to do the conversion from the first packet. But this is just a function of the input data. It just means the data is "flat" in some sense. Absolutely nothing new here.
> storing an indication of each of the identified components so that the sequence does not need to
> be re-identified for subsequent packets of the message; and
> for each of a plurality of packets of the message in sequence,
> for each of a plurality of components in the identified sequence,
> retrieving state information relating to performing the processing of the component with the > > previous packet of the message;
So this looks like a claim on software pipelining. You do a bit of processing, save some state, and send the data on its way. There must be hundreds of uses of this prior to 1999. Its probably even in the textbooks in 1999.
> performing the processing of the identified component with the packet and the retrieved state information; and
> storing state information relating to the processing of the component with the packet for use when processing the next packet of the message
Well, yeah, how else would you do it?
Are you sure there is an invention buried in there somewhere? Can someone explain what they claim to have invented? The claims were so generic I could not find a there there.
Half the focus group users did not want in-focus photos taken of them for a few days each month. Some idiot male programmer clearly mistyped the constant.
I wonder if they managed to use just black and white stones or whether they have a (countable?) infinity of colors of stones.
Presumably its a co-ordination language and data flows between stones down and to the right. Perhaps Black and white might just represent arity and what a stone actually did might not be denoted by color. You would have monadic stones (white?) and dyadic stones (black?) and the syntax would require that monadic stones have at most one stone above or to the left since they can only accept one input at a time.
Either that or the language would be weakly typed and data arriving from above or from the left would be processed separately.
The board would have a left and a top which would accept inputs from the environment but could extend infinitely to to bottom and right.
I implemented something that I cannot distinguish from this from the summary (have not read the entire thing) in a product called "The Corporate Retriever" around the time DOS 2.11 shipped (I actually ported it to dos 2.11 from RT-11 but the RT-11 version did of the registration scheme)
That would have been around 1984 or 5 I think. So yes, it was "usual" or at least published by way of a software product by around the mid 80s. So certainly by 1991 it was not new. I don't believe I invented the idea either - in any case, it was certainly an idea that would have occured to anybody "versed in the arts" back then. Back then the process was done by phone. You generated your unique id, called us and we have you a hashed key to unlock the functionality derived from your generated key.
Just for amusement, this was done in Australia too. Not that that means this earlier system should have been known to the patentee.
In England its been illegal to drive in the passing lane when not passing for ever. Not only that but it is culturally accepted (not sure if its actually illegal) that you don't pull out if doing so will impede another driver. As a result, traffic flows much better there than here although its not clear it prevents or delays traffic jams.
Of course, the English drive on the right side of the road (which is to day, the left) so the passing lane is the right hand one.
In Australia I don't think there is a law but at least one person has been booked for "obstructing traffic" when failing to get past in a reasonable manner.
I think SmallTalk introduced duck typing rather than Perl. But anyway, there is a real difference here that is important from a theoretical viewpoint.
If you think about the inheritance tree (in C++ if you like) then all methods are inherited. There are no synthesized attributes. On a general tree, attributes can be both inherited (they flow away from the root) and synthesized (they flow towards the root). These terms were original introduced by Knuth, I think, a long time ago in a context far far away.
In a language like C++ you have to know what type has the synthesized attribute to do a dynamic cast, so you cannot write a routine that will work with any type that has a given (set of) method(s). So you end up forcing all the methods used by some set of classes down into a common ancestor (perhaps, in C++ as pure methods), which is a nightmare or even impossible if the common base class is not in a subsystem you own or can convince someone to change.
One way to handle this in a statically typed language is with interfaces. You define a parameter as supporting an interface. This can be (partially) checked at compile time at the call point and assuming your language allows checking at runtime, never converts a compile time fail into a runtime fail because you would otherwise have had to do a dynamic cast that would itself only fail at run-time.
So you are arguing that the rights of individuals should be subservient to the interests of the state. This is equivalent to the "tear up the consitution; there are terrorists out there" argument that has prevailed in a lot of places in recent years.
Certainly such systems of government (where the individual is subservient to the state) have existed and still do, and there are those who want to restore them, often but not exclusively in the name of religion. A lot of blood has been shed over the last three centurys to overthrow such governments, and no doubt will be again. Trying to stop things getting to that point by defending the US Constitution against depredation from short term expediencies makes a lot of sense.
I don't follow. Having the info available would increase ridership. How is that in the MTA's interest? Its going to make the trains run slower. How can you expect them to keep schedules if the blasted riders keep getting on and off.
Slashdot Mirror
On the Internet, everyone knows you are a dog.
In practice, even difficult bugs are usually only second order. Plus disciplined programming using strongly typed languages helps a lot. So one could perhaps claim that "all bugs should be shallow" and that any failure to be shallow wis in fact a tools failure.
The other fly in this ointment is that a lot of bugs happen because of incomplete specifications. Before you can find the bug you have to first recognize that the spec is incomplete. For new code, there may be no person who can recognize that. Of course you can quibble the hard ones in this category away by relabelling them "feature requests" but some of them result from building in constraints that are inessential to solving the problem at hand, and those are really bugs.
Can't help imagining a bunch of Gendarmes rushing out of the station and hopping on their pushbikes with hopeful looks on their faces.
or it whacked a dinosaur.
So will it come with a warning to not wear a red shirt while using one?
By a freak mischance, the study was done on retired CIA workers who could neither confirm nor deny that they remembered anything.
... a direct hit by a Sarah Palin
But they said information, so not much TV counts. (do they subtract for Fox news?)
Indeed - lets look at that: What is claimed is: > 1. A method in a computer system for processing a message having a sequence of packets, the method > comprising: > providing a plurality of components, each component being a software routine for converting data > with an input format into data with an output format; Every file convertor ever written does this part. Nothing new here. > for the first packet of the message, This is standard patentese - it does not mean anything > identifying a sequence of components for processing the packets of the message such that the > output format of the components of the sequence match the input format of the next component in > the sequence; and So, this is claiming the ability to recognize a sequence of components that need to run to do the conversion from the first packet. But this is just a function of the input data. It just means the data is "flat" in some sense. Absolutely nothing new here. > storing an indication of each of the identified components so that the sequence does not need to > be re-identified for subsequent packets of the message; and > for each of a plurality of packets of the message in sequence, > for each of a plurality of components in the identified sequence, > retrieving state information relating to performing the processing of the component with the > > previous packet of the message; So this looks like a claim on software pipelining. You do a bit of processing, save some state, and send the data on its way. There must be hundreds of uses of this prior to 1999. Its probably even in the textbooks in 1999. > performing the processing of the identified component with the packet and the retrieved state information; and > storing state information relating to the processing of the component with the packet for use when processing the next packet of the message Well, yeah, how else would you do it?
Are you sure there is an invention buried in there somewhere? Can someone explain what they claim to have invented? The claims were so generic I could not find a there there.
Its worse than that. We've been firing vacuum cleaners at enemy aircraft.
Quite right - that would limit the current police powers much too severely.
Half the focus group users did not want in-focus photos taken of them for a few days each month. Some idiot male programmer clearly mistyped the constant.
Presumably its a co-ordination language and data flows between stones down and to the right. Perhaps Black and white might just represent arity and what a stone actually did might not be denoted by color. You would have monadic stones (white?) and dyadic stones (black?) and the syntax would require that monadic stones have at most one stone above or to the left since they can only accept one input at a time.
Either that or the language would be weakly typed and data arriving from above or from the left would be processed separately.
The board would have a left and a top which would accept inputs from the environment but could extend infinitely to to bottom and right.
Is the "must be Apple branded" alsewhere in the EULA?
Your keyboard should have a http://www./ key.
I don't know. I never have really understood Statistical Mechanics and I have probably not already died in a car accident.
They have remodulated the phase colomators on the prion-antiprion exchange field surrounding the writer's conference room.
That would have been around 1984 or 5 I think. So yes, it was "usual" or at least published by way of a software product by around the mid 80s. So certainly by 1991 it was not new. I don't believe I invented the idea either - in any case, it was certainly an idea that would have occured to anybody "versed in the arts" back then. Back then the process was done by phone. You generated your unique id, called us and we have you a hashed key to unlock the functionality derived from your generated key.
Just for amusement, this was done in Australia too. Not that that means this earlier system should have been known to the patentee.
But surely to be a seizure implies loss of use.
Not arguing the judge should have allowed the practice. Just wondering about the use of terms.
Of course, the English drive on the right side of the road (which is to day, the left) so the passing lane is the right hand one.
In Australia I don't think there is a law but at least one person has been booked for "obstructing traffic" when failing to get past in a reasonable manner.
If you think about the inheritance tree (in C++ if you like) then all methods are inherited. There are no synthesized attributes. On a general tree, attributes can be both inherited (they flow away from the root) and synthesized (they flow towards the root). These terms were original introduced by Knuth, I think, a long time ago in a context far far away.
In a language like C++ you have to know what type has the synthesized attribute to do a dynamic cast, so you cannot write a routine that will work with any type that has a given (set of) method(s). So you end up forcing all the methods used by some set of classes down into a common ancestor (perhaps, in C++ as pure methods), which is a nightmare or even impossible if the common base class is not in a subsystem you own or can convince someone to change.
One way to handle this in a statically typed language is with interfaces. You define a parameter as supporting an interface. This can be (partially) checked at compile time at the call point and assuming your language allows checking at runtime, never converts a compile time fail into a runtime fail because you would otherwise have had to do a dynamic cast that would itself only fail at run-time.
It does have the advantages that more of them fit in the bedroom and people don't look at you funny.
Certainly such systems of government (where the individual is subservient to the state) have existed and still do, and there are those who want to restore them, often but not exclusively in the name of religion. A lot of blood has been shed over the last three centurys to overthrow such governments, and no doubt will be again. Trying to stop things getting to that point by defending the US Constitution against depredation from short term expediencies makes a lot of sense.
I don't follow. Having the info available would increase ridership. How is that in the MTA's interest? Its going to make the trains run slower. How can you expect them to keep schedules if the blasted riders keep getting on and off.