You are disagreeing with me. My argument is with the argumentative person disagreeing with me. Asserting something, then crying about how I should prove it for you (when you are wrong in the first place) seems a colossally stupid stance, so I was presuming I misunderstood. Apparently I didn't.
The combination of two bug-free pieces isn't necessarily bug-free. The glue code is where you typically end up with the subtle assumption and domain bugs.
Then you didn't combine bug-free code. The glue is code. And if the glue is bug-laden, then you combined bug-free code with buggy code, to get a buggy result.
Error handling and modularity in and of themselves do nothing to reduce buggyness,
That gets into the definition of "bug". If an error is caught and handled, then it's not necessarily a bug. If someone performs a SQL injection attack, what do the requirements say to do with it? Nothing? Then the program should do what? Assume it's valid, and put the string in, without alteration? Clean out any unusual characters and pass it in? In many cases, the actual desired operation would be different if imported vs manually inputted. If imported, drop that one record, and make a note in the log. If manually entered, pop up an error message. Both of what I'd consider the most commonly requested/expected manners are error handling. If the intention is to drop the record in a batch job, and you handle it in some other manner, that's a bug. If you handle it without user error reported, that's a bug. But defining what to do with "bad" inputs (truncate records too long, whatever) and handling them appropriately is necessary for bug free operation.
Unless a bug is only unintended operation when given well-behaved inputs. But most people I hear using that term don't limit it to well-behaved inputs. Allowing a SQL injection attack is listed as a programming error, right?
A program that solves some of the problem now, even with bugs, is infinitely more valuable than a program that solves all of the problem (or more frequently, a small subset of the problem correctly) when it is too late. That goes back to the "cost effectiveness" - the solution that generates the most profit is the better one in a capitalist situation.
And risk. Something I've never seen a programmer have a good grasp of. Nearly all humans have a poor measure of rates of rare occurrences. Our firmware is hard wired to overstate or understate them depending on biological factors. As so many programmers think of themselves as logical beings, they can't accept the illogical meatspace programming, so can't introspect well enough to recognize such errors in their own programming. So "risk" (even if they can define it) is as foreign to them as their program code is to the customer that contracted for the code.
So bug-free code, before it's verified, is not bug free? What bug does a bug free code contain before testing/verification that is removed by testing/verification?
If none, then the step of verification is irrelevant to whether the code is bug free.
However, many "bugs" aren't even programming errors, they are communication failures somewhere between the customer and the developer. What the customer wants, what the customer asks for, and what the customer actually needs are three different things.
And there's a difference between a a programming bug and a program bug. If the "program" doesn't do what the customer wants, it's a program bug. If the program doesn't do what the programmer wants, that's a programmer bug. I tried to be consistent with my word usage, and I was talking about programmer bugs. Program bugs aren't technical faults. The only faults the programmer can directly address are the technical ones. So I was trying to pick my words to only address those. When the customer asks for something they don't want, then complains when the signed requirements document is wrong (6 months after delivery), that's not the "fault" of the programmer, and most places separate out the programmers from the customer so the programmer doesn't accidentally give what the customer actually wants, as the paper trail would leave them open to liability. You can't sue someone for breach of contract when you have a requirements doc, signed by all parties, which the program meets every requirement in it (given a well worded contract). So you give them what they ask for, even if it isn't what they want. But whatever you give them should execute in the manner intended by the programmer.
If you didn't start yelling when you put the call on speaker, the call itself would be less distracting, but the unusual nature of the act would be distracting.
Yet if someone takes a sledgehammer to a wall and it fails, it's the fault of the sledgehammer or the person using it. But someone passes bobby tables to the database, and it's the fault of the programmer for not predicting the sledgehammer. Of course, input checking should be done, but the interesting point is the blame.
The material wasn't an issue. I had taken the equivelent of two years of university physics and one year of university calculus in a program from a private university. And, as your incredulity goes, the person in charge of accepting that credit as a transfer, refused to accept the credit and apply it. If I didn't have a math, I couldn't graduate, and I don't remember if science was also required. My senior year of Calculus, I spent no time in my class, until the principal found out, and grounded me to class. After which I brought jigsaw puzzles from home and worked them in the back of the class. After that was discovered by the principal, I was "ordered" to sit at my desk. The room had Pi to 50 digits. I still remember the first 50 digits of Pi. I never scored less than a perfect score on any Calculous test, and slept as much as possible. Near the end of the year, the class was nearing the half-way point of my previous class.
I've been smarter than most of my teachers since about the 2nd grade. The class was told to draw "a man with two orange heads" for a halloween display for an upcoming open house. Everyone in the class drew a man with one head on each shoulder, both orange. I drew a man (normal man) with a jack-o-lantern in each hand - a man, with two orange heads. I was sent to the principal's office and beaten for failure to follow directions (a violation of the law, parents must be notified before any beatings). That's also about when I started getting locked in a closet every day for lunch. That teacher had many accolades, and my mother lied about my address to get me in her class.
With that as my benchmark, I was never worse than my second grade teacher.
As for FERPA, the teacher of record was still the other teacher, and I don't think there was anything in the arrangement that would violate FERPA. The "real" teacher gave the topics, and some minimum mandatory work, and I created a class to fill in the other 90% of the time. I don't know what the grades were derived from, but evaluations of the students were passed to the "real" teacher for her to do with as she wished.
Having been brought up with standardized tests, I preferred to give them. Doesn't hurt that for IT training, most people were seeking a certification, almost all of which were multiple choice. So it's a common format, with well known rules. It doesn't hurt that it's almost entirely objective (though many times tests will contain poor questions, whether poor wording in the question, or multiple correct answers, of which the "best" is expected, but often hard to determine). Though in college, in smaller classes, the grades were almost divined by the teachers. Twice I feel I did inferior work, but received a passing grade or better because the teacher felt I "tried". I would have felt robbed if it went the other way, but was happy to have the boost the other way.
When I got my master's, it was hard to get anything other than an A. That was great. Why? Because it meant that the people learned, without regard to tests, assignments, and such. You got from it what you put in to it. There were no worries about the freeloaders dragging down the group projects, or the annoying people who slow things down asking questions that were answered in the reading they didn't do. Some people are externally motivated, but the internally motivated ones do worse in a graded environment.
I have been known to remove questions after the fact, usualy with giving the best score from the two scores, so someone who got it right wouldn't get a deduction for it going away. Nobody has ever complained about that. Weights change as well. To help approximate a curve. I'm generous with grades. But not afraid to fail someone that deserves it.
That comes down to definition of a "bug". What is the intended operation? Is that 100% defined? No? It isn't defined what to do with sufficiently inappropriate errors in the input? Not handling a case that wasn't intended to be handled isn't a "bug". Crashing with dataloss when someone has little bobby tables as an input is a bug. 90% accepted, with 10% flagged, if the intended operation and 100% perfect with the 90% accepted would be "bug free".
The analogy is fatally flawed. If I buy MS Windows from a store, I expect MS to fix the "wall" for free. If I'm a manager in a construction company, if I pay a worker to build a wall, and it's broken, I have to pay someone to fix it, and I don't expect the worker to work for free to rebuild it, even if it was their error.
So why don't bricklayers work for free when MS fixes bugs for free? Oh, wait, with a little creative re-wording, the analogy is reversed. I guess that makes it a bad analogy.
So negligence resulting in damage is *never* the responsibility of the employee? What if when I worked retail, and I was on the clock for dropping money in the deposit box at the bank, if I robbed the bank while on the clock, the bank could sue my employer for robbing the bank?
I don't believe that such protections exist everywhere, even if someone else pointed out it works that way in California.
Programming without bugs is easy. It's just slow and expensive. so nobody wants it. It's cheaper and easier to write bad code and ship it, absorbing backlash, than to build it right in the first place.
The comments aren't "bugless is impossible" because there exist [10 print "Hello World" 20 goto 10] programs. There always exists something so simple it is either bug free or inoperable. So, why is [10 print "Hello " 20 print "World" 30 goto 10] so much harder? Just build clear bug-free pieces, and assemble them. Take the time and care with each line to verify intention. Use modularity and error handling.
I'm sure I'll be called naieve, but at least should move the smallest error free program to a much larger size. But none of that will work when given a timeline half what it should be, and inadequate budget.
The builder is commissioned for a work. The programmer is paid per hour by their employer, regardless of work. If you buy a wall, and the wall is sub-standard, you return it (on brick at a time through the home window of the bricklayer). If you pay an employee for an hour of time, and it's sub-standard, you pay him for another hour, and hope it's less sub-standard.
If you bought a program, and it has a bug, you expect it to be fixed free of charge. If you are a construction company and your bricklayer lays something sub-standard, you pay him to fix it.
This just seems like a question from someone that doesn't understand hourly pay, vs commissioned works.
The human brain, when hearing one-sided conversation, considers itself to be the missing party. A 2-person conversation can be slept through much more easily than a one-party conversation. The brain will keep trying to process the comments as if aimed at the listener.
I've never seen a person thrown out for using a phone. It's so unusual that when someone was thrown out of a theater in Austin, her complaint about it made national news.
Clinton was impeached for telling the truth to a poorly worded question. The issue wasn't perjury, but that the Republicans hated him. "Abuse of power" was one of the charges brought against him (though it failed to get enough votes to impeach) so there's already a precedent for impeachment for disliking a president (the reason the other impeachment was brought as well). No lie was told, and Clinton was found "not guilty" of perjury by the Senate.
Interstate commerce wasn't used for drinking laws. The feds threatened to pull highway funding if the laws weren't put in line with desires the feds couldn't explicitly legislate.
You comment was a bit of a troll, any comment on politics supporting or attacking either party in any manner is a troll/flamebait. Not because it's intended, but because many will be offended by it.
He didn't make an ad hominem comment. That you don't understand what ad hominem means indicates you are an idiot that nobody should listen to (and that was an actual one). Ad hominem doesn't mean "insult" and almost all insults aren't ad hominems.
The party against regulation wants more regulations than anyone is confortable with, they just find it acceptable if every private company colludes to remove all your rights, but heaven forbid the government defend your rights from someone else. That's overbearing regulation.
You can go home and eat there. You have no right to eat at the counter with the Whites. You have the right to walk to work, so you have no right to sit in the bus at all, let alone in the Whites section. You can make your personal windtrap, so you have no right to have a drink from the Whites water fountain.
Slashdot Mirror
You are disagreeing with me. My argument is with the argumentative person disagreeing with me. Asserting something, then crying about how I should prove it for you (when you are wrong in the first place) seems a colossally stupid stance, so I was presuming I misunderstood. Apparently I didn't.
The combination of two bug-free pieces isn't necessarily bug-free. The glue code is where you typically end up with the subtle assumption and domain bugs.
Then you didn't combine bug-free code. The glue is code. And if the glue is bug-laden, then you combined bug-free code with buggy code, to get a buggy result.
Error handling and modularity in and of themselves do nothing to reduce buggyness,
That gets into the definition of "bug". If an error is caught and handled, then it's not necessarily a bug. If someone performs a SQL injection attack, what do the requirements say to do with it? Nothing? Then the program should do what? Assume it's valid, and put the string in, without alteration? Clean out any unusual characters and pass it in? In many cases, the actual desired operation would be different if imported vs manually inputted. If imported, drop that one record, and make a note in the log. If manually entered, pop up an error message. Both of what I'd consider the most commonly requested/expected manners are error handling. If the intention is to drop the record in a batch job, and you handle it in some other manner, that's a bug. If you handle it without user error reported, that's a bug. But defining what to do with "bad" inputs (truncate records too long, whatever) and handling them appropriately is necessary for bug free operation.
Unless a bug is only unintended operation when given well-behaved inputs. But most people I hear using that term don't limit it to well-behaved inputs. Allowing a SQL injection attack is listed as a programming error, right?
A program that solves some of the problem now, even with bugs, is infinitely more valuable than a program that solves all of the problem (or more frequently, a small subset of the problem correctly) when it is too late. That goes back to the "cost effectiveness" - the solution that generates the most profit is the better one in a capitalist situation.
And risk. Something I've never seen a programmer have a good grasp of. Nearly all humans have a poor measure of rates of rare occurrences. Our firmware is hard wired to overstate or understate them depending on biological factors. As so many programmers think of themselves as logical beings, they can't accept the illogical meatspace programming, so can't introspect well enough to recognize such errors in their own programming. So "risk" (even if they can define it) is as foreign to them as their program code is to the customer that contracted for the code.
So bug-free code, before it's verified, is not bug free? What bug does a bug free code contain before testing/verification that is removed by testing/verification?
If none, then the step of verification is irrelevant to whether the code is bug free.
You are just re-defining bug. So please, give an exhaustive definition of bug before asserting my definition is wrong.
However, many "bugs" aren't even programming errors, they are communication failures somewhere between the customer and the developer. What the customer wants, what the customer asks for, and what the customer actually needs are three different things.
And there's a difference between a a programming bug and a program bug. If the "program" doesn't do what the customer wants, it's a program bug. If the program doesn't do what the programmer wants, that's a programmer bug. I tried to be consistent with my word usage, and I was talking about programmer bugs. Program bugs aren't technical faults. The only faults the programmer can directly address are the technical ones. So I was trying to pick my words to only address those. When the customer asks for something they don't want, then complains when the signed requirements document is wrong (6 months after delivery), that's not the "fault" of the programmer, and most places separate out the programmers from the customer so the programmer doesn't accidentally give what the customer actually wants, as the paper trail would leave them open to liability. You can't sue someone for breach of contract when you have a requirements doc, signed by all parties, which the program meets every requirement in it (given a well worded contract). So you give them what they ask for, even if it isn't what they want. But whatever you give them should execute in the manner intended by the programmer.
If you didn't start yelling when you put the call on speaker, the call itself would be less distracting, but the unusual nature of the act would be distracting.
So now, you are saying that if the employer believes (or proves) the act was willful, that they can force an employee to work for free?
Which president since, say, Cater, wasn't a traitor? Reagan sold guns to an enemy. And he was the good one.
Yet if someone takes a sledgehammer to a wall and it fails, it's the fault of the sledgehammer or the person using it. But someone passes bobby tables to the database, and it's the fault of the programmer for not predicting the sledgehammer. Of course, input checking should be done, but the interesting point is the blame.
The material wasn't an issue. I had taken the equivelent of two years of university physics and one year of university calculus in a program from a private university. And, as your incredulity goes, the person in charge of accepting that credit as a transfer, refused to accept the credit and apply it. If I didn't have a math, I couldn't graduate, and I don't remember if science was also required. My senior year of Calculus, I spent no time in my class, until the principal found out, and grounded me to class. After which I brought jigsaw puzzles from home and worked them in the back of the class. After that was discovered by the principal, I was "ordered" to sit at my desk. The room had Pi to 50 digits. I still remember the first 50 digits of Pi. I never scored less than a perfect score on any Calculous test, and slept as much as possible. Near the end of the year, the class was nearing the half-way point of my previous class.
I've been smarter than most of my teachers since about the 2nd grade. The class was told to draw "a man with two orange heads" for a halloween display for an upcoming open house. Everyone in the class drew a man with one head on each shoulder, both orange. I drew a man (normal man) with a jack-o-lantern in each hand - a man, with two orange heads. I was sent to the principal's office and beaten for failure to follow directions (a violation of the law, parents must be notified before any beatings). That's also about when I started getting locked in a closet every day for lunch. That teacher had many accolades, and my mother lied about my address to get me in her class.
With that as my benchmark, I was never worse than my second grade teacher.
As for FERPA, the teacher of record was still the other teacher, and I don't think there was anything in the arrangement that would violate FERPA. The "real" teacher gave the topics, and some minimum mandatory work, and I created a class to fill in the other 90% of the time. I don't know what the grades were derived from, but evaluations of the students were passed to the "real" teacher for her to do with as she wished.
Having been brought up with standardized tests, I preferred to give them. Doesn't hurt that for IT training, most people were seeking a certification, almost all of which were multiple choice. So it's a common format, with well known rules. It doesn't hurt that it's almost entirely objective (though many times tests will contain poor questions, whether poor wording in the question, or multiple correct answers, of which the "best" is expected, but often hard to determine). Though in college, in smaller classes, the grades were almost divined by the teachers. Twice I feel I did inferior work, but received a passing grade or better because the teacher felt I "tried". I would have felt robbed if it went the other way, but was happy to have the boost the other way.
When I got my master's, it was hard to get anything other than an A. That was great. Why? Because it meant that the people learned, without regard to tests, assignments, and such. You got from it what you put in to it. There were no worries about the freeloaders dragging down the group projects, or the annoying people who slow things down asking questions that were answered in the reading they didn't do. Some people are externally motivated, but the internally motivated ones do worse in a graded environment.
I have been known to remove questions after the fact, usualy with giving the best score from the two scores, so someone who got it right wouldn't get a deduction for it going away. Nobody has ever complained about that. Weights change as well. To help approximate a curve. I'm generous with grades. But not afraid to fail someone that deserves it.
That comes down to definition of a "bug". What is the intended operation? Is that 100% defined? No? It isn't defined what to do with sufficiently inappropriate errors in the input? Not handling a case that wasn't intended to be handled isn't a "bug". Crashing with dataloss when someone has little bobby tables as an input is a bug. 90% accepted, with 10% flagged, if the intended operation and 100% perfect with the 90% accepted would be "bug free".
The analogy is fatally flawed. If I buy MS Windows from a store, I expect MS to fix the "wall" for free. If I'm a manager in a construction company, if I pay a worker to build a wall, and it's broken, I have to pay someone to fix it, and I don't expect the worker to work for free to rebuild it, even if it was their error.
So why don't bricklayers work for free when MS fixes bugs for free? Oh, wait, with a little creative re-wording, the analogy is reversed. I guess that makes it a bad analogy.
You've never heard of "malpractice"?
So negligence resulting in damage is *never* the responsibility of the employee? What if when I worked retail, and I was on the clock for dropping money in the deposit box at the bank, if I robbed the bank while on the clock, the bank could sue my employer for robbing the bank?
I don't believe that such protections exist everywhere, even if someone else pointed out it works that way in California.
Programming without bugs is easy. It's just slow and expensive. so nobody wants it. It's cheaper and easier to write bad code and ship it, absorbing backlash, than to build it right in the first place.
The comments aren't "bugless is impossible" because there exist [10 print "Hello World" 20 goto 10] programs. There always exists something so simple it is either bug free or inoperable. So, why is [10 print "Hello " 20 print "World" 30 goto 10] so much harder? Just build clear bug-free pieces, and assemble them. Take the time and care with each line to verify intention. Use modularity and error handling.
I'm sure I'll be called naieve, but at least should move the smallest error free program to a much larger size. But none of that will work when given a timeline half what it should be, and inadequate budget.
The builder is commissioned for a work. The programmer is paid per hour by their employer, regardless of work. If you buy a wall, and the wall is sub-standard, you return it (on brick at a time through the home window of the bricklayer). If you pay an employee for an hour of time, and it's sub-standard, you pay him for another hour, and hope it's less sub-standard.
If you bought a program, and it has a bug, you expect it to be fixed free of charge. If you are a construction company and your bricklayer lays something sub-standard, you pay him to fix it.
This just seems like a question from someone that doesn't understand hourly pay, vs commissioned works.
The human brain, when hearing one-sided conversation, considers itself to be the missing party. A 2-person conversation can be slept through much more easily than a one-party conversation. The brain will keep trying to process the comments as if aimed at the listener.
I've never seen a person thrown out for using a phone. It's so unusual that when someone was thrown out of a theater in Austin, her complaint about it made national news.
Clinton was impeached for telling the truth to a poorly worded question. The issue wasn't perjury, but that the Republicans hated him. "Abuse of power" was one of the charges brought against him (though it failed to get enough votes to impeach) so there's already a precedent for impeachment for disliking a president (the reason the other impeachment was brought as well). No lie was told, and Clinton was found "not guilty" of perjury by the Senate.
So there should be a Google Glass app for that?
Interstate commerce wasn't used for drinking laws. The feds threatened to pull highway funding if the laws weren't put in line with desires the feds couldn't explicitly legislate.
You comment was a bit of a troll, any comment on politics supporting or attacking either party in any manner is a troll/flamebait. Not because it's intended, but because many will be offended by it.
He didn't make an ad hominem comment. That you don't understand what ad hominem means indicates you are an idiot that nobody should listen to (and that was an actual one). Ad hominem doesn't mean "insult" and almost all insults aren't ad hominems.
The party against regulation wants more regulations than anyone is confortable with, they just find it acceptable if every private company colludes to remove all your rights, but heaven forbid the government defend your rights from someone else. That's overbearing regulation.
You can go home and eat there. You have no right to eat at the counter with the Whites. You have the right to walk to work, so you have no right to sit in the bus at all, let alone in the Whites section. You can make your personal windtrap, so you have no right to have a drink from the Whites water fountain.