3 ms·

> I always find this a bit sad, because it seems to take away the idea that programming is about assembling composable parts [OT] Concerning "programming is a

by pif 4y ago

> I always find this a bit sad, because it seems to take away the idea that programming is about assembling composable parts [OT] Concerning "programming is about assembling composable parts": I always find both sad and ridiculous when self-proclaimed software developers bash Unix because they are not able to appreciate its philosophy.

kaba0 4y ago
It would help Unix’s case if the glue between the parts wouldn’t be byte streams and some very crude int result code, signals, etc. A monolith can be just as composable if not more, with a much “stronger glue” in the form of language-mandated guarantees. Also, sometimes doing multiple things well is the better direction — IPC is additional complexity and essential complexity can’t be decomposed.
- TheDesolate0 4y ago
  In Unix space we use text, almost exclusively. This byte stream thing is a windows/java bs thing.
  - tga_d 4y ago
    When contributing to uutils (the coreutils written in Rust), one of the bigger pain points with cross platform support is the way that in Unix, everything, including arguments, is just bytes, while on Windows, arguments are semi-opaque text strings. E.g., the -t option in sort, join, etc. takes an arbitrary byte (other than null, which is supported via \0), so you can sort, join, etc. binary inputs. However, the -t option will not let you use a multi-byte character, even valid Unicode characters like é, which, if Unix actually used text for everything, you would expect it to. Meanwhile, on Windows, uutils still doesn't support non-ASCII byte values for -t, because Windows doesn't provide a way to represent those.
- bee_rider 4y ago
  Unix has gotten pretty far using just text and return codes. But there's no need to be dogmatic about it I guess, it could be nice to pass objects around, rather than text, like Powershell does. Although, their implementation seems quite verbose. I think to really use something like that, I'd want a well-defined ordering for the fields and the ability to also do something like variable.1 in addition to variable.someLongFieldName This could result in less than obvious scripts, but a shell language also needs to be compact, for interactive usage.

by pif 4y ago

kaba0 4y ago

It would help Unix’s case if the glue between the parts wouldn’t be byte streams and some very crude int result code, signals, etc. A monolith can be just as composable if not more, with a much “stronger glue” in the form of language-mandated guarantees. Also, sometimes doing multiple things well is the better direction — IPC is additional complexity and essential complexity can’t be decomposed.

TheDesolate0 4y ago
In Unix space we use text, almost exclusively. This byte stream thing is a windows/java bs thing.
- tga_d 4y ago
  When contributing to uutils (the coreutils written in Rust), one of the bigger pain points with cross platform support is the way that in Unix, everything, including arguments, is just bytes, while on Windows, arguments are semi-opaque text strings. E.g., the -t option in sort, join, etc. takes an arbitrary byte (other than null, which is supported via \0), so you can sort, join, etc. binary inputs. However, the -t option will not let you use a multi-byte character, even valid Unicode characters like é, which, if Unix actually used text for everything, you would expect it to. Meanwhile, on Windows, uutils still doesn't support non-ASCII byte values for -t, because Windows doesn't provide a way to represent those.
bee_rider 4y ago
Unix has gotten pretty far using just text and return codes. But there's no need to be dogmatic about it I guess, it could be nice to pass objects around, rather than text, like Powershell does. Although, their implementation seems quite verbose. I think to really use something like that, I'd want a well-defined ordering for the fields and the ability to also do something like variable.1 in addition to variable.someLongFieldName This could result in less than obvious scripts, but a shell language also needs to be compact, for interactive usage.