HN Theater @HNTheaterMonth

⬐ fenomas

I don't know if the video goes into this, but she also gave a talk at a TedX event some years ago, on digital stuff for seniors and making art in Excel.

https://www.youtube.com/watch?v=gUjXiYtOC7Y

⬐ ksec

I notice the mouse, I really hope Apple do acknowledge they make crappy mouse.

Another thing I am wondering, what makes a company not hiring programmer at old age when their brain are still functioning properly?

⬐ elldoubleyew

With more age usually comes more experience, and with that higher wages. That's the canned answer.

But in this case I see your point. Many of these young CEOs just don't want older people in their offices. They have youth as part of "their culture". They also generally assume that older workers will be slower to adapt and less welcoming of a more volatile work environment; both frequent traits of many tech companies.

⬐ jansho

It's a damn shame. "Slower to adapt" is a weak excuse, youth is definitely a large part of startup culture. But imagine all that wealth of experience and wisdom that you potentially miss!

⬐ tonyedgecombe

>>With more age usually comes more experience, and with that higher wages.

I'm not sure that is true, if you can't get a job because you are old then your wage is zero.

⬐ wyager

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...

⬐ Danieru

In Japan the last company to have employed someone is on the hook for some retirement benefits. Thus one often sees hiring cut offs entering the fifties.

⬐ cyanexttuesday

Wow, I hope I'm still productive at that age.

⬐ copperx

Though luck. In Americans, coding powers disappear at 40. It's a known fact.

⬐ pottersbasilisk

Hopefully the age discrimination lawsuit against google will change that.

⬐ brooklyn_ashey

link: https://www.bizjournals.com/sanjose/news/2017/08/01/google-a...

⬐ chj

Knuth is still writing code this year and he's now 79.

http://www-cs-faculty.stanford.edu/~knuth/programs.html

⬐ droidist2

True! I think parent was being sarcastic though.

⬐ Grustaf

Absolutely amazing, well done!

But shouldn't it be "silver coder"?

⬐ None

None

⬐ Cursuviam

Both rare metals are good for this case.

https://www.merriam-webster.com/dictionary/golden%20years

⬐ wst_

I thought so far that silver is chosen because of a hair changing color with age.

⬐ Broken_Hippo

I'm of the understanding that you hit silver first, then you are golden. It is the same for anniversaries, isn't it? 25 years of marriage is silver and 50 is gold?

⬐ Grustaf

I don't think there is any connection with silver and golden anniversaries.

Referring to old people with "silver" probably refers to the hair, "golden years" I guess is because of relaxing in retirement and the wisdom of old age.

⬐ jkw

can someone list the games she's made? would love to try them out!

⬐ kawera

https://itunes.apple.com/us/app/hinadan/id1199778491?mt=8

⬐ droidist2

Her website is interesting looking. It reminds me of the sites I used to make when I first learned to code HTML from scratch.

http://marchan.travel.coocan.jp

⬐ kawera

Great find! Some of her Word and Excel games in english: http://marchan.my.coocan.jp/pc_playroom/index.htm

⬐ aikinai

That probably has more to do with her nationality than her age. Many Japanese websites still look like this, in particular for small businesses.

⬐ sergiotapia

She's so inspiring! I wonder if actually programming regularly kept her sharp mentally.

⬐ Scarbutt

nice coding setup ;)

Interesting how she seats, my legs would hurt.

⬐ nihonde

I'm painfully aware of my limit in sitting seiza from enduring formal events in Japan.

⬐ spraak

This is actually how I've been sitting for the past few months. I didn't recall it was a thing of Japanese culture, though, it just happened out of circumstance/need for me

⬐ yodsanklai

Interesting indeed. We talk a lot alternatives to sitting, but I don't recall reading anything about this position. Maybe worth trying.

⬐ rangibaby

My baby did it without being taught, so maybe it is a natural thing.

⬐ Jach

https://en.wikipedia.org/wiki/Seiza

⬐ zerr

I wonder what happened to the generations of 70s/80s/90s arcade/NES/SNES/etc... game developers. Where are they now..

⬐ sdrothrock

A surprising number of NES/SNES developers are still employed, if not at their original companies, at other game companies. I bet for every Shigeru Miyamoto you hear about, there are hundreds of other 50-something programmers who are still plugging away at games... and from what I hear, a lot of them have refused to adapt to modern languages/approaches/IDEs, which would explain why those particular people are not doing so well.

⬐ tonyedgecombe

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

There are plenty of young people like that too.

⬐ icebraining

a lot of them have refused to adapt to modern languages/approaches/IDEs, which would explain why those particular people are not doing so well.

Seems a bit shortsighted from the management's part. Retro and casual gaming is pretty hot right now, especially on mobile. I would license a good emulator, and then gather a good old-school team and let them make a few games their own way. Has anything like this been tried?

⬐ pjmlp

It is hot on the news, but as most Gamasutra and GDC postmortems show, not hot enough to make a living out of it.

All the most well known 80 and 90 game hits already have mobile remakes, not all of them commercial successes.

⬐ icebraining

I'm not saying remaking old games, but doing new games with the same tools. Like VVVVVV or Super Crate Box, but actually done with old tools, not just in an old style.

⬐ dandellion

I'm pretty sure that most modern retro games are not written in assembly, which is what they used in the 80s for consoles.

Most modern games are written using modern tools, most old developers that are still making games successfully are those that have adapted to modern tools, the others struggle. I think parent is referring to that.

⬐ icebraining

I get that games nowadays, even retro, are made using modern tools. My question is whether that's absolutely required, or if you could make a modern game using old tools.

For example, one guy ported Canabalt to the Commodore64: https://www.youtube.com/watch?v=yibnVB9iXfU

But instead of porting, the team would develop new games like Canabalt using old tools, and then sell the games integrated with an emulator.

⬐ the_af

But why? There's a reason we don't use the old tools anymore.

⬐ jolmg

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!

⬐ the_af

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.

⬐ jolmg

This subthread wasn't really restricting itself to writing games in assembly languages. Multiple ancestor posts were talking about "tools" in general, including approaches and IDEs, like sdrothrock expanded in an ancestor post.

If you're arguing specifically that using an assembly language is less productive than a higher level language, then I fully agree with you.

⬐ the_af

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.

⬐ jolmg

This is getting pretty meta-, but I also don't think we were restricting ourselves to Nintendo. :)

You're focusing on specifics, whereas I had been focusing on the more general theme of the thread.

To me, the theme, as set by icebraining, was generally: "does modern game programming benefit from using tools of old?"

Here, "tools" is a very general word, not limited to just assembly languages. sdrothrock expanded a little by saying "languages/approaches/IDEs", and "approaches" and "IDEs" are also very general words.

Your post, to which I initially responded, was:

> But why? There's a reason we don't use the old tools anymore.

Because old tools typically do have niche communities of varying size using them, I take "we" to mean "the majority of programmers".

So I understand your argument to be (I hope I'm not mistaken): "There should be no reason to use old tools, because there must be a valid reason why the majority are not using them anymore."

It's this reasoning that I disagree with. The reason the majority are not using them is because the majority of them look to use what the majority are using. It's a positive feedback loop. The remaining users, the ones that decided to use a modern tool before it was popular, probably chose to use it mostly based on a very important decision that can be made for any tool: how easy is it to learn how to use?

Now, a typically inversely correlated feature to this is: how powerful/flexible is it?

As examples, think of the choice of Vim or Emacs vs Visual Studio or Eclipse, or the choice of CLI vs GUI. It's a choice between ease of use (the popular choice) vs power/flexibility. Most will chose ease of use, but we shouldn't underestimate the importance of the minorities that chose otherwise.

So to answer your question, "why?", in the post I had given, I was providing examples of tools that are considered "old" but still held benefits over modern tools. The point was to answer your question in the general context, rather than suggest for them to use something specifically.

Now, if we talk specifically about what an ex Nintendo dev can do with their old tools, I've have no idea. :P But if it's true that "a lot of them have refused to adapt", like sdrothrock said, while it might be simply due to learning inertia, I would also consider the possibility that there might be something that was lost to the majority that might be worth recovering, something that that niche would consider important enough to keep.

I don't know what kind of system you use, but if it involves use of a command line, consider that many think it old and useless. They'd ask, "But why? there is a reason we're not using CLIs anymore. After all, there's GUIs!". Here is a highly upvoted StackExchange question asking just that:

https://ux.stackexchange.com/questions/101990/why-are-termin...

⬐ icebraining

To take advantage of the skills and experience of the programmers mentioned in sdrothrock's post.

⬐ the_af

I understand that. I guess I'm saying that while it can be done, the drawbacks offset the advantages. Soon there won't be any games programmers that only want to program in assembly language anyway.

⬐ OnlineCourage

I know one...he's in his late 60's and he's an IEEE fellow.

⬐ teej

I have a friend and former coworker who has been working in games since 1990. He is an incredible software engineer and I ended up learning a lot from him. He just recently got out of games and now works at Tesla.

⬐ FraKtus

My first job was to work on some Jamma game boards in the 90s... Thanks to that I did learn assembly and how to create fast animations on small platforms. I left the field after a few years and started a company in the Live Event industry, we are doing media server / VJing software. I am 54 now and while I run the company I still code 50% of my time. Some of my younger colleagues wish I used more C++ and less C :-)