Even if this is discrimination, I'm also not clear that this is discrimination against fathers. It might well be discrimination against mothers. Fathers only have to spend eight weeks caring for the new baby. Mothers have to spend twelve.
After which you send it to the centralized child care facility, so the child is never a burden to either parent ever again?
I'm pretty sure both parents are on the hook for child care for as long as the child is a child. The issue is whether they're also on the hook for going to a job other than raising their child.
My high-tech employer only offers TWO weeks paid paternity leave. TWO. Not the generous eight that Yahoo! offers. That was probably considered progressive in the US in the 60s, but seems hopelessly behind the curve in high tech today. One of my coworkers took an extra two weeks out of his own vacation time to spend a total of four paid weeks with his newborn daughter.
I personally have 8 weeks of vacation time built up, because work keeps me busy enough that I never feel like I can take the time I'm entitled to off. I don't even feel like I can ask for the time off, and it's technically already mine. The culture works against it. We're a country of workaholics, and we're made to feel bad when we ask for a little space.
If we really wanted to do things "right" here in the US, I'd have to ensure I built up a big enough cushion that my wife and I could remain unemployed (and thus, unpaid) for a couple years. And then, hope I could find a job after 2 years out of high tech. Hmmm... yeah, seems unlikely. Or, at least, feels unlikely, even if perception doesn't match reality.
Ah, the American dream: To make enough money that you no longer have to work for a living. For the vast majority of us, it will always remain a dream.
Why it is that every time the moron politicians of the world reach for the cutting budget scissors they cut education, healthcare and social programs?
Hint: It's usually a rich politician whose family and friends wouldn't suffer the cuts directly. They sell it by painting the beneficiaries as slackers that are a drain on society, as opposed to the reality. These things solidify the very base of society.
Net result? An ever widening chasm between the haves and the have-nots. That chasm strains the very notion of society.
You either needed a PEB + Editor/Assembler (which I didn't have), or you could by the Mini Memory cartridge which comes with the Line-by-Line Assembler (which I did have) that left you 768 bytes free to program at location >7D00 (out of 4K total battery-backed memory)
You certainly could not, however, program assembly code on an unexpanded TI-99/4A. You needed at least the Mini Memory cartridge.
TI Extended BASIC didn't have PEEK and POKE in the same sense as other Microsoft BASICs. In other computers, you could literally read and write any location. TI Extended BASIC let you PEEK certain locations, but not really POKE anywhere.
The Mini-Memory did add a PEEKV and POKEV that let you manipulate VDP RAM, but again, that required the Mini Memory cartridge. (I don't know if E/A also provided anything like that; I didn't have E/A.) And if Mini Memory's plugged in, you don't get TI Extended BASIC.
There are a lot of good points in this thread. It's worth noting that there's no direct replacement for experience. You bring N years of experience to the job, and the only thing that can bring you N years of experience is N years of doing the job. While you can teach some the broad lessons (and, I would say, teach them specifically in the context of this app; you're not a professor and you're not teaching a class), there's no replacement for experience.
When I was fresh out of college, I could write programs that did very interesting and useful things. Now it's *mumblety* years later, and I know for a fact I would write my programs far differently now, with generally much better outcomes in maintainability, scalability and flexibility. Much of that was learned through trial and error—ie. experience. That only comes with time and practice.
Sure, very little current flows through the transistor's gate. But, the transistors themselves are imperfect switches, and so you get some current flowing from Vdd to Vss all the time anyway. For the products I tend to work on, around half or more of the power consumption comes from leakage, amazingly.
For the uninitiated: CMOS gates consist of a pair of complementary switches. One set connects Vdd (the positive voltage indicating a logic '1') to the output node, and the other set connects Vss or GND (the zero voltage indicating a logic '0') to the output node. The way CMOS works, there should only be one path from either Vdd or Vss to the output node. All other paths must be open.
The simplest example is an inverter. It has two switches. The switch from Vdd to output opens with the input is 1 and closes when the input is 0. The switch from Vss to output does the opposite: Closes when the input is 1 and opens when the input is 0.
CMOS burns power two main ways. The first and most obvious way is through switching, also called dynamic power. When the output goes to '1', the gate outputs a high voltage. This voltage then charges all of the gates connected to that output. Even if the gates don't leak, they still end up taking on a certain amount of charge due to their capacitance. The total charge taken on is V*C, where V is the voltage and C is the total capacitance of all the inputs this gate drives. Later, when the gate's output switches to 0, all that charge flows back out to ground. The more often you switch an output from 1 to 0, the more charge you ratchet from Vdd to Vss. Furthermore, while you're switching, there's often a very brief period when the two switches are both slightly closed. You can get some current racing directly from Vdd to Vss at this time.
The second, perhaps less obvious way CMOS burns power is through leakage. Modern transistors are far from perfect switches. When they're closed, they conduct, and when they're open they also conduct, just not as well. This leads to a phenomenon known as leakage. That is, even when the gates aren't switching, there's a constant current from Vdd to Vss, because the transistors haven't completely cut off the current flow. You can sometimes address this by lowering the input voltage or using transistors with different threshold voltages, but that trades off speed for leakage.
So, while the promise of CMOS is that no current flows when gates don't switch, the actuality is that tiny transistors in modern processes aren't as good at holding up to that ideal.
And before you cry foul because I picked different years, please note I picked the same quarter, and the peak quarter for the year for both years. You can also look at the Y/Y growth and extrapolate the 2011 numbers from 2012. The Y/Y growth numbers were negative, meaning it fell slightly, and yet TVs are about 2 orders of magnitude larger than public displays.
So, yeah, I was off a bit. It's 2 orders of magnitude. Still, that drives a lot more economies of scale in the TV market.
That's the total market for public displays. Now what proportion of these public displays are actually appropriate for e-Ink? And how does that compare to consumer uses, such as e-readers for volume?
Large market in terms of "highly visible by many, many people," but small market relative to the volume of displays shipped. I'd say there's at least a 3-order-of-magnitude difference here.
One strange typo I make often is to close a parenthetical with a quote, rather than a parenthesis. (Something like this. Weird, I know." I don't know why. Brain damage, I'm sure.
That's a great question. You start to need a concept of transactions and rollback in more places. Databases already have this. Journaling filesystems already do this to an extent. (Btrfs actually COWs, so you theoretically could roll back to an older version also.)
I'm not saying you can do this everywhere, but I think it's a strategy that can find a home many places.
Speaking of iOS: Are you saying that if the battery is low, the phone should shut off without warning, saving all data, or give a few warnings as the battery gets low? The no-error-alert paradigm is just stupid.
My car warns me when it detects a failure, and I think it's no failure of software designers if they also warn me when things are amiss. I'd hate it if my car just tried to "handle" low fuel, low oil pressure, low tire pressure, or what-have-you, as about the only thing it could do for any of those is just stop. iOS devices are in a similar circumstance with low battery.
Are you still of the opinion that there should never be an error alert unless it's the programmer admitting some sort of failure? "I failed to program an infinite capacity battery."
Make forking exceptionally cheap, and move to a checkpoint-and-commit paradigm. Fork just before the first open(), go acquire all your resources (open(), malloc(), etc.). Depending on whether all that succeeds or part of that fails, you know which thread to kill. Kill the thread that did the open, etc. if that path failed, otherwise kill the thread that's waiting at the last checkpoint.
If that sounds at all familiar, it should. Most modern CPUs already do this in hardware. It's called speculative execution, and they do one of these forks at nearly every branch.
In this example, what if the failing function just returned NaN, and you let the NaNs propagate? I guess in some cases you care which of factorial(), zeta() or geommean() failed, but more often you care whether the expression as a whole failed or not.
Hmmm... so if I ask a program to read a file that doesn't exist, should it just create an empty document of that name? Possibly the right answer for a word processor, but quite probably the wrong answer when specifying an attachment to an email.
I think that statement needs to be clarified: An internal error alert pop-up that could happen without a hardware failure is an admission of failure on the part of the programmer, no doubt. But, if the user truly is in error, there's nothing to admit on the programmer's part when they tell the user they're wrong. The program still has to check the user, though.
How to I find users that won't give it incorrect or inconsistent input, or hardware that won't fail unexpectedly? I don't program the users, and I've yet to find 100% reliable hardware that never wears out.
"Never test for an error condition you don't know how to handle." -- Steinbach's Guideline for Systems Programmers.
Ah, that's a bit different. It's advice as to what level you should place your error checking. For example, if you do "fd = open(... )", you probably should at least check the file descriptor, since you know you can't proceed without it. But, you don't know how to fix it, so pass it up. But, if a subsequent call to "write( )" fails, most of the time you don't actually care. (In the event you do care, because it's critical that your write succeed, then check. But, I argue in most cases, it's OK to let the write silently fail; folks will notice their disk got full in other ways.)
yes you really do care. Once you've started using exceptions for normal things, then you quickly find your program will be throwing the buggers all the time. In many server applications you'll be getting 3 or 4 exceptions per request (I see this, even in the Microsoft code that you have no control over)
Wow, that sounds like the programming equivalent of bumper bowling.
I happen to agree that exceptions should be left to exceptional events—something entirely outside the scope of the algorithm—and not something that seems well within the purview of the task at hand. For example, when validating data sets, which is something it sounds like your code does, detecting and handling an invalid datum sounds like the code's raison d'etre. An exception here would be ridiculous.
Another example might be a parser of some sort (for example, in the compiler itself). If it detects an error in the input, that's not an exception. It's a well defined state transition in the parser. Exception handling is not error handling in the general sense. It's only for errors for which the right course of action isn't even knowable except perhaps a couple levels up, and is unlikely to happen much in practice.
For example, if you have data structures that automatically resize to fit whatever your program needs, and you hit an OOM situation, what then? There's likely to be no good way forward. You want to unwind far enough that you can leave things in as consistent a state as possible, and otherwise probably just crash with a hopefully-useful error message. Depending on the nature of the program, "crash" could mean widely different things here. If it's a command-line program or a restartable system service, "error message and exit" is probably the best thing. If it's a GUI environment, if you can close the document or whatever triggered the blow-up and free the resources, that's probably a better idea.
Drifting topics here...
I'm fortunate that most of the programming I have to do is best served by Perl's "die", "croak" and "carp" functions. Usually, whatever error my scripts encounter is best handled outside the script, because the error is either bad input, or a bug in the code. Neither of those can really be handled within the script itself. So, we pop out an error message and a stack trace and say "here, you fix it."
Before you say "you're putting an undue burden on your users," most of this code is developed for ourselves to use. I work with a chip design team, and we manufacture and eat our own dog food. Just as the scaffolding around a skyscraper-under-construction doesn't need to be ADA compliant ("What, no wheelchair ramp up here?"), our scripts for internal use don't need quite as much polish as something we'd ship as a product.:-)
That said, I do also work on code that I intend other less-technical people to use. It takes considerably more work to make that code bulletproof and friendly. I'd say more work goes into polish than into the core algorithms.
The defining aspect is the medium the craft is flying through. The solar wind has dropped from supersonic to nil, and the Sun's magnetic field is about to be superseded by the overall galactic magnetic field. I'd say that's a pretty good definition of transitioning from the solar system's medium to the interstellar medium, since the space the craft is floating through has changed qualitatively.
I guess it's a bit like the difference between the boundary of the Earth's atmosphere, and the orbit of the Moon. The Moon is gravitationally bound to the Earth, but the Earth's atmosphere ends well before you get to the Moon. Where do you say the boundary of space is as you leave the Earth?
Slashdot Mirror
After which you send it to the centralized child care facility, so the child is never a burden to either parent ever again?
I'm pretty sure both parents are on the hook for child care for as long as the child is a child. The issue is whether they're also on the hook for going to a job other than raising their child.
My high-tech employer only offers TWO weeks paid paternity leave. TWO. Not the generous eight that Yahoo! offers. That was probably considered progressive in the US in the 60s, but seems hopelessly behind the curve in high tech today. One of my coworkers took an extra two weeks out of his own vacation time to spend a total of four paid weeks with his newborn daughter.
I personally have 8 weeks of vacation time built up, because work keeps me busy enough that I never feel like I can take the time I'm entitled to off. I don't even feel like I can ask for the time off, and it's technically already mine. The culture works against it. We're a country of workaholics, and we're made to feel bad when we ask for a little space.
If we really wanted to do things "right" here in the US, I'd have to ensure I built up a big enough cushion that my wife and I could remain unemployed (and thus, unpaid) for a couple years. And then, hope I could find a job after 2 years out of high tech. Hmmm... yeah, seems unlikely. Or, at least, feels unlikely, even if perception doesn't match reality.
Ah, the American dream: To make enough money that you no longer have to work for a living. For the vast majority of us, it will always remain a dream.
Hint: It's usually a rich politician whose family and friends wouldn't suffer the cuts directly. They sell it by painting the beneficiaries as slackers that are a drain on society, as opposed to the reality. These things solidify the very base of society.
Net result? An ever widening chasm between the haves and the have-nots. That chasm strains the very notion of society.
You either needed a PEB + Editor/Assembler (which I didn't have), or you could by the Mini Memory cartridge which comes with the Line-by-Line Assembler (which I did have) that left you 768 bytes free to program at location >7D00 (out of 4K total battery-backed memory)
You certainly could not, however, program assembly code on an unexpanded TI-99/4A. You needed at least the Mini Memory cartridge.
TI Extended BASIC didn't have PEEK and POKE in the same sense as other Microsoft BASICs. In other computers, you could literally read and write any location. TI Extended BASIC let you PEEK certain locations, but not really POKE anywhere.
The Mini-Memory did add a PEEKV and POKEV that let you manipulate VDP RAM, but again, that required the Mini Memory cartridge. (I don't know if E/A also provided anything like that; I didn't have E/A.) And if Mini Memory's plugged in, you don't get TI Extended BASIC.
You also had to account for VIC-II fetches in the fastloader, since it could cycle steal from the 6502 and screw things up.
There are a lot of good points in this thread. It's worth noting that there's no direct replacement for experience. You bring N years of experience to the job, and the only thing that can bring you N years of experience is N years of doing the job. While you can teach some the broad lessons (and, I would say, teach them specifically in the context of this app; you're not a professor and you're not teaching a class), there's no replacement for experience.
When I was fresh out of college, I could write programs that did very interesting and useful things. Now it's *mumblety* years later, and I know for a fact I would write my programs far differently now, with generally much better outcomes in maintainability, scalability and flexibility. Much of that was learned through trial and error—ie. experience. That only comes with time and practice.
Yeah, except that the main use of Excel is apparently to make lists. (You might need to scroll down a little.)
Next up: A phone with a negative number of buttons! It removes buttons from other objects it comes in contact with.
Sure, very little current flows through the transistor's gate. But, the transistors themselves are imperfect switches, and so you get some current flowing from Vdd to Vss all the time anyway. For the products I tend to work on, around half or more of the power consumption comes from leakage, amazingly.
For the uninitiated: CMOS gates consist of a pair of complementary switches. One set connects Vdd (the positive voltage indicating a logic '1') to the output node, and the other set connects Vss or GND (the zero voltage indicating a logic '0') to the output node. The way CMOS works, there should only be one path from either Vdd or Vss to the output node. All other paths must be open.
The simplest example is an inverter. It has two switches. The switch from Vdd to output opens with the input is 1 and closes when the input is 0. The switch from Vss to output does the opposite: Closes when the input is 1 and opens when the input is 0.
CMOS burns power two main ways. The first and most obvious way is through switching, also called dynamic power. When the output goes to '1', the gate outputs a high voltage. This voltage then charges all of the gates connected to that output. Even if the gates don't leak, they still end up taking on a certain amount of charge due to their capacitance. The total charge taken on is V*C, where V is the voltage and C is the total capacitance of all the inputs this gate drives. Later, when the gate's output switches to 0, all that charge flows back out to ground. The more often you switch an output from 1 to 0, the more charge you ratchet from Vdd to Vss. Furthermore, while you're switching, there's often a very brief period when the two switches are both slightly closed. You can get some current racing directly from Vdd to Vss at this time.
The second, perhaps less obvious way CMOS burns power is through leakage. Modern transistors are far from perfect switches. When they're closed, they conduct, and when they're open they also conduct, just not as well. This leads to a phenomenon known as leakage. That is, even when the gates aren't switching, there's a constant current from Vdd to Vss, because the transistors haven't completely cut off the current flow. You can sometimes address this by lowering the input voltage or using transistors with different threshold voltages, but that trades off speed for leakage.
So, while the promise of CMOS is that no current flows when gates don't switch, the actuality is that tiny transistors in modern processes aren't as good at holding up to that ideal.
How about some data? 3Q11 saw around 750K units world wide for plasma and LCD public displays according to this link., whereas the North American and Chinese LCD and plasma TV market for 3Q12 was closer to 54M units, according to this link from the same source.
And before you cry foul because I picked different years, please note I picked the same quarter, and the peak quarter for the year for both years. You can also look at the Y/Y growth and extrapolate the 2011 numbers from 2012. The Y/Y growth numbers were negative, meaning it fell slightly, and yet TVs are about 2 orders of magnitude larger than public displays.
So, yeah, I was off a bit. It's 2 orders of magnitude. Still, that drives a lot more economies of scale in the TV market.
That's the total market for public displays. Now what proportion of these public displays are actually appropriate for e-Ink? And how does that compare to consumer uses, such as e-readers for volume?
Seems more likely they're watching for taggers.
Large market in terms of "highly visible by many, many people," but small market relative to the volume of displays shipped. I'd say there's at least a 3-order-of-magnitude difference here.
One strange typo I make often is to close a parenthetical with a quote, rather than a parenthesis. (Something like this. Weird, I know." I don't know why. Brain damage, I'm sure.
Game Cube Network, perhaps? At least that's what GCN means in the context of Mario Kart.
That's a great question. You start to need a concept of transactions and rollback in more places. Databases already have this. Journaling filesystems already do this to an extent. (Btrfs actually COWs, so you theoretically could roll back to an older version also.)
I'm not saying you can do this everywhere, but I think it's a strategy that can find a home many places.
Are zeta or geommean even remotely useful on ints?
Speaking of iOS: Are you saying that if the battery is low, the phone should shut off without warning, saving all data, or give a few warnings as the battery gets low? The no-error-alert paradigm is just stupid.
My car warns me when it detects a failure, and I think it's no failure of software designers if they also warn me when things are amiss. I'd hate it if my car just tried to "handle" low fuel, low oil pressure, low tire pressure, or what-have-you, as about the only thing it could do for any of those is just stop. iOS devices are in a similar circumstance with low battery.
Are you still of the opinion that there should never be an error alert unless it's the programmer admitting some sort of failure? "I failed to program an infinite capacity battery."
Make forking exceptionally cheap, and move to a checkpoint-and-commit paradigm. Fork just before the first open(), go acquire all your resources (open(), malloc(), etc.). Depending on whether all that succeeds or part of that fails, you know which thread to kill. Kill the thread that did the open, etc. if that path failed, otherwise kill the thread that's waiting at the last checkpoint.
If that sounds at all familiar, it should. Most modern CPUs already do this in hardware. It's called speculative execution, and they do one of these forks at nearly every branch.
In this example, what if the failing function just returned NaN, and you let the NaNs propagate? I guess in some cases you care which of factorial(), zeta() or geommean() failed, but more often you care whether the expression as a whole failed or not.
Hmmm... so if I ask a program to read a file that doesn't exist, should it just create an empty document of that name? Possibly the right answer for a word processor, but quite probably the wrong answer when specifying an attachment to an email.
I think that statement needs to be clarified: An internal error alert pop-up that could happen without a hardware failure is an admission of failure on the part of the programmer, no doubt. But, if the user truly is in error, there's nothing to admit on the programmer's part when they tell the user they're wrong. The program still has to check the user, though.
I guess the "innovation" here is that it brought it to a C like language? And errno sucks because it's a single global.
How to I find users that won't give it incorrect or inconsistent input, or hardware that won't fail unexpectedly? I don't program the users, and I've yet to find 100% reliable hardware that never wears out.
Ah, that's a bit different. It's advice as to what level you should place your error checking. For example, if you do "fd = open( ... )", you probably should at least check the file descriptor, since you know you can't proceed without it. But, you don't know how to fix it, so pass it up. But, if a subsequent call to "write( )" fails, most of the time you don't actually care. (In the event you do care, because it's critical that your write succeed, then check. But, I argue in most cases, it's OK to let the write silently fail; folks will notice their disk got full in other ways.)
yes you really do care. Once you've started using exceptions for normal things, then you quickly find your program will be throwing the buggers all the time. In many server applications you'll be getting 3 or 4 exceptions per request (I see this, even in the Microsoft code that you have no control over)
Wow, that sounds like the programming equivalent of bumper bowling.
I happen to agree that exceptions should be left to exceptional events—something entirely outside the scope of the algorithm—and not something that seems well within the purview of the task at hand. For example, when validating data sets, which is something it sounds like your code does, detecting and handling an invalid datum sounds like the code's raison d'etre. An exception here would be ridiculous.
Another example might be a parser of some sort (for example, in the compiler itself). If it detects an error in the input, that's not an exception. It's a well defined state transition in the parser. Exception handling is not error handling in the general sense. It's only for errors for which the right course of action isn't even knowable except perhaps a couple levels up, and is unlikely to happen much in practice.
For example, if you have data structures that automatically resize to fit whatever your program needs, and you hit an OOM situation, what then? There's likely to be no good way forward. You want to unwind far enough that you can leave things in as consistent a state as possible, and otherwise probably just crash with a hopefully-useful error message. Depending on the nature of the program, "crash" could mean widely different things here. If it's a command-line program or a restartable system service, "error message and exit" is probably the best thing. If it's a GUI environment, if you can close the document or whatever triggered the blow-up and free the resources, that's probably a better idea.
Drifting topics here...
I'm fortunate that most of the programming I have to do is best served by Perl's "die", "croak" and "carp" functions. Usually, whatever error my scripts encounter is best handled outside the script, because the error is either bad input, or a bug in the code. Neither of those can really be handled within the script itself. So, we pop out an error message and a stack trace and say "here, you fix it."
Before you say "you're putting an undue burden on your users," most of this code is developed for ourselves to use. I work with a chip design team, and we manufacture and eat our own dog food. Just as the scaffolding around a skyscraper-under-construction doesn't need to be ADA compliant ("What, no wheelchair ramp up here?"), our scripts for internal use don't need quite as much polish as something we'd ship as a product. :-)
That said, I do also work on code that I intend other less-technical people to use. It takes considerably more work to make that code bulletproof and friendly. I'd say more work goes into polish than into the core algorithms.
The defining aspect is the medium the craft is flying through. The solar wind has dropped from supersonic to nil, and the Sun's magnetic field is about to be superseded by the overall galactic magnetic field. I'd say that's a pretty good definition of transitioning from the solar system's medium to the interstellar medium, since the space the craft is floating through has changed qualitatively.
I guess it's a bit like the difference between the boundary of the Earth's atmosphere, and the orbit of the Moon. The Moon is gravitationally bound to the Earth, but the Earth's atmosphere ends well before you get to the Moon. Where do you say the boundary of space is as you leave the Earth?