Studies have consistently found that prisoners who maintain close contact with their family members while incarcerated have better post-release outcomes and lower recidivism rates.
Studies have shown that capital punishment and execution of prisoners results in superb outcomes for society in general and ZERO recidivism rates!
This plus code: 9C3XGV25+H9 will get you to Buckingham Palace in London, UK. But transpose the G and the V letters (resulting in 9C3XVG25+H9) will place you in a rural area just outside Luton, some 30-odd miles away.
Even worse, if you mistakenly transpose any of the first four characters, which represent a large "area code" in plus code (i.e. transposing the C and the 3 resulting in 93CXGV25+H9) you end up in the ocean in the Gulf of Alaska - an entirely different continent!
Unless that pill also provides all the other necessities you need in life such as water, food, a roof over your head etc. then what would be the point of living - even a disease free existence - when you have no money and can't get any money to live due to the billionaire miracle pill inventors having it all?
Unfortunately, in today's world, it's far more profitable to destroy and harm than it is to create and improve...
FTFY. And therein lies the rub. So long as it's it's both easier and more profitable to do the wrong thing than the right thing, more people will do the wrong thing.
The CEO should have foreseen this and should be let go. As should other executives who approved the offshoring plan.
Yes, they'll probably be "let go". Right after they collect their multi million golden parachute, receive a hearty slap on the back from fellow members of the old boys network and walk right into another high paying CxO position in another multi-national organisation with nary a drop of ink to blot their copybook.
This is what happens when you treat your IT staff like your Janitorial staff.
It's often worse than this. I rarely see Janitorial staff having to "make do" with old threadbare mops and having to wash floors with water with no detergent. They are usually very well stocked for the specific things that they need to get their jobs done. IT staff? Not so much.
It doesn't mean that a company is employee-focused. It means that a company understands that it lives and dies by the capabilities of its employees, so it's in the company's interest to figure out what it takes to keep their workforce productive, possibly to even expand their productivity.
No, most companies care only about their employees as cogs in the machine. It's the function of the cog that they care about. The human being representing that cog, well, they're fungible and can be fairly quickly replaced with an equally fungible asset. Ergo, other than what is mandated by law, companies don't give a shit about you as a human being, only as the cog.
That's the difficult thing. It is all about the relationship and the environment.
In bad environments asking for a raise gets you fired. Asking for training (even if the company says they encourage it) gets you fired. Doing anything ambitious gets you fired, or have the things taken without credit. This type of company also fires people immediately if they make a mistake that has a cost.
In good environments asking for a raise starts a discussion that can get you money. Asking for training (even when the company has never encouraged it) can get one person or even a team of people some training. Being ambitious is rewarded openly and and given cautious praise: that in addition to doing the regular duties you also did the thing on the side. This type of company generally retains people who make costly mistakes who are also contrite and appear to learn the lesson; leaders know the company pays for the learning experience either way, the question is if they will retain the student of life's hard lessons.
The first type of company is the one to flee. The second is the type to cherish. If you don't know what to look for it is easy to miss the signs when finding the job.
And what about the 95% of companies that somewhere in the middle? Where asking for a raise doesn't get you fired, but doesn't get you a raise either. Same with training. Same with trying to introduce new ideas.
You can jump ship from one of these companies, but it's more likely than not that you'll end up somewhere else just the same.
Eric Lippert, a former Microsoft employee and one of the main designers of the C# language and someone who understands and appreciates functional programming (having brought many functional paradigms to C# such as lambdas etc.) responded to the question "Why hasn't functional programming taken over yet?" on StackOverflow, which for me, sums up everything I feel about functional programming.
I've quoted Eric's answer below, but the TL;DR is that I believe the future is neither purely functional, nor purely OO, but some hybrid of the two.
Because all those advantages are also disadvantages.
Stateless programs; No side effects Real-world programs are all about side effects and mutation. When the user presses a button it's because they want something to happen. When they type in something, they want that state to replace whatever state used to be there. When Jane Smith in accounting gets married and changes her name to Jane Jones, the database backing the business process that prints her paycheque had better be all about handling that sort of mutation. When you fire the machine gun at the alien, most people do not mentally model that as the construction of a new alien with fewer hit points; they model that as a mutation of an existing alien's properties.
When the programming language concepts fundamentally work against the domain being modelled, it's hard to justify using that language.
Concurrency; Plays extremely nice with the rising multi-core technology The problem is just pushed around. With immutable data structures you have cheap thread safety at the cost of possibly working with stale data. With mutable data structures you have the benefit of always working on fresh data at the cost of having to write complicated logic to keep the data consistent. It's not like one of those is obviously better than the other.
Programs are usually shorter and in some cases easier to read Except in the cases where they are longer and harder to read. Learning how to read programs written in a functional style is a difficult skill; people seem to be much better at conceiving of programs as a series of steps to be followed, like a recipe, rather than as a series of calculations to be carried out.
Productivity goes up (example: Erlang) Productivity has to go up a lot in order to justify the massive expense of hiring programmers who know how to program in a functional style.
And remember, you don't want to throw away a working system; most programmers are not building new systems from scratch, but rather maintaining existing systems, most of which were built in non-functional languages. Imagine trying to justify that to shareholders. Why did you scrap your existing working payroll system to build a new one at the cost of millions of dollars? "Because functional programming is awesome" is unlikely to delight the shareholders.
Imperative programming is a very old paradigm (as far as I know) and possibly not suitable for the 21th century Functional programming is very old too. I don't see how the age of the concept is relevant.
Don't get me wrong. I love functional programming, I joined this team because I wanted to help bring concepts from functional programming into C#, and I think that programming in an immutable style is the way of the future. But there are enormous costs to programming in a functional style that can't simply be wished away. The shift towards a more functional style is going to happen slowly and gradually over a period of decades. And that's what it will be: a shift towards a more functional style, not a wholesale embracing of the purity and beauty of Haskell and the abandoning of C++.
I build compilers for a living and we are definitely embracing a functional style for the next generation of compiler tools. That's because functional programming is fundamentally a good match for the sorts of problems we face. Our problems are all about taking in raw information -- string
Organizations can spot the risks of a new idea a mile away. But there’s a curious blind spot when it comes to the risks of not taking those risks. The path of least resistance is to play it safe and keep the idea as close to the tried-and-true as possible. We just need to ask Polaroid how that strategy works in the long run.
Executives and entrepreneurs face two very different sorts of risks. One is that their organization will make a bold move that failed — a risk they call ‘sinking the ship.’ The other is that their organization will fail to make a bold move that would have succeeded — a risk they call ‘missing the boat.’
Naturally, most executives worry more about sinking the boat than missing the boat, which is why so many organizations, even in flush times, are so cautious and conservative.
If I asked for 200 I may have gotten it, but they wouldn't have been happy.
On the assumption that you ask for and get the $200k, why wouldn't they be happy?
I mean, if they've determined you're skilled and experienced enough for the position in order to make you an offer, and they've further decided that they're willing to offer you $200k, why wouldn't they be happy about that?
Seems to me that if they were "unhappy" about any part of it, they wouldn't be extending you that offer in the first place, no?
No, you should never disclose your salary history to any prospective future employer.
Employers will ask this question for one reason and one reason only, to find the lowest possible offer you'd be willing to accept if they decide they want to offer you a position. Many people in this thread that are representing the employers perspective have said that they need this information in order to determine if a candidate's expectations are in line with their budget. Well, that can easily be achieved by either the employer being up front with the salary range on offer, or by asking the candidate not for their actual previous salaries but for their expected salary. That's a whole different question and one which you as a candidate should be prepared to answer (although ideally, you'll avoid giving a direct answer to this question also - see below). Of course, if you do give an answer here, you should still respond with a range rather than a specific number to allow that all important wiggle room within negotiations if you get far enough into the application process.
Too many employers here seem to be expecting the candidate to do half of their job for them - i.e. to divulge information that is detrimental to the candidate and helps the employer make a hiring decision (especially in the negative direction - i.e. helping the employer to discount the candidate rather than offering reasons to hire).
Here's some very useful tips I've picked up over the years for answering the "What is your current salary?" question without actually divulging the salary information the employer so desperately seeks. Also, some great answers to the "What salary are you seeking?" question, too. For this, use the Noel Smith-Wenkle method which avoids giving a direct answer and naming a number - something that will instantly give the other party the upper hand in any salary negotiation.
So, when asked "What is your current salary?", answers are: - "I'm seeking a salary in the range of $x to $y" (i.e. the Politician's answer - you answer a different question that what was asked). - “My current employer does not allow me to discuss the terms of my employment” - “This position is not exactly the same as my current job, so let’s discuss what my responsibilities would be here and then determine a fair salary for this job.” or finally, for really pushy interviewers: - “I’m happy to help you evaluate what I’d be worth to your business based upon my skills, experience and the value that I can add to your organisation, but my current salary is personal and confidential, just as the salaries of your own employees are.”
And the aforementioned Noel Smith-Wenkle method in a nutshell is that when asked "What salary are you seeking?" you give three answers for the number of times they repeat the question, or try to pin you down to mention a figure:
1st answer: "I am much more interested in doing (type of work) here at (name of company) than I am in the size of the initial offer." 2nd answer: "I will consider any reasonable offer." 3rd (and subsequent) answers: "You are in a much better position to know how much I'm worth to you than I am."
Slashdot Mirror
Studies have consistently found that prisoners who maintain close contact with their family members while incarcerated have better post-release outcomes and lower recidivism rates.
Studies have shown that capital punishment and execution of prisoners results in superb outcomes for society in general and ZERO recidivism rates!
God created man in his own image... .... And so man will create robots/AI in his own image.
So, I think it'll turn out more or less as the Perry Bible Fellowship suggests.
But the same problem applies to these plus codes.
This plus code: 9C3XGV25+H9 will get you to Buckingham Palace in London, UK. But transpose the G and the V letters (resulting in 9C3XVG25+H9) will place you in a rural area just outside Luton, some 30-odd miles away.
Even worse, if you mistakenly transpose any of the first four characters, which represent a large "area code" in plus code (i.e. transposing the C and the 3 resulting in 93CXGV25+H9) you end up in the ocean in the Gulf of Alaska - an entirely different continent!
Unless that pill also provides all the other necessities you need in life such as water, food, a roof over your head etc. then what would be the point of living - even a disease free existence - when you have no money and can't get any money to live due to the billionaire miracle pill inventors having it all?
Unfortunately, in today's world, it's far more profitable to destroy and harm than it is to create and improve...
FTFY. And therein lies the rub. So long as it's it's both easier and more profitable to do the wrong thing than the right thing, more people will do the wrong thing.
What else would I be using?
Foobar2000
Obligatory link: https://marketoonist.com/2014/...
have we found a way to get a robot to be POTUS?
Yes, I think we have.
The CEO should have foreseen this and should be let go. As should other executives who approved the offshoring plan.
Yes, they'll probably be "let go". Right after they collect their multi million golden parachute, receive a hearty slap on the back from fellow members of the old boys network and walk right into another high paying CxO position in another multi-national organisation with nary a drop of ink to blot their copybook.
This is what happens when you treat your IT staff like your Janitorial staff.
It's often worse than this. I rarely see Janitorial staff having to "make do" with old threadbare mops and having to wash floors with water with no detergent. They are usually very well stocked for the specific things that they need to get their jobs done. IT staff? Not so much.
Same way any big org avoids it. "Lobby" the government with $$$
It doesn't mean that a company is employee-focused. It means that a company understands that it lives and dies by the capabilities of its employees, so it's in the company's interest to figure out what it takes to keep their workforce productive, possibly to even expand their productivity.
No, most companies care only about their employees as cogs in the machine. It's the function of the cog that they care about. The human being representing that cog, well, they're fungible and can be fairly quickly replaced with an equally fungible asset. Ergo, other than what is mandated by law, companies don't give a shit about you as a human being, only as the cog.
That's the difficult thing. It is all about the relationship and the environment.
In bad environments asking for a raise gets you fired. Asking for training (even if the company says they encourage it) gets you fired. Doing anything ambitious gets you fired, or have the things taken without credit. This type of company also fires people immediately if they make a mistake that has a cost.
In good environments asking for a raise starts a discussion that can get you money. Asking for training (even when the company has never encouraged it) can get one person or even a team of people some training. Being ambitious is rewarded openly and and given cautious praise: that in addition to doing the regular duties you also did the thing on the side. This type of company generally retains people who make costly mistakes who are also contrite and appear to learn the lesson; leaders know the company pays for the learning experience either way, the question is if they will retain the student of life's hard lessons.
The first type of company is the one to flee. The second is the type to cherish. If you don't know what to look for it is easy to miss the signs when finding the job.
And what about the 95% of companies that somewhere in the middle? Where asking for a raise doesn't get you fired, but doesn't get you a raise either. Same with training. Same with trying to introduce new ideas.
You can jump ship from one of these companies, but it's more likely than not that you'll end up somewhere else just the same.
Eric Lippert, a former Microsoft employee and one of the main designers of the C# language and someone who understands and appreciates functional programming (having brought many functional paradigms to C# such as lambdas etc.) responded to the question "Why hasn't functional programming taken over yet?" on StackOverflow, which for me, sums up everything I feel about functional programming.
I've quoted Eric's answer below, but the TL;DR is that I believe the future is neither purely functional, nor purely OO, but some hybrid of the two.
Because all those advantages are also disadvantages.
Stateless programs; No side effects
Real-world programs are all about side effects and mutation. When the user presses a button it's because they want something to happen. When they type in something, they want that state to replace whatever state used to be there. When Jane Smith in accounting gets married and changes her name to Jane Jones, the database backing the business process that prints her paycheque had better be all about handling that sort of mutation. When you fire the machine gun at the alien, most people do not mentally model that as the construction of a new alien with fewer hit points; they model that as a mutation of an existing alien's properties.
When the programming language concepts fundamentally work against the domain being modelled, it's hard to justify using that language.
Concurrency; Plays extremely nice with the rising multi-core technology
The problem is just pushed around. With immutable data structures you have cheap thread safety at the cost of possibly working with stale data. With mutable data structures you have the benefit of always working on fresh data at the cost of having to write complicated logic to keep the data consistent. It's not like one of those is obviously better than the other.
Programs are usually shorter and in some cases easier to read
Except in the cases where they are longer and harder to read. Learning how to read programs written in a functional style is a difficult skill; people seem to be much better at conceiving of programs as a series of steps to be followed, like a recipe, rather than as a series of calculations to be carried out.
Productivity goes up (example: Erlang)
Productivity has to go up a lot in order to justify the massive expense of hiring programmers who know how to program in a functional style.
And remember, you don't want to throw away a working system; most programmers are not building new systems from scratch, but rather maintaining existing systems, most of which were built in non-functional languages. Imagine trying to justify that to shareholders. Why did you scrap your existing working payroll system to build a new one at the cost of millions of dollars? "Because functional programming is awesome" is unlikely to delight the shareholders.
Imperative programming is a very old paradigm (as far as I know) and possibly not suitable for the 21th century
Functional programming is very old too. I don't see how the age of the concept is relevant.
Don't get me wrong. I love functional programming, I joined this team because I wanted to help bring concepts from functional programming into C#, and I think that programming in an immutable style is the way of the future. But there are enormous costs to programming in a functional style that can't simply be wished away. The shift towards a more functional style is going to happen slowly and gradually over a period of decades. And that's what it will be: a shift towards a more functional style, not a wholesale embracing of the purity and beauty of Haskell and the abandoning of C++.
I build compilers for a living and we are definitely embracing a functional style for the next generation of compiler tools. That's because functional programming is fundamentally a good match for the sorts of problems we face. Our problems are all about taking in raw information -- string
Dear The Hoi Polloi,
We'll do what we want. What are you going to do about it?
Yours (up the a$$),
The CIA.
This is simply and succinctly explained in this cartoon, Safe Is Risky, from 2014.
In a nutshell:
Organizations can spot the risks of a new idea a mile away. But there’s a curious blind spot when it comes to the risks of not taking those risks. The path of least resistance is to play it safe and keep the idea as close to the tried-and-true as possible. We just need to ask Polaroid how that strategy works in the long run.
Executives and entrepreneurs face two very different sorts of risks. One is that their organization will make a bold move that failed — a risk they call ‘sinking the ship.’ The other is that their organization will fail to make a bold move that would have succeeded — a risk they call ‘missing the boat.’
Naturally, most executives worry more about sinking the boat than missing the boat, which is why so many organizations, even in flush times, are so cautious and conservative.
Are we talking about mental illness for the owner, or for the cat?
If I asked for 200 I may have gotten it, but they wouldn't have been happy.
On the assumption that you ask for and get the $200k, why wouldn't they be happy?
I mean, if they've determined you're skilled and experienced enough for the position in order to make you an offer, and they've further decided that they're willing to offer you $200k, why wouldn't they be happy about that?
Seems to me that if they were "unhappy" about any part of it, they wouldn't be extending you that offer in the first place, no?
No, you should never disclose your salary history to any prospective future employer.
Employers will ask this question for one reason and one reason only, to find the lowest possible offer you'd be willing to accept if they decide they want to offer you a position. Many people in this thread that are representing the employers perspective have said that they need this information in order to determine if a candidate's expectations are in line with their budget. Well, that can easily be achieved by either the employer being up front with the salary range on offer, or by asking the candidate not for their actual previous salaries but for their expected salary. That's a whole different question and one which you as a candidate should be prepared to answer (although ideally, you'll avoid giving a direct answer to this question also - see below). Of course, if you do give an answer here, you should still respond with a range rather than a specific number to allow that all important wiggle room within negotiations if you get far enough into the application process.
Too many employers here seem to be expecting the candidate to do half of their job for them - i.e. to divulge information that is detrimental to the candidate and helps the employer make a hiring decision (especially in the negative direction - i.e. helping the employer to discount the candidate rather than offering reasons to hire).
Here's some very useful tips I've picked up over the years for answering the "What is your current salary?" question without actually divulging the salary information the employer so desperately seeks. Also, some great answers to the "What salary are you seeking?" question, too. For this, use the Noel Smith-Wenkle method which avoids giving a direct answer and naming a number - something that will instantly give the other party the upper hand in any salary negotiation.
So, when asked "What is your current salary?", answers are:
- "I'm seeking a salary in the range of $x to $y" (i.e. the Politician's answer - you answer a different question that what was asked).
- “My current employer does not allow me to discuss the terms of my employment”
- “This position is not exactly the same as my current job, so let’s discuss what my responsibilities would be here and then determine a fair salary for this job.”
or finally, for really pushy interviewers:
- “I’m happy to help you evaluate what I’d be worth to your business based upon my skills, experience and the value that I can add to your organisation, but my current salary is personal and confidential, just as the salaries of your own employees are.”
And the aforementioned Noel Smith-Wenkle method in a nutshell is that when asked "What salary are you seeking?" you give three answers for the number of times they repeat the question, or try to pin you down to mention a figure:
1st answer: "I am much more interested in doing (type of work) here at (name of company) than I am in the size of the initial offer."
2nd answer: "I will consider any reasonable offer."
3rd (and subsequent) answers: "You are in a much better position to know how much I'm worth to you than I am."