The illusion of apparent simplicity [LWN.net]

The illusion of apparent simplicity

Posted May 2, 2022 16:36 UTC (Mon) by kleptog (subscriber, #1183)
In reply to: The illusion of apparent simplicity by ddevault
Parent article: DeVault: Announcing the Hare programming language

I think the point was slightly different: when solving a problem that problem comes with a certain amount of complexity and that complexity is irreducible if you still want to solve them problem.

If you're writing an HTML parser, a YAML parser, a TLS library, an X.509 parser, the program will contain a certain amount of complexity which cannot be removed while still actually solving the problem. So the question is really: does a programming language allow you to express this complexity without requiring lots of additional overhead complexity.

Writing a YAML parser in Assembler is clearly insane, for example. Processing text files with Awk works really well because that's what it was designed for.

In this day and age, *no-one* should be out there writing their own X.509 parser or TLS library unless you really have a brand new use case that is core to your program. Just import a library and get on with your life. Now, a leftpad library is obviously overboard, but importing libraries to handle complexity that you don't want to deal with yourself is a good thing and shouldn't be discouraged.

to post comments

The illusion of apparent simplicity

Posted May 2, 2022 16:48 UTC (Mon) by ddevault (subscriber, #99589) [Link]

> If you're writing an HTML parser, a YAML parser, a TLS library, an X.509 parser, the program will contain a certain amount of complexity which cannot be removed while still actually solving the problem. So the question is really: does a programming language allow you to express this complexity without requiring lots of additional overhead complexity.

I actually agree with this take. And we do intend to implement all of these things, actually, except perhaps YAML, which is a den of snakes (so is X.509, but one we unfortunately cannot avoid). However, I don't think these use-cases call for much re-usable logic beyond what Hare already offers, unless someone seeks to implement a parse-them-all abstraction, which I would consider highly misguided. The level of complexity of such implementations in Hare will, I think, map relatively closely onto the minimum required level of complexity. We aim to provide exactly the right number of primitives to support robust implementations, and no more.

Hare does provide several features to help with this sort of thing, by the way. For example, quoting the author of Monocypher on Hare's use of slices for cryptography:

> I like that (apparently) slices are used for the API. Having written a cryptographic library in C, I saw how we are reading from and writing to buffers all the time, and having to specify their length explicitly means my functions have many more arguments than I would have liked.

Other primitives in the stdlib also encourage good/robust design, such as bufio, and things like mandatory error handling ensure you never accidentally forget to verify that some authenc data was actually authenticated.