129 karma · joined February 23, 2019
Moreover, this axiom is _independent_ of the other axioms in ZFC. It is in fact possible to have entirely self-consistent "worlds" of mathematics, ones where axiom of choice is true, and ones where it is false.
More details and examples of alternate axioms are in the Wikipedia article: https://en.wikipedia.org/wiki/Axiom_of_choice
If it seems weird that math can give you contradictory results, remember that the difference only shows up when you deal with some form of infinity (e.g. when performing an operation on an infinitely large set). For any usage of math in the real world, the truth or falsity of this axiom won't give you contradictory results.
So journal publication is not the only means of recognition.
Speaking of which, computer science is a bit weird in that conference papers tend to have higher visibility than journals, even though the latter still has some of its grandfathered glory. Not all conferences are equal, obviously. Some have a more rigorous submission process than others. But our field definitely carries a bit of skepticism about the value added by journal publishers.
You might find it interesting to look at the actual sqlite source commits where this change was introduced: https://sqlite.org/src/timeline?r=larger-databases It turns out the number comes from having a max of 2^32 pages in their database. Their default page being 4 kB each: https://www.sqlite.org/pgszchng2016.html
Working backwards, they must have raised it to 64kb: `python -c 'print(1024 * 64 * 232)'` produces 281,474,976,710,656.
> SQLite was originally designed with a policy of avoiding arbitrary limits. [...] Unfortunately, the no-limits policy has been shown to create problems. Because the upper bounds were not well defined, they were not tested, and bugs were often found when pushing SQLite to extremes.
That said, if you do not have actual data or experience to back up what you are preaching, I definitely welcome the call for caution. It is not useful to insist that "everyone should learn a certain skillset" unless you found those skills relevant in practice in some situation.
It sounds like you've been compiling an interesting collection of stories, ones that might be interesting to a lot of folks here.
That interpretation makes sense to me when I read the docs, but is way too easy to miss when I'm actually doing comparisons.
I'm sure you know exactly how much of which filter to apply for similar results. Laymen like ourselves will need a lot more trial and error. Their contribution here is to provide a push-button, automated mechanism.
I would have probably also tried something simple and given up due to the noise. So this is definitely interesting.
There nothing in between.
mv foo-<tab>
mv foo-bar-baz foo-<tab>
mv foo-bar-baz foo-bar-baz
Now I can edit the second part pretty quickly.Downside: you have to at least type `foo-` twice.
Upside: command line history still has the full command.
Have you ever tried wiring any non-trivial logic without flip-flops? Say, a simple signal routing layer. Even the most basic bits of logic becomes much less efficient to downright impossible without storage.
Protects that don't do that are therefore unlikely to remain interesting for long.
In other words, intraprocedural optimisation has always been more aggressive than interprocedural optimisation. If you try inlining every function ever into one giant function, you'll be forced to scale back optimization levels.
Unix file systems, and its philosophy of "everything is a file". It wasn't common before Unix to interact with devices through a filesystem. Somebody noticed that simple tasks like "listing with ls" and "hex-dumping with xxd" doesn't need separate utilities for files vs devices, and thus made the abstractions converge. If you ask me, this is the kind of abstraction I wouldn't normally think of. It's useful to know what kind of things to be on the lookout for.
The second example is fuzzing. At least today, it's still kind of painful to have to manually write fuzz-tests for everything we care about. Manually coming up with good test cases is also hard. But remember those Monad laws in Haskell? https://wiki.haskell.org/Monad_laws these are essentially free fuzzing code. If I implement something as a Monad, at least in theory I should be able to reuse existing fuzz-drivers to test my new code as well. I probably would not have had the patience to come up with good tests myself. Similarly for other categories. Again, it's good to know what general interfaces already exist.
Buggy code is not the problem, but a buggy process is.
Most server-side applications should never have to know what these concepts even are. Or any library that is not user-facing. They get bytes from the UI layer, and they can keep them as opaque bytes. For user-facing apps, you can ask your renderer library for a pixel-width or similar for a string, and let them handle how to parse it. Very little code ever needs to know about unicode.
Any kind of input-sanitization is vastly simplified in utf8, and that makes it worth it for me. For me the really troubling trends are conventions like Rust Utf8Error, where they can cause what I'd consider a UI-related exception in code that had no business even interpreting what those bytes are. Unfortunately, every API uses strings, so they are kind of hard to avoid. It introduces what I'd consider a software layering problem.
Maybe others here with more experience with internationalization can chime in and tell me I'm wrong.