When you are on the job for the government, you are acting as a government representative and not a private person. You can be fired for what you say while on the job.However, the police unions would never allow such a thing.
 First of all, we aren't even talking about the police saying anything out loud. We're talking about them turning their backs on the mayor while at a funeral which, while not verbal speech, is clearly a form of expression that would fall under the 1st amendment.Second, I suspect that a majority of the officers in question were not on the job while attending that funeral.
 So, what is actually new here?They had already announced the various parts of this, and the only link I see in here is a GitHub repo with links to other GitHub repos that we've already seen. Is there anything new in this announcement?
 I'm not familiar with the fraction button. Is this common on calculators? I don't see it on most of the basic function calculators that I look at. Hmm, taking a look around, it looks like it might be present on a lot of scientific calculators, but not the basic calculators I see. I had switched to RPN by the time I started using scientific calculators, so I guess I never became familiar with this button.Parentheses are common on scientific caclulators and graphing calculators, but as you demonstrate, they add a lot of extra button presses, and you even left out the final "=".To do this on an RPN calculator, you need nothing beyond the basic 4 functions and the enter key, while you need extra specialized keys like parens or a fraction button to do it on an infix calculator. Taking a look at various infix scientific calculators, they mostly seem to have both parens and a fraction key, so using up the space of 3 keys that an RPN calculator doesn't need and can use for more actual functionality.Here's how you do it on RPN:3 4 + 5 6 + / 7 8 + 9 2 + / +You wrote it in Polish notation rather than Reverse Polish Notation, and had left out the enter key that is used as the delimiter between two numbers (pushes a number to the stack, so you can start entering the next number).
 I generally just use dc on the command line. Pretty bare bones, but gets the job done.M-x calc in Emacs is a very full-featured RPN calculator.On Android, I use Droid48, a great HP48 emulator: https://play.google.com/store/apps/details?id=org.ab.x48 ; I also have RealCalc (https://play.google.com/store/apps/details?id=uk.co.nickfine...) installed, which I figured I'd use more due to the bigger buttons by default, but I still reach for Droid48 most often.
 M-x calc is pretty awesome. I had no idea it was there.. (M-x tetris I had heard of)I use dc and bc on the command line. Some people have chided me saying the command line calculators aren't always accurate and are buggy, but I haven't seen any problems.
 Really? I haven't heard of any bugs in the command line calculators. Do you know what kinds of bugs they were talking about? One thing to note is that they use arbitrary-precision decimal arithmetic (well, base-100 arithmetic internally, but that's equivalent), rather than fixed precision binary floating point arithmetic, so that may surprise some people (though it also reduces surprise for those who expect decimal arithmetic).Interesting tidbit, it seems that dc is the oldest language on Unix; it was ported before even an assembler was. (https://en.wikipedia.org/wiki/Dc_%28computer_program%29#Hist...)
 I did some digging. it was in this thread in a comment about bc and exponents (although I can't use a non rpn calculator on computers I just tend to type the formulas in):https://news.ycombinator.com/item?id=5054618a couple of replies to my comment there about exponents. specifically."bc is a pretty misleading calculator, without specifying rounding it thinks 2^(40/1.5) is 67108864.It's not even close.If you trust your finances to that, you could get in trouble. "
 Ah, thanks for digging that up. I was not aware that they didn't support fractions in exponents; I don't think I had ever tried them for that. Luckily they do give warnings, though only if you have already set the precision (via "bc -l" or something like "10 k" in dc).Sadly, since dc doesn't have a math library, it looks like you can't use the "e" function workaround unless you implement it yourself.
 Hmm. This seems to focus on a few issues that neatly fall into a sense of "progress" in social change, in which something changes in a number of states culminating in a Supreme Court decision that causes that change to affect the entire country.However, it ignores some issues that don't fall into such a pattern. For example, the issue of teaching evolution vs. creation in public schools; where teaching about evolution has never been questioned (as far as I know) in some states, while others have had laws on the books, and there is continuing pressure and laws that offer limited "workarounds" of the supreme court decision in order to promote "teaching the controversy", so it's not really a clear cut case of progress.Another that isn't covered is capital punishment; some states have never had capital punishment, some have repealed it over the years, and the Supreme Court briefly suspended it nationwide but it was reinstated later, and many states still practice it.Abortion, which is used as an example in this article, faces a similar problems as teaching of evolution. While abortion was allowed nationwide by Roe v. Wade, states are slowly introducing laws that restrict it so heavily that it's not available to a large fraction of people who need it. The turning point nationwide is being slowly turned back by laws that skirt the existing precedent.It seems like picking these couple of issues, to show how "it may happen again", is a bit disingenuous without also covering major cases in which change hasn't followed this pattern, or has backslid since the original change.
 I don't think capital punishment and creationism follow the same trend as women's suffrage, interracial marriage, etc. The issues in the article started with low state-level support and rapidly gained acceptance across the country; at some threshold the Supreme Court stepped in and said "this is now accepted as law nation-wide.I don't have the numbers to back this up, but I don't think creation teaching and capital punishment started at a low level of support and rapidly ramped up across many states. State-level legislation on creation-teaching is limited to a few conservative areas. Capital punishment has been around forever and support for it has fluctuated with the times.I agree that abortion doesn't really fit the pattern of the other issues in the article, though. Supreme court approval seems to have come prematurely in that case.
 The pattern is generally that Clang and GCC will have partial support when the standard is release, and full support a couple of years later. Intel will lag behind a year or two after that. Microsoft will be behind another year or two.So, let's say that C++17 does come out in 2017. It will probably be the case that some of the features will be ready to use in GCC and Clang right away, and around 2019 or so they should have full or nearly full support. 2021 for Intel. 2023 for Microsoft.So that gives you a range of answers. Depending on which features and which compiler, you could start using some of them immediately (or even before 2017, many of the features are implemented experimentally in advance), but if you want full support across the range of commonly used compilers, you're probably going to be waiting until the early to mid 2020s.
 It's frustrating having the proliferation of different package managers.Each one can work well in isolation; but when you then need to integrate with your platform package manager or another language's package manager, you get a combinatorial explosion of possible interactions.One example that I've been particularly frustrated by recently is Python/Emacs integration. I have Emacs and Python installed via my system package manager (apt). Then there are a bunch of Emacs modes that I need to install via the Emacs package manager (elpy and its dependencies). Those in turn have dependencies on Python packages (rope/flake8). And finally I have a bunch of different python packages that I work on that are all linked to from a virtualenv so that they'll all resolve properly in all of those tools.If I upgrade one part of that system (apt, emacs packages, python packages), it frequently breaks other parts, because there aren't any proper dependencies between them. I then have to spend a while fiddling with the whole setup to get it back up and running again.Basically, the more package managers you have, the less value they have. The whole point of package managers is to manage a whole set of packages together, so you don't have to manually go through and resolve all of the dependencies yourself, manually figure out which version of this package goes with what version of that package. But every time there is some dependency between two different package managers, that breaks down.Another part of the frustration is that they are all basically doing the same thing, but with slightly different implementations. In the end, a package manager's purpose is to let you figure out which packages you need, by resolving dependencies while honoring version constraints, fetch those packages from an archive somewhere (and verify that they are intact and haven't been tampered with), unpack them and install the files in the right places, and run some glue code to set up indexes, documentation, and so on appropriately. The only part of that task which really needs to differ between package managers is that glue code, plus the policies for inclusion in the centralized archive; everything else is basically solving the same problem in a whole bunch of slightly different ways (different ways of representing and comparing version numbers, different ways of verifying package integrity, different ways of doing local mirrors, etc), and so you get a whole bunch of incompatible and differently buggy implementations of the same kinds of things, or some functionality just missing from certain package managers.What I would really like to see is a single unified package manager core, that handles all of the basic functionality that they all set out to solve, with the ability to utilize multiple different repositories (so that different projects could have their own policies for inclusion and sets of packages that are designed to work together), and appropriate places to hook in all of the language (or distro) specific glue that you need. I've been mulling over trying to write such a package manager, but of course when doing so you need to be careful or you will run into this problem: https://xkcd.com/927/
 I agree with you in theory, but in practice the existing package managers are simply not suitable for the new languages (too fragmented, walled gardens, not powerful enough), so language designers really don't have any other solution except making their own manager. Ideally, though, a language's package manager would integrate nicely with the system's package manager and would know how to automatically install other packages.
 Oh, I know why it keeps on happening, but it leads to a frustrating and fragmented experience. That's why it would be nice to have a common core package manager, that handles all of the tasks that any package manager will need to handle (metadata, versions, dependencies, dependency resolution, conflicts, features, fetching packages, verifying packages, managing an archive of packages, etc), plus the ability to hook in at appropriate places to provide the distro or language specific hooks necessary, and the ability to have cross-archive dependencies (including union dependencies like "either these three Debian packages, these two Fedora packages, or this Homebrew package"). That would then let you focus on solving the common problems in one place, and leave each language or distro to only have to focus on its own particular glue and policies.
 It looks more schizophrenic than bot to me.