At one time (and this might be true now), life insurance didn't tend to pay out for suicide, so there was a real incentive to find some way to call a self-inflicted death an accident. I don't know what the incentives might be elsewhere.
Having been where I am for over seven years, I get 5 weeks of PTO, and nearly free good-quality personal health insurance. Note that "PTO": in the last year I've had some medical issues that forced me to take off a significant amount of time, which means I effectively get less vacation time.
He's in a mandatory group insurance plan with a really big group. The savings are massive, and premiums are collected more by ability to pay. What's really important here is that, if he's flat broke and has a medical problem, he gets treatment. In the US, if flat broke, he'd have to go to an emergency room for an emergency and otherwise do without, and the emergency room will not do any long-term necessary treatment and will likely leave him with massive bills to face if he ever gets a decent income again.
US health care is good - provided you can afford it, which for most people means having a decent employer-provided insurance plan. Medical bills are a leading cause of bankruptcy in the US. Pre-ACA, if you had a serious medical condition and lost your job you were really screwed. With the ACA, there's at least a better chance of getting the care you need.
Code review makes sure people are programming according to a certain style, which can be done to avoid traps. If someone tried using a C-style array, or wrote "free" or "delete" in the main code, we'd spot it and not approve it. That removes some of the traps.
Code reviews won't necessarily catch traps that aren't a matter of style, but they can force a style that will prevent some of them.
Elsewhere in this thread, I've mentioned memory management (using C++ smart pointers) and buffer overflows (mentioning C++ vectors and strings). If you consistently use these, you will avoid some of the big problems people have with C, and your programs will be safer.
Except that the renters looking for $725/month aren't going to bid $725 under this arrangement. They'll have to lower the offer to feed Rentberry.
Also, how does this affect renegotiated rents when the lease is up? If the place goes up for auction again, it becomes a less desirable property, since it increases the chance that the tenant will have to move again sooner than the tenant wants to. If not, what's Rentberry's slice going to be?
I suspect that Rentberry apartments are going to become less desirable than non-Rentberry apartments, and that Rentberry landlords aren't going to make as much money as non-Rentberry on the whole. Of course, there's nothing to prevent ApartmentBay from opening and undercutting Rentbery's take. I wouldn't invest in Rentberry.
They may complain about the lack of DVD sales, but so can I. I can't get DVDs for some stuff I'd like to watch and keep. Offer me the DVDs and I'll buy them.
I don't get regular TV reception, and use the TV for Amazon Prime (we joined for the delivery service) and DVDs. I've had to mention this to people who apparently assumed I was watching the latest shows, and hope I didn't come off as feeling superior. (I also don't blame the TV, Amazon Prime, DVDs, or Starfleet for what we watch. It's our decision.)
Yeah. I'm wondering if I should jump in as Relativity Guy and start pointing out that this time stuff isn't fixed. Heck, from the point of view of the X-rays, they just left that galaxy, and referring to the time when the EM radiation gets here is very convenient in some respects.
Historically, when we eliminated jobs, we wound up with spare workers that did something else. No net job loss, we just produced more. (Of course, this process was neither immediate nor painless.) If we can eliminate jobs with automation, and find new productive things for the displaced workers to do, that's one thing. The fear with the robotic revolution is that robots will do most of the jobs that low-skill humans can do.
The individual goals are to make more money, not to eliminate jobs. If a machine can do a job a human is doing, and the machine is cheaper, the worker is out of there. There's no real limit to how cheap a machine can be, and there are limits for humans.
"Right to Work" means not having to join a union under any circumstances. What you're talking about is "at will" employment. Legally, someone could come around now and fire me for bad fashion sense, or for no reason at all. (There are things I can't legally be fired for. Good luck proving one of them applied.) Similarly, I could grab my stuff and walk out. It's all legal (although I probably wouldn't get paid for unused PTO if I didn't give notice).
I'd be in real trouble. I have a great deal of difficulty getting fingerprint readers to recognize me. I managed to get my iPhone to recognize my fingerprint about once or twice a year, and finally disabled fingerprint access.
Yeah, the syntax kinda sucks independently of the semantic problems.
C was designed to do anything, including systems software, and it was necessary to allow C-style pointers and memory models. C++ provides safe handles for sharp tools.
I normally use two lines, one creating a typedef (new name) for the function pointer, and then an array of those. I try to keep the syntax not looking too ugly. (There's no way of making some of this not look ugly.)
If you know C, bash, some compiler theory, and various Unix utilities, Perl still looks like the syntax depended on what Larry Wall had for breakfast when he designed that part.
Idiocy (to conform with your desire to start a post with an insult). There are C++ best practices. There's lots of books on them that more or less agree, and do agree on certain important points. (Example, use vectors instead of C-style arrays.) Also, if you think the ARM is of anything other than historical interest today, you don't know C++. The ARM was the base document for the 1998 Standard, which improved on it in important ways, and the 2011 and 2014 Standards improved on the 1998 Standard in important ways.
And, no matter how much you learn, some of your own judgments will be wrong. C++ is safer than C. You can deliberately write C++ to be as unsafe, but when used in a manner that's fairly easy to learn and is easily checked by code reviews it is safer.
Or you could learn C++ and how to use it. Well-written C++ avoids a lot of C gotchas. (By well-written, I'm not saying written by good C++ coders, but rather adhering to a style guide that can easily be checked in code review.)
C suffers from buffer overflows. Use C++ strings and containers and avoid all that.
C suffers from memory management problems, and C programs that use dynamic allocation typically lose track of memory or get obscure bugs. Use C++ smart pointers instead.
Large C functions often need cleanup code that can get out of sync with the main body of the functions. (Large functions are often necessary, or at least clearer than lots of little functions.) C++ destructors can handle a lot of that.
You can do binary search on an ordered sequence in memory, not just in a tree. It's tricky, and I've got lots of references to people not doing it right on the first try. (Knuth said it was published six years before a correct version was published.)
Except that the i5 in my laptop is a black box, even given the assembly code. What I know is that it will be translated into some sort of RISC code inside the processor, and there will be complicated things going on with those. The results of x64 assembly still trust a mysterious black box.
Slashdot Mirror
At my age, refocusing usually means tilting my head to get the right correction, and so it's faster than moving my head from screen to mirror.
At one time (and this might be true now), life insurance didn't tend to pay out for suicide, so there was a real incentive to find some way to call a self-inflicted death an accident. I don't know what the incentives might be elsewhere.
Having been where I am for over seven years, I get 5 weeks of PTO, and nearly free good-quality personal health insurance. Note that "PTO": in the last year I've had some medical issues that forced me to take off a significant amount of time, which means I effectively get less vacation time.
He's in a mandatory group insurance plan with a really big group. The savings are massive, and premiums are collected more by ability to pay. What's really important here is that, if he's flat broke and has a medical problem, he gets treatment. In the US, if flat broke, he'd have to go to an emergency room for an emergency and otherwise do without, and the emergency room will not do any long-term necessary treatment and will likely leave him with massive bills to face if he ever gets a decent income again.
Security is valuable.
US health care is good - provided you can afford it, which for most people means having a decent employer-provided insurance plan. Medical bills are a leading cause of bankruptcy in the US. Pre-ACA, if you had a serious medical condition and lost your job you were really screwed. With the ACA, there's at least a better chance of getting the care you need.
It's the tail recursion I learned about, primarily as applied to Lisp and dialects.
Yup. In C++, the preferred technique is to write your own comparison function, which is a more general but often somewhat clunky solution.
Code review makes sure people are programming according to a certain style, which can be done to avoid traps. If someone tried using a C-style array, or wrote "free" or "delete" in the main code, we'd spot it and not approve it. That removes some of the traps.
Code reviews won't necessarily catch traps that aren't a matter of style, but they can force a style that will prevent some of them.
Elsewhere in this thread, I've mentioned memory management (using C++ smart pointers) and buffer overflows (mentioning C++ vectors and strings). If you consistently use these, you will avoid some of the big problems people have with C, and your programs will be safer.
Except that the renters looking for $725/month aren't going to bid $725 under this arrangement. They'll have to lower the offer to feed Rentberry.
Also, how does this affect renegotiated rents when the lease is up? If the place goes up for auction again, it becomes a less desirable property, since it increases the chance that the tenant will have to move again sooner than the tenant wants to. If not, what's Rentberry's slice going to be?
I suspect that Rentberry apartments are going to become less desirable than non-Rentberry apartments, and that Rentberry landlords aren't going to make as much money as non-Rentberry on the whole. Of course, there's nothing to prevent ApartmentBay from opening and undercutting Rentbery's take. I wouldn't invest in Rentberry.
There's a lot of difference between a series of comic books and a superhero movie, also, so I'd consider them as original content.
They may complain about the lack of DVD sales, but so can I. I can't get DVDs for some stuff I'd like to watch and keep. Offer me the DVDs and I'll buy them.
I don't get regular TV reception, and use the TV for Amazon Prime (we joined for the delivery service) and DVDs. I've had to mention this to people who apparently assumed I was watching the latest shows, and hope I didn't come off as feeling superior. (I also don't blame the TV, Amazon Prime, DVDs, or Starfleet for what we watch. It's our decision.)
Yeah. I'm wondering if I should jump in as Relativity Guy and start pointing out that this time stuff isn't fixed. Heck, from the point of view of the X-rays, they just left that galaxy, and referring to the time when the EM radiation gets here is very convenient in some respects.
Historically, when we eliminated jobs, we wound up with spare workers that did something else. No net job loss, we just produced more. (Of course, this process was neither immediate nor painless.) If we can eliminate jobs with automation, and find new productive things for the displaced workers to do, that's one thing. The fear with the robotic revolution is that robots will do most of the jobs that low-skill humans can do.
The individual goals are to make more money, not to eliminate jobs. If a machine can do a job a human is doing, and the machine is cheaper, the worker is out of there. There's no real limit to how cheap a machine can be, and there are limits for humans.
"Right to Work" means not having to join a union under any circumstances. What you're talking about is "at will" employment. Legally, someone could come around now and fire me for bad fashion sense, or for no reason at all. (There are things I can't legally be fired for. Good luck proving one of them applied.) Similarly, I could grab my stuff and walk out. It's all legal (although I probably wouldn't get paid for unused PTO if I didn't give notice).
I'd be in real trouble. I have a great deal of difficulty getting fingerprint readers to recognize me. I managed to get my iPhone to recognize my fingerprint about once or twice a year, and finally disabled fingerprint access.
Yeah, the syntax kinda sucks independently of the semantic problems.
C was designed to do anything, including systems software, and it was necessary to allow C-style pointers and memory models. C++ provides safe handles for sharp tools.
I normally use two lines, one creating a typedef (new name) for the function pointer, and then an array of those. I try to keep the syntax not looking too ugly. (There's no way of making some of this not look ugly.)
If you know C, bash, some compiler theory, and various Unix utilities, Perl still looks like the syntax depended on what Larry Wall had for breakfast when he designed that part.
Idiocy (to conform with your desire to start a post with an insult). There are C++ best practices. There's lots of books on them that more or less agree, and do agree on certain important points. (Example, use vectors instead of C-style arrays.) Also, if you think the ARM is of anything other than historical interest today, you don't know C++. The ARM was the base document for the 1998 Standard, which improved on it in important ways, and the 2011 and 2014 Standards improved on the 1998 Standard in important ways.
And, no matter how much you learn, some of your own judgments will be wrong. C++ is safer than C. You can deliberately write C++ to be as unsafe, but when used in a manner that's fairly easy to learn and is easily checked by code reviews it is safer.
Or you could learn C++ and how to use it. Well-written C++ avoids a lot of C gotchas. (By well-written, I'm not saying written by good C++ coders, but rather adhering to a style guide that can easily be checked in code review.)
C suffers from buffer overflows. Use C++ strings and containers and avoid all that.
C suffers from memory management problems, and C programs that use dynamic allocation typically lose track of memory or get obscure bugs. Use C++ smart pointers instead.
Large C functions often need cleanup code that can get out of sync with the main body of the functions. (Large functions are often necessary, or at least clearer than lots of little functions.) C++ destructors can handle a lot of that.
You can do binary search on an ordered sequence in memory, not just in a tree. It's tricky, and I've got lots of references to people not doing it right on the first try. (Knuth said it was published six years before a correct version was published.)
Except that the i5 in my laptop is a black box, even given the assembly code. What I know is that it will be translated into some sort of RISC code inside the processor, and there will be complicated things going on with those. The results of x64 assembly still trust a mysterious black box.