Trevor Jim

You're missing high-level languages such as Modula-2 or Free Pascal that are safe-by-default while being close to the machine. They compile faster. They're easier to analyze. Someone who understands C could easily port it to one of these languages or even write a translator that converts them to C for easy integration of incrementally-rewritten pieces of the OS. They don't because they like C for non-technical reasons or want to do one piece of tooling work over another. Another you might find interesting in alternate history where C programmers adopt better tech is Cyclone that tried to stick to C as much as possible. Rust's safety scheme took a lot of inspiration from Cyclone. https://en.wikipedia.org/wiki/Cyclone_(programming_language) http://trevorjim.com/unfrozen-cyclone/ " There are excellent model checkers out there for C, and quite a few proof assistants are gaining the ability to check proofs on C code directly" I agree. Further, just using Design-by-Contract with property-based and fuzz testing on those contracts would improve things by itself. There was also an academic who applied Frama-C to one of their smallest, battle-tested components in I think a string library. Although no coding flaw found, the exercise did show the documentation was incorrect. Gotta wonder what benefit might happen for less obvious stuff than string operations.

Yes, that is exactly what's mentioned here, on the same site that I linked: http://trevorjim.com/python-is-not-context-free/ (Are you the author? :) ) Why does this matter? Because AFAICT the current best practice for implementing languages is to 1) prototype the language with a tool, then 2) throw that out and write the parser by hand. If you skip step 1, then it will be unclear what language you've defined (and it's not always obvious how to break up the procedures). If you skip step 2 and auto-generate your code instead, you typically don't have enough expressive power, and you have to hack around it (communication with globals, etc.) Tools and theory are focused excessively on CFGs (i.e. in this thread parsing with derivatives). Whereas real language always have non-context-free parts. Granted, Python is probably one of the most friendly and well-designed, and writing the lexer by hand and generating the parser works well there. I don't think that, in the case of Python, writing the parser by hand would have been a good idea.

"until recently"? More than 10 years just going by HN. https://news.ycombinator.com/item?id=5161214 I think HTML showed the problem with Postel's principle. Quoting "Postel’s Law is not for you" at http://trevorjim.com/postels-law-is-not-for-you/ from 2011 > The next version of HTML, HTML5, should considerably reduce the problem of browser incompatibilities. It does this, in part, by rejecting Postel’s Law for browser implementors. Instead of allowing browsers to be liberal when dealing with “flawed” markup, HTML5 requires them to parse it exactly as in the HTML5 specification, and that specification is given much more precisely than before, in the form of a deterministic state machine, in fact. HTML5 is trying to give implementors no leeway at all in this, in the name of browser compatibility.

Let's link to the actual article (the tweet is just a link): http://trevorjim.com/how-emacs-beat-vi-in-the-editor-wars/ https://news.ycombinator.com/item?id=24364437

> I think you should really be pushing more for SML or Haskell or something like that. There are two clues in this sentence (mentioning SML and not OCAML, "something like that") that suggest you do not regularly program in a "something like that" language. I wrote my first Haskell program over a decade ago. I find Haskell very hard to read. The grammar is very complicated[1] and is actually context-sensitive[2]. [1] https://www.haskell.org/onlinereport/haskell2010/haskellch10.html [2] http://trevorjim.com/haskell-is-not-context-free/

Perhaps "The Harmful Consequences of Postel's Maxim"?: https://news.ycombinator.com/item?id=9824638 If not, perhaps one of these: http://programmingisterrible.com/post/42215715657/postels-principle-is… https://bitworking.org/news/There_are_no_exceptions_to_Postel_s_Law_ http://trevorjim.com/postels-law-is-not-for-you/

The author of Cyclone seems to suggest that Rust is the current path forward: http://trevorjim.com/unfrozen-cyclone/ > Cyclone was an early attempt to create a programming language at the level of C, combining manual memory management with complete static memory safety. You can think of it as one step on the path that Rust and other languages have continued, one that I believe will eventually replace C, eliminating a host of severe security problems.

I would be worried about handling the not-context-free parts of the language: http://trevorjim.com/c-and-cplusplus-are-not-context-free/ How would you handle these?

A) Python is not context-free; this is a common misconception: http://trevorjim.com/python-is-not-context-free/ B) No one feature of a grammar provides context-freedom. It's not meaningful to compare Go's grammar to another grammar; it's meaningful to compare Go's grammar as-is to the way it would be if it allowed both forms. In this case, I believe the same-line braces rule is not strictly necessary by itself (they could have gotten a context-free grammar other ways), but this was (part of) one approach.

Unless he means that Rust should be used on projects where the Rust compiler is available for all relevant platforms and C and C++ can be used otherwise, I disagree. In fact, until LLVM is replaced, C++ will probably be the language of choice for new languages. Even `rustc` requires a C++ bootstrap for that purpose. There are also other important C++ and C libraries that will continue to mean C and C++ may be better choices than Rust in certain cases. And don't get me started on embedded. Also, that doesn't even matter when the purpose is a hobby project (such as mine) where the programmer has no interest in Rust (such as me). I like how Trevor Jim put it [1] better: > If you decide to write your project in C/C++ you must have a plan for handling the inevitable memory corruption in advance. Anything else is malpractice. This is possible to do. I've released a non-trivial program that has had no known memory bugs ever since 1.0 on 2018-10-26. It is written in C. And I challenge anyone to find one in any release since then. You might find one, but I think it will be tough. In other words, it's possible to put C and C++ on the same footing as Rust when it comes to memory bugs; after all, even Rust is not perfect there. Yes, it takes more effort. A lot more effort. For my hobby projects, that works fine because I'd rather work in C with the extra effort than in Rust. Oh, and it's possible to make C as good as Rust: I've got macros to do automatic bounds checking. I've…

The other big problem with Postel's law is that it makes enforcing security guarantees a nightmare. When each component in a system is "liberal in what it accepts", it's very easy to fall into a trap where component A thinks that component B is performing the security checks and component B thinks that component A is performing the check and as a result the security check is either never performed or trivially sidestepped. A good example of this was the vulnerability with null characters in SSL certificates [0]. In that vulnerability, both the browser and the certification authority interpreted the domain with the null character as "liberally" as possible, but their differing interpretations of what constituted "forgiving" made it trivial to spoof SSL certificates merely by including a null character in your domain. Another example is with guarding against XSS vulnerabilities. Browsers try to be liberal in what constitutes valid Javascript, and will attempt to execute even the most malformed scripts they encounter. This makes it unnecessarily difficult to shield against XSS - one must block a whole range of vectors, rather than just script tags. [0]: http://trevorjim.com/postels-law-and-network-security/

I mean, ps2pdf be with you (it ships with Ghostscript), or, if you must, use a Web service[1]. PostScript was fairly common for scientific articles before PDFLaTeX was written and Adobe still attempted to control PDF using their patents. That said, the System P₂ papers might be more helpful[2,3]. The System P paper[4] is indeed more about the inference algorithm and less about the motivation—perhaps the accompanying slides[5] will help some, alongside the first two papers? [1] https://www.ps2pdf.org/ [2] “What are principal typings and what are they good for?” (POPL ’96), https://dl.acm.org/doi/10.1145/237721.237728 [3] “Rank 2 type systems and recursive definitions” (MIT-LCS-TM-531), https://hdl.handle.net/1721.1/149246.2 [4] “A polar type system” (ITRS ’00), http://trevorjim.com/papers/polar.ps.gz or http://www.macs.hw.ac.uk/~jbw/itrs/itrs00/papers/Jim:ITRS-2000.ps.gz or https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi… [5] http://www.macs.hw.ac.uk/~jbw/itrs/itrs00/slides/Jim:ITRS-2000:slides.…