Do some projects in this direction even exist? Or are we going to stick around with abstractions of things even most people's grant great parents haven't ever seen because this tech was already long obsolete at their time?
Thanks for the links!
This looks like the future.
It does everything 100% correctly.
(Now "only" the rusty Unix commands need to get evolved into some proper interactive language and this would be the perfect CLI.)
I'm impressed heavily. Going to install this ASAP to play around with it.
We should get rid of all the historic accidents. Really.
Imho it's completely crazy how computers "work" today.
Modern computers still need to emulate "a PDP-7" because that's the only kind of machine C runs on fast.
But the sequential command stream machine (which is the abstract machine of C) is extremely inefficient. It's a mayor pain to extract parallelism from an inherently sequential command stream! We built crazy shit like "hardware JIT compilers", that are embedded nowadays in all CPUs, only so the CPU can maintain the PDP-7 illusion to the outside world (which is, in the end, still C, and nothing else) even it's a proper data-flow machine internally.
But because all the SW world is build in C (or languages that work the same) nobody invests in alternative architectures. Because C would not run fast on such machines, and they would fail in the market if you would need to rebuild the whole SW world first to get any advantage.
C (and, tragicomicaly its portability) was a trap!
And we will die a painful death even before anybody would start to think to finally remove the von Neumann bottleneck (which is inherent to sequential command stream machines with RAM).
I for my part would love if someone would invest in something like a modern take on the Connection Machine, but build form the ground up with a HW-SW co-design approach. (Of course this would be some work; you would need to build the hardware, which is comparably easy, but also some adequate programming language and ecosystem, up to a completely new designed operating system, and convince people to "rewrite the world" for your new system — which is the hard part).
> from the ground up (bits and bytes)
In this context it should read "(trits and 'trytes')" (only that we would maybe need a new world as trytes are historically six trits, but would be better 9 trits; so we could directly use a septemvigesimal system, which maps excellently to the English alphabet + "point"), and it should be of course balanced.
Time to finally switch to the most efficient information encoding, when we're at it! (Binary was also just an historic accident, chosen because it was most easy implemented on the ancient integrated circuits).
The use of C as a scapegoat is odd. What alternatives would have led to a different world of processors? Pascal? PL/I? Experiments in parallelism at the time like Erlang are about process-level parallelism, not the kind of instruction-level parallelism this line of argument calls for.
You absolutely can have simpler systems than we use today, but let's not fool ourselves about how we got here.
That's not a "cliche". It's the reality how computers work today.
Internally they're data-flow machines since quite some time. But they need to emulate a command stream machine (which did not change fundamentally since the time of the PDP-7!) to the outside world.
> Explicit instruction-level parallelism has its own issues that make it difficult to use effectively, precisely because it must do statically what out-of-order processors do dynamically.
That's why nobody here ever talked about "explicit instruction-level parallelism"…
> The use of C as a scapegoat is odd.
No it isn't, as the success of C is the root of all evil in this case.
> What alternatives would have led to a different world of processors? Pascal? PL/I?
No, of course not. Because Pascal or PL/I are of course also "just C" (with some minor, and regarding this consideration here, completely irrelevant differences).
> Experiments in parallelism at the time […]
Are irrelevant.
The topic is: How would things look like if we would start over with all what we know now, and with our current technical capabilities.
> the kind of instruction-level parallelism this line of argument calls for.
At least I have talked explicitly about data-flow (and nothing else)!
Imho the whole command stream based approach is a dead end.
Dynamically reconfigurable data-flow hardware (with local scratch memory instead of RAM) is imho the answer.
But of course it's almost impossible to compile sequential command streams (aka. "imperative programs", which is synonym to C and all languages that work the same, so actually almost all languages in existence) into anything that could be efficiently executed on such data-flow hardware. That's why you would need to "rewrite the world" form scratch to get any benefits from finally sane hardware (instead of the expected degradation in case you would try to map our current sequential command streams into this new world).
Too bad it was so unstable I stopped using it. Should maybe give Enlightenment another try in the coming year.
https://saitoha.github.io/libsixel/
But that's just another "layer of craziness", imho. (Even it's quite cool).
I think the whole terminal should be replaced. Not even with something funky. Just a proper RPC + streaming protocol based on some sane modern tech. (No, no HTTP! Simple and lightweight. Tailor made for the task. So it works also in an embedded setting; and lasts for the next 50 years :-)). Of course it should also have separate control and data channels. (That's a mayor flaw of the "classical" terminal tech. The in-band transport of control is a big PITA, and can be even an security risk).
And if they don't, https://github.com/csdvrx/sixel-tmux will give you the best rendering it can do
“imgcat filename.jpg” for example will display the image in your shell/terminal.