Posted on 02/12/2016 10:53:21 AM PST by Swordmaker
:-)
Man oh man....isn't that just about the biggest wish of every guy on the planet? That is, over the age of 60.
You are only permitted to do that after you have worked out the square root of -1.
“You are only permitted to do that after you have worked out the square root of -1.”
Why do you think they call it the “i” phone?
Sorry to hear that...my response if my son fell for this trick...
He’d be sitting and staring at a “brick” for quite a while until he figured it out.
He’s already been warned about the idiots and saboteurs of the www...he learned his first lesson on sidebar ads when he got the FBI virus for clicking on some game link...I didn’t bail him out for quite a few days until he actually needed the laptop for school.
+1. Tell me about it....
We check literally everything we get from a user or outside entity (network, file, shared memory, etc).
Siri no workie. Of course that is the case now.
My pet peeve with young coders. Condition testing is hardly ever a consideration. You clearly learned back when coding was structured and had rules.
One thing I actually did with some commercial software I wrote - kind of as a joke - was put up one of my applications running in normal user mode... Then literally threw my cat onto the keyboard (gently folks). We always say "what if a cat walked across the keyboard?" at any given time... So I found out. ;-)
Exactly1
I cut my teeth on Fortran and punch cards also!
Exactly WHY would the capability of setting a modern device like an iPhone’s date to anything prior to the date of manufacture make ANY SENSE AT ALL? What is the point?
That's why I called it a "Stupid User Trick." It takes a really stupid user to do it after being warned it will brick your iPhone.
Good question. However, the adding such checks on every outside chance of a user doing every possible "Stupid User Trick" would increase the size of the core code to unweildlyness.
I too, cut my teeth on FORTRAN and Hollerith punch cards. I designed and programmed a database for the Emergency Food Bank I founded more than 30 years ago. I designed it so that we could take a person off the line of applicants and sit them down at the keyboard and with two hours training have them do intake interviews. However, it took over a year of my work to "idiot proof" that input process to prevent these people from finding ways to break the database or input garbage. After that year, though, that database ran for twenty years with no issues.
A supervisor could check the input at the end of the day and correct any errors if there were any, usually not. At the end of the month I could check the error log, and usually the number of corrected errors could be counted on the fingers of one hand.
However, for that first year, I was frequently astounded at the ways the users came up with to crash the system and the database or to input errors. . . and of course, by their very nature, they were always ways I had not anticipated. No programmer or designer can anticipate everything, or as a battle planner should realize, "no battle plan survives the first contact with the enemy!"
Same here, I used to do FORTRAN code on punched cards. Later, it was great to use time-sharing terminals for COBOL, easier to correct mistakes than wait for a punch machine.
Speaking of conditions that shouldn't happen, but can... I was entering code on a terminal in the shared terminal room, busy with a dozen people working away. A gal I was supervising was at the other end of the row, when she screamed out to me
"... I'm missing my period!".
I turned crimson red while the other guys laughed their heads off at me. My wife didn't laugh when she heard about it... ("Honey, it's COBOL!").
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.