Interest in "Systems" level understanding has never been so low.
It doesn't help that
Systems Software Research is Irrelevant according to Rob Pike and the other UNIX weenies who helped to kill it. Until now, I was only familiar with the title, but I found it only takes a few minutes to read. He seriously thinks Plan 9 to be something meaningfully distinct, just like the kind of guy who thinks his C-flavoured ALGOL clones are meaningfully different.
I found a funny line in here:
Rob Pike said:
The future is distributed computation, but the language community has done very little to address that possibility.
He mentions Perl, but not Erlang in his little paper.
Now Erlang had only left Ericsson for a year at that point, but still, and it's not as if Erlang was the first language to do what it did.
Mostly, I think this is because actually interfacing with Systems isn't done any more, everything runs off of an API
Yes, this is how a proper system is designed. Projects such as the Linux kernel make people think bit-banging is the proper way to request something of hardware, when high-level messages are a much better method. Really, the entire model of
drivers rather than explicitly making the hardware act like an independent object is another conversation.
Moving away from C makes this worse, and Rust also makes this worse, as instead of learning the Systems interfaces, the community reaches for """SAFE""" wrappers.
I've written an Ada binding to POSIX Sockets without involving any C language code on my side. Even with Ada's standardized facilities for interoperating with it, the experience was still terrible: I had to wade through header files just to find basic shit like type definitions and the numerical values of what pass for macros. I wrote a low-level binding that basically wrapped around the C language procedures (
socket,
bind,
recvfrom, and
sendto) while making them a bit more convenient; I then used that library to write a high-level package that exposed an entirely different interface, one actually pleasant to use. There's nothing about the hardware that makes POSIX Sockets necessary, it's just in the way, because it's been there for nearly half a century. That's it.
I may have said it earlier in this thread but if you couldn't figure out how to install Windows XP / Vista / Linux, then you failed the basic competency test.
Here's a reminder that Richard Stallman has never installed GNU/Linux and doesn't know how. He could figure it out, certainly, but what use is that knowledge, really?
It feels like the programming trends of today are entirely defined by the challenges of a couple of decades ago.
I completely agree.
I remember learning early Rust and being sold on it as the way to code highly parallel programs.
Alan Kay had children writing massively parallel programs without issues a long time ago, while the average C++ programmer shits himself with not even sixteen threads of execution.
Here, I've got a real programming question for the thread this time. I've written the following C11 code in an attempt to get some information out of the compiler, which I liken to squeezing blood from a stone:
C:
#include <stdio.h>
#include <sys/socket.h>
#include <sys/types.h>
int
main ()
{
ssize_t s;
socklen_t t;
if (2 == SOCK_DGRAM)
printf("SOCK_DGRAM = 2\n");
else
printf("SOCK_DGRAM /= 2\n");
if (2 == AF_INET)
printf("AF_INET = 2\n");
else
printf("AF_INET /= 2\n");
if (32 == MSG_TRUNC)
printf("MSG_TRUNC = 32\n");
else
printf("MSG_TRUNC /= 32\n");
if (_Generic(s, long: 1, default: 0))
printf("ssize_t is long\n");
else
printf("ssize_t isn't long\n");
if (_Generic(t, unsigned int: 1, default: 0))
printf("socklen_t is unsigned integer\n");
else
printf("socklen_t isn't unsigned integer\n");
return !((2 == SOCK_DGRAM)
&& (2 == AF_INET)
&& (32 == MSG_TRUNC)
&& (_Generic(s, long: 1, default: 0))
&& (_Generic(t, unsigned int: 1, default: 0)));
}
In Common Lisp, I've got functions like INSPECT, DESCRIBE, and TYPE-OF that make this utterly basic task as simple as it should be. The C language, lacking any vocabulary with which to discuss itself, has nothing. I looked into getting LLVM to spit out useful information, and was greeted with a lot of automatically generated documentation for hundreds of C++ language routines. Notice the best I could do here is use
_Generic, which is what Common Lisp calls TYPECASE, to see if I'd included the true type, but I've got no means by which to figure out the type unless I already know every type it could be.
Now, an acquaintance wrote his own POSIX Sockets binding for Ada, and just wrote enough C language routines to ignore all of this shit, by having the routines accept a new type kept in sync between them, and only returning simple
Int return codes, but I knew I could do better. My library works, and has worked for years, but this would be a pain if I ever cared about someone else using it. Does anyone here know a way to get what I want?
