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.
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.
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.
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.
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 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.
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..
It isn't a contest you know..