 |
| 2 users recommended this comment. What they said: |
|
LukeShu Jan 8, 2019 | on: Bash 5.0 released | context
That was kind of the idea of Unix. C was just a nicer from Assembly. You might write a performance-sensitive or low-level routine in C, much like you might drop to C when writing a Python library. But the high-level language of the system was the shell. The `dc` executable wasn't just meant to be a user-facing calculator program, it was also meant to be the system's "bignum" library. That was big-picture Unix. The syscalls and C were little-picture Unix. This 2013 thread shaped a lot of the way I think about Unix: https://news.ycombinator.com/item?id=6530180 |
|
nothrabannosir Oct 22, 2019 | on: Node.js 13.0 | context
How far we have strayed from the days where Unix tools were meant to be used as a stdlib, called through stdin and out. It makes me a little sad. Classic HN comment on this topic: https://news.ycombinator.com/item?id=6530180 |
| Also recommended by people who recommended this: | ||
| 1. | "PSD is not my favorite file format" (code.google.com) | |
| recommended by 3 users | 2009 | 131 points by iamelgringo | original thread | | ||
The fact that dc was originally intended as basically the Unix system's bignums library http://www.catb.org/esr/writings/taoup/html/ch08s02.html#id2... helped to open my eyes to this. I think you could talk about this idea of Unix as "big Unix" and the narrower understanding of Unix programming, dominated by the C APIs, as "little Unix".
Little Unix took over the world, while big Unix collapsed under its own weight due to things like portability/versioning hell, robustness problems due to faulty tools and text-parsing errors, performance issues and so on. (Partly this was a success catastrophe, of course, for example in how the popularity of Unix resulted in a profusion of different Unix userlands with varying interfaces and bugs.) Also little Unix was more comprehensible from, and more portable to and from, the world of PC (MS-DOS/Windows/Mac) application development, where the environment is more or less the kernel's/OS vendor's APIs. The fact that clearly many more people have bought or read K&R http://www.amazon.com/dp/0131103628/ (with its very little-Unix perspective) than /The Unix Programming Environment/ http://www.amazon.com/dp/013937681X reflects this divergence, and also surely helped to create it.