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.
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.
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).
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).
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.
If you really don't care about the license, just use MIT. It has the best combination of simplicity, compatibility with every other license, and it's already known and used in just about every collection of any sizeable amount of free or proprietary software.
Trying to go even further by using a weird, probably not legally enforceable declaration like this one, or other oddball things like public domain dedications, the Unlicense, the WTFPL, or CC0 is just likely to lead to more confusion, more problems with legal ambiguities in different jurisdictions, simply more time spent reading and evaluating the licenses to make sure there's nothing hidden or that it does have legal meaning in your jurisdiction, etc.
Yes, there are a few prominent examples of public domain dedication that are widely used, like SQLite. They make it work out by actually having all contributors sign an affidavit, and additionally charging a fee for people who really do want or need a license rather than the public domain dedication. Thus, being public domain is actually more work and more friction for the project than if everyone just licensed their contributions under a permissive license like MIT.
Plus, of course, 'public domain' is a very fuzzy concept and in some countries either doesn't exist or else exists in a very different form to the US. It's a legal minefield both the the producer and the consumer; way, way better to ignore it completely and use an OSI license.
(Apropos of nothing, I generally prefer the BSD-2 clause license to the MIT one because I think it's clearer and easier to understand, but they're fundamentally equivalent.)
> Some scholars really grok grammar, and are excellent at teaching it, yet they haven't written great novels. I'm thinking of William Strunk Jr (of "The Elements of Style" fame), for example.
Not sure that Strunk, or the successor Strunk and White, are good examples here; they didn't "really grok grammar", in fact, they were pretty bad at both understanding it and teaching it, and their advice consists of a lot of incorrect information and vague platitudes. E. B. White was actually a good writer, but much of his writing violates the prescriptions in The Elements of Style.
So, this is exactly why it's an interesting question to test if the suggestions in the "Effective C++" series are actually good suggestions, or are just someone expounding rules that sound good in theory but don't actually help in practice.