> That was explicitly labelled an experimentation, so don't judge it as something in which I've more confidence.

There's nothing wrong with that, I'm just pointing out that I've seen very few systems that lacked essential complexity and that at the same time were... useful. One of them was my old Romanian ZX Spectrum clone, which took sometimes an hour to load the larger 8-bit games off the magnetic tape, but that didn't even have an ethernet port; and I suspect the cost of adding ethernet alone (without the rest of the networking stack) would be non-trivial.

> I try to prefer implementing for myself what I can, but it's not reasonable for everything, currently, no.

> Every network operation is unreliable. No packet is guaranteed. Thus it follows that motion is impossible.

... theoretically. In practice, the particular HTTP server hosting this blog serves web pages just fine and the blog also has a comment mechanism, which is what it was intended for in the first place. This supposed paradox actually ties pretty well into the mathematics thread above and below, thank teh Lords for infinitesimal calculus!

> Just because a man can shit himself to death doesn't mean we should build computers to do the same.

Again, this must sound really annoying: I don't disagree at all, but let's consider that Nature (if anything deserves a personification, I guess it's "nature") has spent millions of years attempting to perfect autonomous systems that nevertheless have this failure mode. The Big Question is, can any non-trivial autonomous systems be built that *don't* have this failure mode?

> I don't recall Euclid's Elements having these issues

I'm not saying *some* problems cannot be solved elegantly. I myself am more interested in problems along the lines of acoustic modelling, which are the subject of thick books comprising just as thick equations with partial derivatives that I'm not at all equipped to present here. Or more generally, take some of the fluid dynamics problems which can only be solved numerically... I haven't visited this field in a while, but to my eye it's just one of the many examples of impedance mismatch between the beautiful Platonic ideals and reality.

I went through your easy-peasy-tcp example

That was explicitly labelled an experimentation, so don't judge it as something in which I've more confidence.

Do you think me a fool for resorting to this, rather than someone who values his time?

Neither of us knows the other well enough to call him a fool, so no. Compare it to what I do, however. I'll try to go without than get trapped. I didn't write the HTTP server I use, but I wrote my Gopher server. I try to prefer implementing for myself what I can, but it's not reasonable for everything, currently, no.

I will rather use C than resort to this sort of nonsense.

Not everything is worth doing, I agree.

Precisely this -- I don't think C is particularly the problem here, rather than the bizarre design of TCP and all the implementation issues that derive from it.

Every network operation is unreliable. No packet is guaranteed. Thus it follows that motion is impossible.

The "design" of humans allows each single individual to be deadlocked without recourse, that alone does not make it (or them) garbage.

We're stuck with our design, for now. Just because a man can shit himself to death doesn't mean we should build computers to do the same.

mkstemp may be of some help here? I really don't know.

The point is it can fail, and the greater operation may have had no naturally intractable failure case. This is condemnation of bad design.

This is a very naive view of the history of mathematics, which went through an evolution spanning centuries before reaching the distilled form currently present in the didactic material.

I don't recall Euclid's Elements having these issues, although I'm not finished reading my copy, I'll admit.

Still and again, I suppose this is a tangent. Feel free to have the last word.

I went through your easy-peasy-tcp example and... well, I'll digress and instead challenge you to consider a less trivial task, that of a WWW server written in Common Lisp. Consider that it took me ten humongous articles (minus the summary) to fully document the code, *minus* its dependencies; and consider that that task made me realize that I was attempting to rewrite Wordpress in Common Lisp, which task I gave up and instead moved on to the actual Wordpress, based upon that PHP abomination we all know. Do you think me a fool for resorting to this, rather than someone who values his time?

Similarly, consider my attempt to a much more approachable task, i.e. to write a fault-tolerant IRC bot in the same language, and the reasons why I gave up. I wish all the luck to whomever may try this again in the future, and I don't particularly blame Common Lisp or SBCL for this failure, just don't come biting me in the ass about how "everything would be ok had I just used FFI". I will rather use C than resort to this sort of nonsense.

> a TCP connection can fail for many reasons and may result in failure from which there's no reasonable recovery mode

Precisely this -- I don't think C is particularly the problem here, rather than the bizarre design of TCP and all the implementation issues that derive from it. I'm not talking out of my ass here either, as I've read reasonable chunks of the Linux TCP implementation numerous times, when dealing with some of those intractable failure cases. Those failure cases did not come from C or Linux or whatever, they came from the TCP implementation itself, which is an unmaintainable horror that should have never made it into the kernel, for it fails to adhere to even the most basic "guidelines" laid out by Torvalds himself.

> the design of the system allows most any program to be deadlocked without recourse, meaning it's garbage.

The "design" of humans allows each single individual to be deadlocked without recourse, that alone does not make it (or them) garbage.

> Some interface requires a file, so a unique file must be created

mkstemp may be of some help here? I really don't know.

> One of the primary issues with computing is how an idiot can build a broken interface, which humans must then work around indefinitely

Verisimilitude, I'm not disagreeing with you here, merely pointing out that quite often, folks tend to attempt to solve problems using the wrong means. Maybe you don't actually *need* to create a unique file for that interface? I don't know, I'm merely considering this side of the issue.

> This wasn't an issue with mathematics

This is a very naive view of the history of mathematics, which went through an evolution spanning centuries before reaching the distilled form currently present in the didactic material. Consider the example that Lord Newton's calculus is as much a consequence of his Lordship as much as his genius, or in other words that politics can't be simply brushed aside from this history. Consider also some of the very unprincipled methods (e.g. approximations) used by some of the practitioners (e.g. physicists) and that some mathematicians had to literally invent new mathematics (e.g. the Dirac delta function) in order to model their experiments.

Bringing this back to computing, my best guess is that despite the obvious amplification brought about by computers, the field, aged less than a century, is probably just about nearing its stage of puberty. Whether this stage will be further delayed by the incoming dark ages, or whether war will actually speed up the maturization process (as they often do), I guess we'll see.

because all I/O (occuring between the von Neumann machine's "main memory" and "peripheral devices") was squeezed together into the abstraction called "file", which file doesn't even behave consistently

Yes, exactly.

However, this is the cost of a self-proclaimed general purpose abstraction for I/O, the alternative being e.g. the DOS way, where each and every application came bundled with drivers for the peripherals they used, with the exception of... actual files, of course.

There are alternations. I've written about exactly this here:

I firmly believe proper system design takes pain unto itself to eliminate edge cases. A proper such system would provide the option of treating wildly different I/O sources as the same, but permit the reducing of failure cases for any single one by permitting avoiding this. It may seem reasonable to give a terminal, file system, and TCP similar interfaces, yet this group poses necessarily different failure cases. The source of input for a terminal is usually a human and so a read can't fail, with a potentially indefinite wait; a file system can make a request, yet fail due to recognized hardware failure or semantic issues with the underlying model; a TCP connection can fail for many reasons and may result in failure from which there's no reasonable recovery mode. Collapsing these under a lone interfaces collapses their failure modes into a single model, as well, and it should be realized the addition of invariants through a lack of genericity is valuable.

We see similar idiocy with Unicode, and pouring the edge cases of all languages and other nonsense into one vase.

Now, did they work by accident?

No, but the design of the system allows most any program to be deadlocked without recourse, meaning it's garbage.

As for pwd, I seemed to have outdated information. Consider a different example: Some interface requires a file, so a unique file must be created, which opens it to naming conflicts, space exhaustion, and other nonsense. To repeat myself, when this nonsense becomes an ingredient for the real recipe, it only gets in the way.

One of the primary issues with computing is how an idiot can build a broken interface, which humans must then work around indefinitely. This wasn't an issue with mathematics, if only because the practitioners were their computers, and so valued concision and beauty, lest they rewrite something to have those qualities.

> Consider that the write system call can fail indefinitely, with no recourse

I agree; now let's consider that all software written on top of Unix (including, but not limited to, all emulators and high-level language implementations) is doomed to use it. And let us further consider why this "indefinite failure" is the case (at least as far as I can tell): because all I/O (occuring between the von Neumann machine's "main memory" and "peripheral devices") was squeezed together into the abstraction called "file", which file doesn't even behave consistently: sometimes it's a socket, other times it's a pipe, while other times who even knows what is it... a "device", eh?

I'm not attempting to exonerate the folks who made POSIX from their idiocy. However, this is the cost of a self-proclaimed general purpose abstraction for I/O, the alternative being e.g. the DOS way, where each and every application came bundled with drivers for the peripherals they used, with the exception of... actual files, of course. This is where the perversity lies: that even though POSIX *claims* to provide a general-purpose abstraction for I/O, in practice the application will be forced to implement an ad-hoc driver for whichever "/dev/X" it attempts to talk to.

As far as I'm concerned, it's liberating to spell this out, despite the fact that, as I mentioned, I did implement sane applications using write. Now, did they work by accident?

> the pwd command may conform to POSIX by returning a single period

The spec pretty clearly states otherwise.

A machine code is more well specified than a Forth, generally. When I write machine code, and when I read it, I evaluate it in my head first; if the true execution fails, I may have entered something incorrectly, or the implementation be flawed. It will be one or the other.

Still, I suppose this is a tangent. Feel free to have the last word.

I know; and I'm not debating this aspect, as I know it having taken my time to go through the specs. I am however debating the argument against size as a principal issue, as it sounds too similar to the old high school moaning "I didn't read War and Peace because it was too long". The main argument against this problem of size is my having read the specs: yes, the items in question are full of flaws, but this may only be determined by reading them and pointing out the flaws in question, not just bitching about bloat.

> and have intractable failure cases

I don't know what this means. I know what is an intractable problem, I know what is a failure case, but I have no clue how a specification/system can "have intractable failure cases". Perhaps an example or two would help here?

> Both of these systems force irrelevant problems to be solved for which there's no good solution

I am not debating that said systems pose problems, but I'm not sure which of them you consider irrelevant (and more importantly, irrelevant *in what context*?) and to what extent there is no good solution available (and "good" *in what context*?). Can you give two examples of such problems?

> [...] both as in CHIP-8

Then why choose CHIP-8 and why not, say, Forth?

> At the lowest levels

My point, as stated above, is that the lowest level is always the physical iron. Simply because CHIP-8 ran on RCA hardware back in the '70s does not mean you can wave away that you are running it, say, on a *nix machine in the 2020s, nor that you are using a *nix machine to browse the web. Sure, it's nice to get rid of complexity, but one doesn't simply get rid of it by "changing the language", but by pushing it to another layer. Otherwise you are going to hit that complexity one way or another, simply by using the system, some systems just manage to hide it better than others. In other words, *everything* in engineering (and in economics and life in general) is to be paid for some way or another, there is no such thing as "for free".

From this point of view, one example would be that C and POSIX are not evil because they "force irrelevant problems", but because they force them upon the application developers, who need not be concerned with pointerisms and various undefined behaviours. Still, I personally have written correct programs, using subsets of C and POSIX, which did not require all the complexity specified in the standards and that, similarly, had clear, reasonable invariants. So to my eye the underlying issue is rather that some abstractions are better at solving *certain* problems than others and, circling back to that old problem of operating systems/language environments, that there is no such thing as a "general-purpose" tool, or in other words, that things are hammers only inasmuch as they're good at driving nails into certain materials specified beforehand.

TL;DR: I'm well beyond discussing this stuff in terms of hyperboles and I find arguments along the lines of "X is The Right System" to be a waste of time. If you still think this makes me obtuse, then let's leave it at that.

There's a difference between that and having no instruction timing guarantees and so using the system timer to its fullest, or not assuming a certain value comprises a flag generated by an instruction, both as in CHIP-8.

The focus here is that, in such machine code hacking, I can establish invariant cases easily, more easily than in some higher-level languages, even good such languages. At the lowest levels, I can compress a world of variation and uncertainty into a single known point.

If specification is equivalent to "knowing the full system", then by this criterion alone I deem POSIX and C to be enough. So what are we talking about, then? If size by itself, without an underlying reason, is a criterion for this criticism of yours, then I am unimpressed and not interested.

Sure, I understand that small systems entail small specifications, which may make for good didactic exercises; I also understand that the discussion of size is absolutely needed when establishing economic limitations such as memory size; hell, I may even give it that it's fun to approach the field of systems design from a minimalist perspective, for purely artistic purposes, i.e. that "distilled essence" you mentioned. But you don't properly bother to put the subject of critique in context other than some vague mention of "machine code hacking", which isn't a subject in and of itself in the world I inhabit, but rather a small activity in an otherwise vast field.