5 ms·

> Unix is polyglot by design; that's a feature and not a bug. No it is not. Unix was always built around C with other languages as an afterthought, even late

by sedachv 10y ago

> Unix is polyglot by design; that's a feature and not a bug. No it is not. Unix was always built around C with other languages as an afterthought, even late in its development. Here are some quotes from my copy of the UNIX time-sharing system: UNIX Programmer's Manual revised edition from 1983: "System calls are entries into the UNIX supervisor. Every system call has one or more C language interfaces..." "An assortment of subroutines is available... The functions are described in terms of C, but most will work with Fortran as well." "The three principal languages in UNIX are provided by the C compiler cc(1), the Fortran compiler f77(1), and the assembler as(1)." Saying that Unix is a "polyglot" operating system makes as little sense as saying that Symbolics machines were "polyglot." Symbolics had better C and Fortran development environments than Unix but it does not change the fact that it was a Lisp machine. Unix is a time-sharing system with a C standard library, C memory management conventions, C calling conventions, C stack layout, C process memory layout, C linking and loading. Working against any of these conventions is possible but very awkward.

chubot 10y ago
Yes, you're right that C is special in Unix. There's a bias toward writing applications in C because the system interface is provided as C headers, and the ABI is architecture-dependent. But C turned out to be a great language for writing programming languages as well as kernels. The JVM is written in C, Python/Perl/Ruby/v8 etc. are written in C or C++. So in practice you do get an ecosystem with multiple languages. It's certainly nicer to write languages in C than in assembly. Treating everything as byte streams is another big reason that it is polyglot. This has obvious downsides, but if you stored everything as s-expressions, or C structs, then it would privilege one language over another. Traditional Unix utilities don't use architecture-dependent binary formats, and this is one of the main reasons why. But honestly, the only other solution would have been to define an RPC-like architecture-independent interface -- what operating systems do that? I don't know of any.
- sedachv 10y ago
  > The JVM is written in C, Python/Perl/Ruby/v8 etc. are written in C or C++. This is disingenuous - that's exactly like saying that ZetaC on the Lisp Machine was written in Lisp and not in microcode, so Symbolics is a polyglot machine. The reason that a lot of dynamic programming language runtimes (like the JVM, SBCL, etc) use C is exactly because the only alternative on Unix is to hand-code system calls in assembly. The code generators are almost always self-hosting in these languages. > It's certainly nicer to write languages in C than in assembly. C is a bad language to target compilers and transpilers to if you need non-standard control flow because it forces you into a stack discipline. Doing things like continuations or restartable exceptions requires Rube Goldberg machine-level workarounds. > Treating everything as byte streams is another big reason that it is polyglot. This has obvious downsides, but if you stored everything as s-expressions, or C structs, then it would privilege one language over another. Traditional Unix utilities don't use architecture-dependent binary formats, and this is one of the main reasons why. Even the idea of byte streams is a C-ism. Bytes on the PDP-10 would "naturally" come out to 6 bits (out of a 36-bit word) - the instruction set was based around flexible bit fields. > But honestly, the only other solution would have been to define an RPC-like architecture-independent interface -- what operating systems do that? I don't know of any. That sounds like a microkernel. But I think the real takeaway here is that any operating system is going to come with baggage for language implementors, and it is important to recognize and make explicit what these assumptions are and why they were made (like for example I don't think many people ever think about the non-8-bit-bytes thing, but it is important if you want to provide a nice interface for bit-banging: http://clhs.lisp.se/Body/f_ldb.htm#ldb http://clhs.lisp.se/Body/f_ldb.htm#ldb)
kazinator 10y ago
C doesn't have calling conventions; those are dictated by ABI's. A Pascal compiler can easily use the same ABI as a C compiler. The layout of a process doesn't really do anything that helps C. The C-specific considerations creep into API's when clients are required to prepare, or to parse, memory described as a C structure. C helps here by dictating that the members of a struct may not be reordered. The rules that compilers use for aligning structure members tend to be very similar and straightforward.

by sedachv 10y ago

chubot 10y ago

Yes, you're right that C is special in Unix. There's a bias toward writing applications in C because the system interface is provided as C headers, and the ABI is architecture-dependent. But C turned out to be a great language for writing programming languages as well as kernels. The JVM is written in C, Python/Perl/Ruby/v8 etc. are written in C or C++. So in practice you do get an ecosystem with multiple languages. It's certainly nicer to write languages in C than in assembly. Treating everything as byte streams is another big reason that it is polyglot. This has obvious downsides, but if you stored everything as s-expressions, or C structs, then it would privilege one language over another. Traditional Unix utilities don't use architecture-dependent binary formats, and this is one of the main reasons why. But honestly, the only other solution would have been to define an RPC-like architecture-independent interface -- what operating systems do that? I don't know of any.

sedachv 10y ago
> The JVM is written in C, Python/Perl/Ruby/v8 etc. are written in C or C++. This is disingenuous - that's exactly like saying that ZetaC on the Lisp Machine was written in Lisp and not in microcode, so Symbolics is a polyglot machine. The reason that a lot of dynamic programming language runtimes (like the JVM, SBCL, etc) use C is exactly because the only alternative on Unix is to hand-code system calls in assembly. The code generators are almost always self-hosting in these languages. > It's certainly nicer to write languages in C than in assembly. C is a bad language to target compilers and transpilers to if you need non-standard control flow because it forces you into a stack discipline. Doing things like continuations or restartable exceptions requires Rube Goldberg machine-level workarounds. > Treating everything as byte streams is another big reason that it is polyglot. This has obvious downsides, but if you stored everything as s-expressions, or C structs, then it would privilege one language over another. Traditional Unix utilities don't use architecture-dependent binary formats, and this is one of the main reasons why. Even the idea of byte streams is a C-ism. Bytes on the PDP-10 would "naturally" come out to 6 bits (out of a 36-bit word) - the instruction set was based around flexible bit fields. > But honestly, the only other solution would have been to define an RPC-like architecture-independent interface -- what operating systems do that? I don't know of any. That sounds like a microkernel. But I think the real takeaway here is that any operating system is going to come with baggage for language implementors, and it is important to recognize and make explicit what these assumptions are and why they were made (like for example I don't think many people ever think about the non-8-bit-bytes thing, but it is important if you want to provide a nice interface for bit-banging: http://clhs.lisp.se/Body/f_ldb.htm#ldb http://clhs.lisp.se/Body/f_ldb.htm#ldb)

kazinator 10y ago

C doesn't have calling conventions; those are dictated by ABI's. A Pascal compiler can easily use the same ABI as a C compiler. The layout of a process doesn't really do anything that helps C. The C-specific considerations creep into API's when clients are required to prepare, or to parse, memory described as a C structure. C helps here by dictating that the members of a struct may not be reordered. The rules that compilers use for aligning structure members tend to be very similar and straightforward.