UnixFiles

Context : Unix, TextPeople, CommandLine, TheUnixPipe, OperatingSystem

Another round of arguing about text vs. non-text representations.

I had this insight.

Embedding failed with embed type :twitter

and data
{:type :twitter, :url "https://twitter.com/interstar/status/1451706307673837589", :title "", :caption "\n\n@msimoni @chaturshalabh Yeah. Another way of looking at this is that Unix by taking line-breaks seriously, puts a 'sequence' API in front of all text. So when I say I like text, I also mean that I like this standard sequence API to which you can apply all the usual map, filter, fold etc operations.\n\n@msimoni @chaturshalabh At the same time, text as a sequence of characters affords parsing/pattern matching/regex APIs. Again, when I think of text, I think of having these at my disposal.\n\nMaybe if the OS is built on something different but offers consistent parsing and sequence APIs to everything ...\n\n@msimoni @chaturshalabh Then I'd find that an acceptable substitute.\n\nWhen I contemplate textlessness, I imagine that in practice would be some impoverished ad-hoc API to the objects that isn't as expressive as parsing and sequence processing.\n\n@msimoni @chaturshalabh The worst-case scenario is an OO system (even SmallTalk) where every object provides its own ad-hoc inconsistent API to its contents rather than there being a single standard API.\n\nBut even an 'everything is a table/query' API isn't as expressive as everything is seqs & parsables\n\n\n"}
java.lang.Exception: JSON error (unexpected character): <