The indie game developer Jonathan Blow is currently trying his best to create a replacement for the C programming language with the intended use case of developing games (go figure). In general I think that replacing C/C++ is a good call; my personal belief being that undefined behavior [1] is a bigger problem than the college lectures let on. And honestly, replacing C/C++ seems to be en vogue these days [2].
Now Jonathan’s project is still a work in progress, but he’s racked up quite the impressive length of video digression into this subject [3]. If you watch through those videos, you’ll get the impression (and part of this comes from explicit statements) that the goal of this language is to be an 85% language. Fix the parts of C that are rather archaic, optimize for the use cases that game designers care about, avoid syntactic and semantics pitfalls that do not have any reason to exist and we can fix with zero cost, but don’t ground the thing in whatever crazy lambda calculus the cool kids are playing with this decade. After all we would like to be able to get some work done by Thursday without having to learn category theory in order to do it.
I think that the 85% goal is a pretty good one if you already know how you want to be programming. If your patterns stay the same and are always doing *basically* the same things, ensuring that weird edge cases fit into your system might actually be a waste of time. You can handle those issues with code reviews, stack traces, and debuggers.
However, on the other hand, my personality doesn’t get along with very well with 85% solutions. Economically, I see why they are absolutely necessary, and I wouldn’t hesitate to use an 85% solution as an implementation detail if my focus is on whatever the bigger picture is (assuming of course the 85% can be verified to fully satisfy the requirements). But if my goal and focus is to understand the thing (whatever it is), I’m going to lean towards 100% solutions nearly every time.
I think the reason for this is because my learning style seems to involve some sort of combination of counter example search and backtracking. Break everything apart into the smallest pieces you can and then try to put the pieces back together again. Anytime you think you have a semantic meta statement look for counter examples. If you find a counter example then something is wrong, so backtrack until you can’t find any counter examples. Once you can’t find any counter examples for anything you’re done. Not quite a proof of correctness, but success by exhausting all avenues of failure seems like it ought to work better than “but this worked last time”.
Here comes the punch line: I’ve already mused about mathematical properties being valuable for programming correctness [4]. And I think the reason for that is because the context of a property is 100% (and by the way we have proofs). You don’t have to worry about things going wrong tomorrow. I think the reason that we need to be replacing C/C++ today is that they were the 85% languages of yesterday. The programming techniques we’ve developed just don’t fit into languages that were developed in a very different environment. Maybe you want an 85% solution or programming language because you need to get work done today and you don’t want to worry about proofs of correctness. And maybe that’s going to work. On the other hand maybe someone will misuse your solution or new techniques will arrive that can’t be safely utilized in your language.
[2] - Microsoft is supposedly developing *something*, Apple has developed Swift, Mozilla is developing Rust, Facebook seems interested in D, Google has developed Go, the C++ standard is trying to modernize.
No comments:
Post a Comment