4 ms·

I think the browser is the described OS here: every-api passes objects around, IndexDB is your filesystem, remote REST & GraphQL servers are returning structure

I think the browser is the described OS here: every-api passes objects around, IndexDB is your filesystem, remote REST & GraphQL servers are returning structured JSON objects to your program, you can add a <script> tag to your <html> to pull in your single-function scripts (i.e. leftpad). Seriously though, the question of "why isn't it done this way" is answered a couple times: "it's all just bytes in the end". Bytes & arrays-of-bytes are really the only thing that you can trust that all systems and all languages interpret the same (even 2-byte integers can be interpreted differently by different systems). Presumably the author just wants to be able to memcpy structures between programs or from disk, or maybe with some high efficiency pre-allocated heap stuff, but you really need to have code to validate the bytes, essentially requiring the parsing of your data-structure which the author is trying to avoid. Running programs with some common argument notation does sound really nice, but ideally that's just calling a function from your language's binding to their library (as their executable should do, right?).

bmn__ 7y ago
> remote REST & GraphQL servers are returning structured JSON objects to your program They are not. They are sending a HTTP message, which consists of just octets and has to be parsed. The parsers have to have a ridiculous complexity for various reasons. The HTTP header contains sublanguages such as RFC 7231 §5.3.1 or RFC 8288 §3. JSON meanwhile has amassed at least six incompatible specifications with the same exact media type, so there is not even a theoretic hope of parsing all messages correctly. https://news.ycombinator.com/item?id=20736665 https://news.ycombinator.com/item?id=20736665
- squiggleblaz 7y ago
  Wow that statement is completely untrue. It links to several RFCs. RFC-7158 and RFC-7159 differ only in (a) that one is RFC-7158 and the other is RFC-7159 (b) that one is dated in March 2013 and the other is March 2014 (c) that one obsoletes RFC-7158 in addition to RFC-4627 which they both obsolete. It appears that 7159 was pushed only to handle an error in the dating of 7158, given that the irrelevant RFC-7157 is dated March 2014. So to say that there's more that five incompatible specs is just a cruel disregard of the facts. No implementation can differ in its parsing of a text based on the metadata of the spec. There needs to be a substantive difference in the spec. As to the current RFC 8259, it makes no substantial differences from the previous version. There are a few typos that have been fixed ("though" becoming "through", when "though" was not a possible interpretation). It eliminates the obligation to parse public texts not coded in UTF-8. Previously, documents SHALL be UTF-8 - that's barely a change, but it is a change. It has specified more concretely its relationship with ECMA-404. It's possible that someone reading earlier RFCs would have concluded "a valid RFC 7159 json parser can parse and only the documents produced by ECMA-404". If there were any discrepancies between ECMA-404 and RFC-7159, therefore, an interpretation along these lines would lead a person to conclude you cannot parse a document according to RFC-7159, so the spec doesn't really count as an incompatible spec. Under the current spec, it identifies that there are possible discrepancies, and RFC-8259 is intended to accept fewer documents that ECMA-404. The first RFC did not permit the json documents "true", "false" and "null", accepting only json documents that comprise an object or an array. It permitted any Unicode encoding, defaulting to UTF-8, and non-Unicode encodings as well (so a Latin-1 document is valid RFC-4627, but not valid RFC-7158+). It also included some incorrect statements about its relationship to javascript. These were reduced in later versions and eventually eliminated. They do not affect the specification of the language, but merely how you may handle data in the language. No document that is accepted by the current RFC will be rejected by any RFC other than the first. The only such documents to be rejected by the first are those which consist entirely of "true", "false", or "null". No UTF-8 document that is accepted by the first RFC will be rejected by subsequent RFC parsers, unless a person reads a paragraph called "security considerations" that says "you can kinda do this but it's insecure" as somehow trumping the clear statements of the grammar in earlier sections. I have not investigated the other specs and I probably won't. But the idea that there are 6 incompatible specs is false. There is not more than 5, and it is almost trivial to accept documents according to 3 of 5 or 4 of 6 specs at once by ignoring the restrictions on character coding.
  - pdimitar 7y ago
    > It links to several RFCs. RFC-7158 and RFC-7159 differ only in (a) that one is RFC-7158 and the other is RFC-7159 (b) that one is dated in March 2013 and the other is March 2014 (c) that one obsoletes RFC-7158 in addition to RFC-4627 which they both obsolete. It appears that 7159 was pushed only to handle an error in the dating of 7158, given that the irrelevant RFC-7157 is dated March 2014. "they only differ in", yeah, indeed. Dude. We all have work to do and grappling with some obscure JSON parsing corner is the last thing we need in our workday. This applies to 95% of commercial programmers, I am willing to bet. What you described does sound simple and small in isolation. Now multiply it by 50 and see how "they only differ in" is a problem that must not be allowed in the first place. Where's the-one-and-only JSON spec? Why no organisation has the courage to step forward and standardise it once and for all? Given the current realities, just cut your very small and ignorable losses by losing those obscure JSON parsing corners and let people describe JSON simply as: "RFC #ABCD". That's it. Nothing else. Only that. Everything is contained in it. Complexity compounds and makes everything non-deterministic. We should stop allowing that.
- akubera 7y ago
  Yes but that's the underlying system, not your "application code" handling the structure parsing. Maybe I shouldn't have said JSON, but you do always get a JavaScript object back, as opposed to UNIX filesystem/socket operations which only really return application/x-octet-stream data. I thought that was the thesis of the article: it'd be a better world if your operating system supported parsing common structures for you.
Bystroushaak 7y ago
> I think the browser is the described OS here I was actually describing something more close to the Smalltalk (http://pharo.org http://pharo.org) / Self (http://blog.rfox.eu/en/Series_about_Self.html http://blog.rfox.eu/en/Series_about_Self.html) image.

bmn__ 7y ago

> remote REST & GraphQL servers are returning structured JSON objects to your program They are not. They are sending a HTTP message, which consists of just octets and has to be parsed. The parsers have to have a ridiculous complexity for various reasons. The HTTP header contains sublanguages such as RFC 7231 §5.3.1 or RFC 8288 §3. JSON meanwhile has amassed at least six incompatible specifications with the same exact media type, so there is not even a theoretic hope of parsing all messages correctly. https://news.ycombinator.com/item?id=20736665 https://news.ycombinator.com/item?id=20736665

squiggleblaz 7y ago
Wow that statement is completely untrue. It links to several RFCs. RFC-7158 and RFC-7159 differ only in (a) that one is RFC-7158 and the other is RFC-7159 (b) that one is dated in March 2013 and the other is March 2014 (c) that one obsoletes RFC-7158 in addition to RFC-4627 which they both obsolete. It appears that 7159 was pushed only to handle an error in the dating of 7158, given that the irrelevant RFC-7157 is dated March 2014. So to say that there's more that five incompatible specs is just a cruel disregard of the facts. No implementation can differ in its parsing of a text based on the metadata of the spec. There needs to be a substantive difference in the spec. As to the current RFC 8259, it makes no substantial differences from the previous version. There are a few typos that have been fixed ("though" becoming "through", when "though" was not a possible interpretation). It eliminates the obligation to parse public texts not coded in UTF-8. Previously, documents SHALL be UTF-8 - that's barely a change, but it is a change. It has specified more concretely its relationship with ECMA-404. It's possible that someone reading earlier RFCs would have concluded "a valid RFC 7159 json parser can parse and only the documents produced by ECMA-404". If there were any discrepancies between ECMA-404 and RFC-7159, therefore, an interpretation along these lines would lead a person to conclude you cannot parse a document according to RFC-7159, so the spec doesn't really count as an incompatible spec. Under the current spec, it identifies that there are possible discrepancies, and RFC-8259 is intended to accept fewer documents that ECMA-404. The first RFC did not permit the json documents "true", "false" and "null", accepting only json documents that comprise an object or an array. It permitted any Unicode encoding, defaulting to UTF-8, and non-Unicode encodings as well (so a Latin-1 document is valid RFC-4627, but not valid RFC-7158+). It also included some incorrect statements about its relationship to javascript. These were reduced in later versions and eventually eliminated. They do not affect the specification of the language, but merely how you may handle data in the language. No document that is accepted by the current RFC will be rejected by any RFC other than the first. The only such documents to be rejected by the first are those which consist entirely of "true", "false", or "null". No UTF-8 document that is accepted by the first RFC will be rejected by subsequent RFC parsers, unless a person reads a paragraph called "security considerations" that says "you can kinda do this but it's insecure" as somehow trumping the clear statements of the grammar in earlier sections. I have not investigated the other specs and I probably won't. But the idea that there are 6 incompatible specs is false. There is not more than 5, and it is almost trivial to accept documents according to 3 of 5 or 4 of 6 specs at once by ignoring the restrictions on character coding.
- pdimitar 7y ago
  > It links to several RFCs. RFC-7158 and RFC-7159 differ only in (a) that one is RFC-7158 and the other is RFC-7159 (b) that one is dated in March 2013 and the other is March 2014 (c) that one obsoletes RFC-7158 in addition to RFC-4627 which they both obsolete. It appears that 7159 was pushed only to handle an error in the dating of 7158, given that the irrelevant RFC-7157 is dated March 2014. "they only differ in", yeah, indeed. Dude. We all have work to do and grappling with some obscure JSON parsing corner is the last thing we need in our workday. This applies to 95% of commercial programmers, I am willing to bet. What you described does sound simple and small in isolation. Now multiply it by 50 and see how "they only differ in" is a problem that must not be allowed in the first place. Where's the-one-and-only JSON spec? Why no organisation has the courage to step forward and standardise it once and for all? Given the current realities, just cut your very small and ignorable losses by losing those obscure JSON parsing corners and let people describe JSON simply as: "RFC #ABCD". That's it. Nothing else. Only that. Everything is contained in it. Complexity compounds and makes everything non-deterministic. We should stop allowing that.
akubera 7y ago
Yes but that's the underlying system, not your "application code" handling the structure parsing. Maybe I shouldn't have said JSON, but you do always get a JavaScript object back, as opposed to UNIX filesystem/socket operations which only really return application/x-octet-stream data. I thought that was the thesis of the article: it'd be a better world if your operating system supported parsing common structures for you.

Bystroushaak 7y ago

> I think the browser is the described OS here I was actually describing something more close to the Smalltalk (http://pharo.org http://pharo.org) / Self (http://blog.rfox.eu/en/Series_about_Self.html http://blog.rfox.eu/en/Series_about_Self.html) image.