3 ms·

One of the trends of newer programming languages that I'm a big fan of is to pair good error messages with strict validation (see e.g. Elm or Rust) rather than

One of the trends of newer programming languages that I'm a big fan of is to pair good error messages with strict validation (see e.g. Elm or Rust) rather than to try to have very lax input (in this case code) and make it work (e.g. older versions of PHP or JS). While there are specific cases where lax validation or extensible validation is the right way to go, I agree with the IETF here that that lax/extensible validation is a poor default and strict (+ good error messages!) is a better default. It is always easier, whether purely from an implementation perspective or from a wider ecosystem perspective, to take strict validation and make it laxer.

kazinator 5y ago
This might also go hand in hand with newer programming languages being (1) free and (2) single-implementation unique languages. When you have a multiply implemented language there is an incentive to support nonconforming programs, in order to fool naive programmers and their pointy haired bosses that a given language implementation is superior. And also to lock users to that implementation. There is existing code out there creating a kind of competitive scene: which implementation will most of that get built with. The browser wars were an example of this. Rendering broken HTML was a feature; it looked like your browser was better than another one which "broke" on the incorrect web page. Microsoft tried to co-opt Java with something called Visual J++, pissing off Sun Microsystems badly enough to provoke a lawsuit.
schoen 5y ago
> I agree with the IETF here Note that the status of this document is an (expired) Internet-Draft -- it is a proposed RFC that has not been adopted, so it doesn't necessarily reflect an IETF consensus. I mention this because I'm the author of some somewhat controversial Internet-Drafts that some people thought had already been adopted because they were hosted on ietf.org and were written in the style of an RFC. It's worth remembering that anyone can write a proposed RFC and it will be hosted on ietf.org in order to facilitate discussion. IETF documents should indicate their status at the top, as well as having more details about their history available in the IETF datatracker, so we can see what kind of consensus each document has or has not achieved so far.

kazinator 5y ago

This might also go hand in hand with newer programming languages being (1) free and (2) single-implementation unique languages. When you have a multiply implemented language there is an incentive to support nonconforming programs, in order to fool naive programmers and their pointy haired bosses that a given language implementation is superior. And also to lock users to that implementation. There is existing code out there creating a kind of competitive scene: which implementation will most of that get built with. The browser wars were an example of this. Rendering broken HTML was a feature; it looked like your browser was better than another one which "broke" on the incorrect web page. Microsoft tried to co-opt Java with something called Visual J++, pissing off Sun Microsystems badly enough to provoke a lawsuit.

schoen 5y ago

> I agree with the IETF here Note that the status of this document is an (expired) Internet-Draft -- it is a proposed RFC that has not been adopted, so it doesn't necessarily reflect an IETF consensus. I mention this because I'm the author of some somewhat controversial Internet-Drafts that some people thought had already been adopted because they were hosted on ietf.org and were written in the style of an RFC. It's worth remembering that anyone can write a proposed RFC and it will be hosted on ietf.org in order to facilitate discussion. IETF documents should indicate their status at the top, as well as having more details about their history available in the IETF datatracker, so we can see what kind of consensus each document has or has not achieved so far.