Earlier quoted context omitted.
My CS degree did something like that, both for programming languages and OSes. I eventually got very surprised that not all universities do that.
Where was that, if I may ask?
In Portugal early 90's, FCT/UNL.
The Collapse of the Unix Philosophy
411–420 of 616 posts
Re: The Collapse of the Unix Philosophy
#412Earlier quoted context omitted.
XML, YAML, JSON and s-expressions are all just flavours of representing trees . So yeah, any of that would be a much better idea than unstructured text, and yes, you can serialize all those use cases into trees. I'd steer away from XML for sake of efficiency and human-readability though.
Not everything is a tree, and neither XML nor JSON nor sexp are particularly efficient or "beautiful". And there is no canonic representation. You could strip all whitespace or indent all childs, but... And YAML for example has no nice way to put lists of single words on one line.
I'm yet to see a practical data set that could not be encoded as a tree. Maybe if you have a cyclical data structure and you want to save that directly, but then it's a simple meta-level extension. For example, Lisp reader does that when reading S-expressions. If you want to create a list like this:
1 ---> 2 ---> 3-|
^_______________|
Re: The Collapse of the Unix Philosophy
#413Earlier quoted context omitted.
Ruling out "bad" characters is bound to affect internationalization negatively. IMO the best approach would be to separate between file name and the file object. When I edit a file with vim, should vim really need to know the name of the file? No. Likewise for a lot of other utilities as well. If instead of being so focused on file names and paths everywhere and we operated instead mainly on inodes then I think much…
"Bad" characters in this context is control characters. So no, it would not affect internationalization at all.
I missed the portion where that was said. I read through all of the comments about this and replied to the last one thinking we were still talking about things like spaces and newlines. My comment would have been better placed as a reply elsewhere. Sorry about that.
Still though, even if we only block some control characters, doing so could lead to problems with future character encodings.
Personally I hope UTF-8 / UTF-16 / UTF-32 is the final set of character encodings but we can't know that it will be.
Re: The Collapse of the Unix Philosophy
#414Earlier quoted context omitted.
Ruling out "bad" characters is bound to affect internationalization negatively. IMO the best approach would be to separate between file name and the file object. When I edit a file with vim, should vim really need to know the name of the file? No. Likewise for a lot of other utilities as well. If instead of being so focused on file names and paths everywhere and we operated instead mainly on inodes then I think much…
"Bad" characters in this context is control characters. So no, it would not affect internationalization at all.
[deleted]
Re: The Collapse of the Unix Philosophy
#415Re: The Collapse of the Unix Philosophy
#416Earlier quoted context omitted.
It's not converting to "one single format", it's converting to "any and all possible formats", because with unstructured text, you're literally throwing away the structure and semantics inherent in the data, instead relying on users to glue things together with ad-hoc parsers.
Please stop spreading bs. It's not throwing away structure. Piping text doesn't even preclude sexps. It's just that they are seldom needed. Simpler encodings like space-separated are sufficient for many use cases, and better for interoperation. It's misguided and inefficient to encode everything in the same way. Would you prefer to have your JPG or MP4 encoded in sexps? And I say that as someone who is working on a s…
Piping isn't the culprit. It's what you pipe that is, and Unix Philosophy says "pipe whatever the hell you want, and let the users upstream sort it out".
It's not about encoding everything in exactly the same way. It's about providing the basic, shared protocol for representing structure. With typical Unix tools, you don't have "simpler encodings", you have no encoding at all. Each tool outputs whatever its particular author felt like (and this changes between Unix systems), each tool parses things in whatever way its author felt like, and as a user your job is to keep transforming unstructured blobs of text to glue them together.
Re: The Collapse of the Unix Philosophy
#417Earlier quoted context omitted.
> It always amazed me when someone looks at computer systems of the 70's through the lens of "today's" technology and then projects a failure of imagination on the part of those engineers back in the 70's True enough, but as a younger programmer, I find it pretty reasonable to look back at computer systems of the 70s and wonder if we can do better today . I feel a little bit gross every time I have to write a bash sh…
JSON doesn't have comments so it's a bad choice for human-editable config. YAML doesn't have an end marker so you can never be sure if you've got the entire file. XML is a huge pain to edit by hand if the schema is complicated, and overly verbose if it isn't. None of them are even close to being safe (for example https://arp242.net/weblog/yaml_probably_not_so_great_after_a... ). All of those choices fail your "elegan…
StrictYAML - https://github.com/crdoconnor/strictyaml
Re: The Collapse of the Unix Philosophy
#418He lost me right at the beginning, with "I guess there wasn’t even Microsoft DOS at the time (I guess and I don’t bother to check, so check it yourself).". This is the OS equivalent of a Call of Duty teenage online player on XBox live.
Well it's a true statement, even if made in an irascible way. If you're going to insult the guy, at least wait until he makes a false statement.
Wasn't intended as an insult. Just a statement as to where he lost me and why. The tone of the post was so arrogant it might have carried over to my comment.
Re: The Collapse of the Unix Philosophy
#419Earlier quoted context omitted.
JSON doesn't have comments so it's a bad choice for human-editable config. YAML doesn't have an end marker so you can never be sure if you've got the entire file. XML is a huge pain to edit by hand if the schema is complicated, and overly verbose if it isn't. None of them are even close to being safe (for example https://arp242.net/weblog/yaml_probably_not_so_great_after_a... ). All of those choices fail your "elegan…
StrictYAML - https://github.com/crdoconnor/strictyaml
Still does not allow tabs for indentation - same problem as `make` but inverted
Re: The Collapse of the Unix Philosophy
#420Earlier quoted context omitted.
> It always amazed me when someone looks at computer systems of the 70's through the lens of "today's" technology and then projects a failure of imagination on the part of those engineers back in the 70's True enough, but as a younger programmer, I find it pretty reasonable to look back at computer systems of the 70s and wonder if we can do better today . I feel a little bit gross every time I have to write a bash sh…
JSON doesn't have comments so it's a bad choice for human-editable config. YAML doesn't have an end marker so you can never be sure if you've got the entire file. XML is a huge pain to edit by hand if the schema is complicated, and overly verbose if it isn't. None of them are even close to being safe (for example https://arp242.net/weblog/yaml_probably_not_so_great_after_a... ). All of those choices fail your "elegan…
I will capitalize on this derailment to promote luxem, my flexible and minimal JSON alternative: https://github.com/rendaw/luxem#what-is-luxem