If Unicode had used a full 32 bits from the start, it could have usefully reserved a few bits as flags that would divide it into subspaces, and could be easily tested.
Imagine a Unicode like this:
8:8:16
- 8 bits of flags.
- 8 bit script family code: 0 for BMP.
- 16 bit plane for every script code and flag combination.
The flags could do usefuil things like indicate character display width, case, and other attributes (specific to a script code).
Unicode peaked too early and applied an economy of encoding which rings false now in an age in which consumer devices have two digit gigabyte memories, multi terabyte of storage, and high definition video is streamed over the internet.
You're no longer talking about ASCII. ASCII has only a double quote, apostrophe (which doubles as a single quote) and backtick/backquote.
Note on your Mac that the Option-{ and Option-}, with and without Shift, produce quotes which are all distinct from the characters produced by your '/" key! They are Unicode characters not in ASCII.
The apostrophe is shown as a closing quote, by slanting to the right; approximately a mirror image of the backtick. So it looks as though those two are intended to form an opening and closing pair. Except, in many terminal fonts, the apostrophe is a just vertical tick, like half of a double quote.
The ' being veritcal helps programming language '...' literals not look weird.
This is by design, so that case conversion and folding is just a bit operation.
The idea that SOH/1 is "Ctrl-A" or ESC/27 is "Ctrl-[" is not part of ASCII; that idea comes from they way terminals provided access to the control characters, by a Ctrl key that just masked out a few bits.
I learned about from 6502 machine language programming, from some example that did a simple bit manipulation to switch lower case to upper case. From that it became obvious that ASCII is divided into four banks of 32.
Been an ASCII-naut since the 80's, so .. its always amusing to see people type 'man ascii' for the first time, gaze upon its beauty, and wonder at its relevance, even still today ...
Yes, the diagram just shows the ASCII table for the old teletype 6-bit code (and 5-bit code before), with the two most significant bits spread over 4 columns to show the extension that happened while going 5→6→7 bits. It makes obvious what was very simple bit operations on very limited hardware 70–100 years ago.
(I assume everybody knows that on mechanical typewriters and teletypes the "shift" key physically shifted the caret position upwards, so that a different glyph would be printed when hit by a typebar.)
"You're using AI wrong. First, you need to get an agent (chat windows are so 2023). Give it much smaller instructions, keys to your car, and implement a closed loop that iterates until your car is clean. "
In the world of Kubernetes and languages where a one-liner brings in a graph of 1700 dependencies, and oceans of Yaml, it's suddently important for a C thing to be one file rather than two.
C libraries have advertised "header-only" for a long time, it's because there is no package manager/dependency management so you're literally copying all your dependencies into your project.
This is also why everyone implements their own (buggy) linked-list implementations, etc.
And header-only is more efficient to include and build with than header+source.
> And header-only is more efficient to include and build with than header+source.
Dispute.
This is C code. You can't just drop it in and build it; you have to write code to use it. You have to figure out the API to correctly use it. If memory is passed around by pointers, you have to understand the responsibilities: who allocates, who frees, who may touch what when.
In the first place, you have to decide whether to commit to that library that far; it might not be until you've done some exploratory programming with it that you want to scrap it and find another one.
The cost of adding two files versus one is practically nothing in consideration of the larger picture.
The separate header model is baked into the C mindset; the tooling readily supports it.
Many "header only" libraries are secretly two files in one. When you define a certain preprocessor symbol before including the file, you get the implementation bits. When you don't define that symbol, the header is a pure header.
That means you have to pick some existing .c file which will define the preprocessor symbol and include the heaader. That source file becomes a "surrogate" source file, taking the place of the source file it ought to have.
There's a number of extremely shitty vendor toolchain/IDE combos out there that make adding and managing dependencies unnecessarily painful. Things like only allowing one project to be open at a time, or compiler flags needing to be manually copied to each target.
Now that I'm thinking about it, CMake also isn't particularly good at this the way most people use it.
They are certainly bad vendor toolchain, but I want to push back against the idea that this is a general C problem. But even for the worst toolchains I have seen, dropping in a pair of .c/.h would not have been difficult. So it is still difficult to see how a header-only library makes a lot of sense.
One of the worst I've experienced had a bug where adding too many files would cause intermittent errors. The people affected resorted to header-izing things. Was an off-by-one in how it was constructing arguments to subshells, causing characters to occasionally drop.
But, more commonly I've seen that it's just easier to not need to add C files at all. Add a single include path and you can avoid the annoyances of vendoring dependencies, tracking upstream updates, handling separate linkage, object files, output paths, ABIs, and all the rest. Something like Cargo does all of this for you, which is why people prefer it to calling rustc directly.
People certainly sometimes create a horrible mess. I just do not see that this is a good reason to dumb everything down. With a proper .c/.h split there are many advantages, and in the worst case you could still design it in a way that it is possible "#include" the .c file.
I tried to use cargo in the past and found it very bad compared to apt / apt-get (even when ignoring that it is a supply-chain disaster), essentially the same mess as npm or pip. Some python packages certainly wasted far more time of my life than all dependencies for C projects I ever had deal with combined.
I consider it compiler abuse to #include a source file. Useful for IOCCC competitions though.
Apt is fine for local development, but it's a bit of a disaster for portability and reproducibility. Not uncommon to see a project where the dependencies either have unspecified versions whose latest versions in universe are incompatible, or where the package has been renamed and so you have to search around to find the new name. Plus package name conventions are terrible. libbenchmark-dev, libgoogle-perftools-dev, and libgtest-dev are all library packages from the same company. The second one is renamed to gperftools-lib with RPM repos, to further compound the inconsistency.
I find myself dealing with package and versioning rename issues regularly in the CI pipelines I have using apt.
Well, I consider it abuse of header files to put an implementation in there. And comparing including a c-file to IOCCC seems very exaggerated.
My experience with dependencies in Debian-derived distributions is actually very good, far less problematic than any other packaging system I ever used. But yes, one needs to maintain dependencies separately for RPM and others distributions. But obviously the problem is not lack of a package manager and adding another one would not solve anyhing: https://xkcd.com/927/ The solution would be standardizing package names and versions across distributions.
It goes without saying that they are optimizing for engagement with their platform/app and user growth, just like every last digital huckster on the internet.
To keep people hooked while making them feel that the app is working, even though they are not getting their end result.
You have it backwards. The apps aren't training the human preferences, the human preferences are training the apps. There have been a LOT of different dating app ideas, and all have been competed away except for the ones that provide users the biggest perception of optionality.
And human behavior is absolutely shaped by our environments and systems. We're quite easily manipulatable - whether we want to admit/realize it or not.
Social media literally hired human behaviorists to design their apps to make them more addicting. You're quite mistaken if you dont think apps arent engineered to drive human behavior.
Dark Patterns are very prominent and well known thing in tech UI.
I mean competed away. There are a lot of dating apps out, probably a lot more than you think. Zero of them were bought out by Match before the market made them huge.
That's how variables are declared in BCPL, the language he designed and implemented in 1967. Keyword "LET", comma-separated list of names, "=", comma-separated list of expressions (that will be used to initialize the variables). For rare cases when one deliberately wants to leave a variable uninitialized, constant-valued expression "?" exists.
It appears that the author of this work invented the word 雪華 (sekka); it originates in that book. Other than that, a snow crystal is just called ゆきの結晶 (yukinokesshō).
Imagine a Unicode like this:
8:8:16
- 8 bits of flags. - 8 bit script family code: 0 for BMP. - 16 bit plane for every script code and flag combination.
The flags could do usefuil things like indicate character display width, case, and other attributes (specific to a script code).
Unicode peaked too early and applied an economy of encoding which rings false now in an age in which consumer devices have two digit gigabyte memories, multi terabyte of storage, and high definition video is streamed over the internet.
reply