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...
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?
Obligatory link: https://marketoonist.com/2014/...
have we found a way to get a robot to be POTUS?
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 -- strings and metadata -- and transforming them into different strings and metadata. In situations where mutations occur, like someone is typing in the IDE, the problem space inherently lends itself to functional techniques such as incrementally rebuilding only the portions of the tree that changed. Many domains do not have these nice properties that make them obviously amenable to a functional style.
Dear The Hoi Polloi,
We'll do what we want. What are you going to do about it?
Yours (up the a$$),
The CIA.
Adapt. Enjoy. Survive.
