Japan’s ’golden coder’ making games apps aged 82 [video]

Japanese hiring and benefits laws are extremely aggressive, which makes hiring someone of any age a very risky proposition. There was a good article posted here maybe a couple years back that had a great overview of the legal incentives leading to Japan's unfortunate soul-crushing sarariman system; I wish I could remember the title...

>>a lot of them have refused to adapt to modern languages/approaches/IDEs

There are plenty of young people like that too.

Old is subjective (when it was created or last updated), and even when old in all respects, it's not universally bad. Many would consider linux/unix, command-line interfaces, vim, emacs, common lisp, haskell, lisp machines, etc. to be old/useless, because they lack pretty graphics, support for the newest hardware, or is simply not windows nor mac.

But these old technologies have positive traits that are lost and sometimes recovered in the newer technologies. Examples of when older technology was recovered could be the introduction of lambdas and higher order functions into mainstream languages like c++ and python; that's something that "older" languages like lisp and haskell have had since their inception. I'm also to understand that Windows servers needed a graphical interface because not everything was doable from command line interface, and so setup had to be done manually instead of just making a script containing what you'd otherwise would've typed through a CLI. Now, they've improved the situation by making a CLI in the form of Powershell and making more of the system available through it.

As for other advantages of older tech that are not mainstream in "newer" tools, there is for example the fact that lisp machines are completely coded in lisp. Mind you, I haven't used a lisp machine myself, but I'm to understand that they have the ability to modify any part of anything running on the computer at any time even while the program is running, with minimum "build" time. I've experienced this on emacs, but on a lisp machine it's everything. Right now, I'm experiencing a bug on Firefox where some checkboxes and radioboxes are not rendered; this happens even with all add-ons uninstalled. If I wanted investigate this further, I'd have to download the firefox source, and read it in whatever multiple languages it's written in (as opposed to just lisp). Let's imagine I find the bug and fix it. I'd have to build the whole of firefox, not just the pieces I've changed. mozilla.org tells me I'd need "2G RAM with lots of available swap space" and, I imagine, lots of time. On a lisp machine, I'd just need to rebuild the functions I've changed.

Emacs also has support for live coding in multiple languages through addons like slime for common lisp, cider for clojure, skewer for javascript, etc. I'm not sure if things like that are available in "newer" IDEs.

Sorry, I ended up ranting. I just love to research "old" technology, as I find that they have much to offer over modern "equivalents".

EDIT: This post seems to stray a little from the context of this thread, but consider for example live coding. I'm not familiar with the workflow of the typical modern game developer, but if modern tools don't offer something similar to live coding, they might benefit from it. If a particular piece of code is only launched under very specific conditions in the game, something that would require a little time to setup, they might benefit from being able to change/add and load the new code while they're playing in that "deep context". I remember once seeing a video of someone developing an FPS in Common Lisp. They where shooting at a wall and checking how it impacted with it. They would switch windows to emacs, edit a bit inside a function, hit a keybinding, and have the shots altered immediately in the running game, without having to restart it or anything. They would develop the game while playing it!

I don't disagree with what you're saying in the more general case.

In this case, though, we're talking about programming games using assembly language for outdated hardware, and doing so for no real technical reason. There's little definitive in software development, but we can agree on this: avoid assembly language whenever it's not mandatory for performance/memory/platform reasons. Software written in assembly is harder to understand, harder to fix, and harder to change. This is one case where using relatively modern tools (i.e. higher level languages) is an unambiguous win.

I do agree old tech has an indisputable charm. That's not what I'm arguing against here. If you want to write retrogames using old-fashioned assembly just because you can, that's fine! It will just be harder.

Ok, what other tools are we talking about, then? :)

Somehow I doubt these die-hard ex Nintendo devs are insisting on using Emacs or Lisp. I'd say those are "modern" tools anyway, in the sense that they still hold revolutionary insights for modern software development -- and also probably were NOT used for Nintendo games.