I think Jonathan Blow's main goal is to make his dream game programming language so that he can be happier while developing all of his future games. Widespread adoption by others is only a secondary concern. He also doesn't want to push it out to the general public until he feels it's ready, and wants to take the time to get it right first.
Jonathan Blow is a skilled craftsman with stuff like this and he knows he's going to get a bunch of Opinions About His Language from people who think they have a complete superset of his knowlege, and he is making his language without involving those people in any way.
That’s fair, but if you look at his posts about the language, he also makes a big point about how he doesn’t want any input from people with an academic background in language & type theory. This smells like anti-intellectualism to me.
I’m a bit concerned that some of the decisions that he’s making in the language are leading towards traps that have caught other language designers in the past, but because he’s rejecting that expertise, he has to learn from experience, at greater cost. These concerns are motivated by specific things I’ve seen in Jai code, but I don’t really want to dive into the specifics, since Jai is unavailable.
I think his disdain towards academia isn't really anti-intellectualism (he's not ignorant of compiler theory knowledge, otherwise he wouldn't have been able to write a compiler from scratch in the first place! And his interest in programming languages seems to span decades, from what I remember from one of his streams). I think he's critical of the fact that the primary focus of academia and industry in computer science have diverged so much over the years, such that most academic CS works haven't really helped developers in building better programs and tools. Thinking about the countless hours compiler academics have spent on all sorts of esoteric parser theory in the past, while all the production compilers today are using recursive decent for pragmatic reasons... maybe this kinda makes sense.
I’d have to say that academic research into programming languages has provided immense benefits for actual programmers over the years, it just has such a long lead time that people forget that the research came out of academia in the first place. People also don’t really understand the process of how these ideas come from academia into mainstream programming languages.
It only seems like academic research has diverged because the benefits of current research haven’t materialized as real, usable features in programming languages that people use to get work done. But if you look at features that we use in day-to-day programming right now, you can trace the heritage of these features back to research programming languages (like Self or Haskell) and then farther back to more abstract research into esoteric subjects like category theory and substructural logic.
The esoteric parsers that people invented in the past were, in a sense, necessary because people were ignorant of how to design languages in such a way that they could support a rich syntax without using a complicated parser. It took a lot of academic research for us to figure out that, say, you could probably use an LALR parser for lots of existing languages, and you could stick to LL(1) for new designs.
That's a fair point. Maybe researchers needed to delve into all sorts of weird parser theories, to later figure out that they weren't that needed. Practicioneers mainly know the final result, but aren't usually interested in the full history of how people got to that conclusion.
But I think during the recent decades, there has been a consensus that perverse incentives in academia are degrading research quality and preventing papers from becoming actually usable in real-life applications (mainly with the focus of paper metrics and the constant need to apply for grants). So although I think academia is still important long-term, I understand why some people would think it's becoming less useful.
Actually that's probably under-selling the problem. It's not just that Jon doesn't value the opinions of academics, he doesn't really value the opinions of anyone except Jonathan Blow.
Which is probably a healthy way to attack your first video game project, it's not as though Braid would be more likely to be a success if Blow stopped believing in it himself. But I would be surprised if that's true of a programming language.
> most academic CS works haven't really helped developers in building better programs and tools
It's doubtless possible to measure "most works" and "really helped" in ways which allow you to either draw this conclusion, or not, as you prefer but I don't think that's a useful way to think about it at all.
it isn't anti-intellectualism at all, it's that he gets asked questions by people in college as well as college grads continuously and the questions they ask are indicating that the things being taught in higher education are absolutely not the kinds of things that he sees in his day to day work.
to be fair to Jon, he works in a subset of software development that most do not: video games.
the kinds of problems that Jon sees do encompass the things that we all see, since he uses the same operating systems that we do, the same compilers, and just generally the software available to him is the same as what is available to all of us.
where the experience of a game developer really differs from that of, say, an enterprise software developer is the complexity of the problem being solved and the speed at which the problems in games must be solved. additionally, it is trivial to compare two games of the same genre and determine which looks better and which feels better. so, performance and quality are of prime importance to a game developer.
game performance and playability directly correlate to game sales in many cases, and game sales directly correlate to employment as a game developer. game developers want to create games specifically, so they want to continue working as game developers. so, they want to create successful games, so they want to create games that perform their best and that look their best so that more players purchase the game.
Enterprise and commercial software developers simply do not have the same types of pressure on them. It is perfectly fine for an enterprise software developer to use object oriented code which consumes 8 bytes of network capacity to transfer a single boolean value because the performance and latency of enterprise applications does not impact their use except in extreme circumstances.
game developers will redesign lots of their types to net a 2 byte savings on a data structure if that is what it takes to keep a full multiplayer game update in a single 1492-byte network packet and avoid packet fragmentation. game developers will spend 200 hours changing their data structures so that they fit more efficiently into CPU cache lines and they will change how game logic is processed so that they miss the CPU data cache as little as possible, because CPU cache efficiency directly relates to performance on almost all modern platforms. these are problems that simply do not exist within most enterprise's software development teams.
and because those are problems that do not exist for enterprises, those are problems whose nature and whose solutions are not taught at University.
Jon has been a game developer for almost his entire career, so he sees things differently than people on this website. people who work at startups and seek angel investment so they can scrape by long enough to deliver an MVP and be purchased have wildly different priorities than a game developer who wishes to succeed as a game developer.
in general I think the wider software development community could learn a great deal from game developers. the software written by developers who are not game developers is almost unilaterally unacceptably slow.
Most general purpose software developers simply do not have the experience to understand how egregiously bad most general purpose software is. Jon does. and his complaints regarding academia reflect the reality he sees.
I think I’ve never heard someone romanticize a profession as hard as what you’ve done here. This comment paints a truly distorted and unrealistic picture of game developers.
Game developers are not radically different from other developers. You see game developers leave the game industry and become programmers somewhere else, or you see programmers in another industry become programmers in the game industry. It is not a big deal.
While you could find some game developers who care about saving a couple bytes to fit something in a single network packet, you can equally find developers elsewhere who care about the same thing. Shave some time off your latency numbers and people stay on your website or app, they buy things or watch ads, your company gets money, you put it in your performance review. That’s just the most boring example I could think of. There are more interesting examples. Most programmers are simply not interested in saving a few bytes or a few cycles because they have features to work on. That includes game developers.
We fetishize low-level programming too much. Low-level programming is, in a sense, easy, because you are working with components that are simpler and have better documentation.
never in my 30-year career have I witnessed a single non-game developer give a damn about the latency or responsiveness of any application they've written.
never in my 30-year career have I witnessed a single game or emulator developer STOP caring about these things.
> I think I’ve never heard someone romanticize a profession as hard as what you’ve done here.
Go fuck yourself. it isn't me romanticizing, it's you thinking you know more than others by default, and outright dismissing the viewpoint of others. go away from me and stay away.
I work in telecoms, we do care a lot about latency, HFT guys are the same.
Some parts use FPGAs instead of normal hardware due to the low latency requirements!
OTOH I remember when one man doubled the framerate of a Nintendo game: apparently not all game developers care so much if they leave so much performance unused..
I had been a game developer for last 7 years and I disagree. Most game developers do not have that much expertise to start with, because it has been a long time that low-level optimization makes or breaks your game. They tend to lean to proven techniques to the point that they have consistent aches like your aging grandparents but still keep using them because complaints alone don't break their games. The ratio of game developers capable of optimizing things at that level is roughly same to (or possibly even lower than) the ratio of comparable non-game developers.
