As a human, I don't need to remember the content of every file I work on to be effective, but I do need to understand how to navigate my way around, and enough of how the codebase hangs together to be able to make good decisions about where new code belongs, when and how to refactor etc.. I'm pretty sure I don't have the memory or reading comprehension to match a computer, but I do have the ability to form context maps at different scales and switch 'resolution' depending on what I'm hoping to achieve.

- cryptography in general

- data compression

- a lot of DSP stuff is pretty magical in it's various applications - digital filtering, modulation/demodulation, recovery of weak signals in noisy environments, beam-forming etc

There's a lot of really amazing, largely mathematical, foundation work that we now tend to take for granted and without which we'd be back in the relative dark ages.

Across an entire scanline I think you normally get something like 63 6510 cpu cycles to do 'work' in, but only 23 if you hit a badline - keeping in mind that some instructions take multiple cycles to execute. This probably makes the timing difficult or impossible to manage with the characters turned on.

This is true if Grant is the only person doing the work, however having a well educated and scientifically engaged populace seems important enough that we (the human race) should devote a few more resources to creating high quality (and freely available) courseware for all curricula/year levels.

If you want to get fancy you could go for something like an Ultimate II+ and a usb key, which will get you a bunch of extra functionally like network connectivity, extra SID support, pretty solid compatibility, REU emulation etc (but UII+ will also cost a lot more).

Given you've got a real 1541, maybe you could just copy files/disk images across to the real thing if KFF doesn't work for a particular program I guess?

Funnily enough I'd been thinking that it's about time I tried (again, as an older person) to write a game or a demo for the old 64.

It's absolutely amazing what people are able to get out of these 40+ year old machines now, and I love that there's still a vibrant scene.

In addition to the tools specified in the article, I would also recommend "retro debugger", it's an amazing tool for single stepping through code and seeing what's going on, even letting you follow the raster down the screen to see what code is executing on given scaliness.

Also, there are some really good youtubers out there helping to demystify how various games/demos work.. Martin Piper comes to mind as a good example.

It seems to me that the smartest people would be far more motivated to leave a country where they are unable to find other people like themselves to collaborate with.

And they'd be far more likely to come back in future and reinvest their overseas earnings in a country that they felt warmth towards than one that had forced them to play life in hard mode and was actively hostile towards them.

I think most people will feel better working in a position that is aligned with their values, but a lot of people can also tolerate/justify a surprising amount of cognitive dissonance in aid of supporting themselves and their families.

Whether it's convincing oneself that one's work will only be used militarily against baddies that deserve it, that the people one is putting out of work with automation/AI will fall on their feet into much better jobs, or that manipulating people into spending more time in one's app is actually a public service because the app itself does some good, people will find ways of compartmentalising and living with what they do since the alternative of having a family less well provided for is seen as the bigger failure. "Suck it up princess and get on with it, you can't bear the weight of the whole world on your shoulders, and you've got kids who need to go to college"...

My main advice would be to try not to stray so far from your moral compass that you can no longer recognise yourself. No amount of therapy or donating to charity is going to fix you at that point.

I'm really glad there are people like yourself out there, asking questions like these. I wish more were like you, and I wish you good luck and happiness whatever you choose to do.

[1]: https://www.drive.com.au/caradvice/ute-tax-breaks-exemptions...

Whilst I accept that bad abstractions can really hold a codebase back, good abstractions and layering are what make code clean, understandable, and maintainable. I don't think we should throw the baby out with the bathwater.

What's important is having good designers who understand the domain and are able to judiciously select the "right abstractions" to apply at the "right time". Often this will mean people who have worked in a domain and made or experienced the consequences of mistakes previously.

Bad or inexperienced developers will write bad code. Good, experienced devs will do a little better. Don't let inexperienced devs design abstractions that you'll be stuck with for a while.

The idea that something could become less unwieldy or overall "smaller" by splitting it into separate codebases and introducing RPC and dealing with all the other complexities I mentioned above seems fanciful to me.

As far as I can tell the only semi-reasonable reason to want to move to micro-services is social -- effectively Conways law driven by Dunbar's number -- ie. you've scaled your organisation to a point where you have too many people to work effectively together and you need to split off into smaller teams, each with a subset of your total pool of developers, and want to be able to grant each team autonomy over their 'microservice'/domain to prevent death-by-committee.

I'd still argue most would be better off modularising/maintaining the monolith so multiple teams can work on it, but I do at least understand that rationale.

Consider the situation where you have a proliferation of micro-services all using a similar but slightly divergent stack, and you're notified of a security issue that means you need to update the same library across the entire fleet of services. I know what situation I'd prefer to deal with.

Additionally, as soon as you introduce RPC-style (or even event-based) interactions between services your complexity goes through the roof. You need to deal with:

- service versioning and backward compatibility

- serialisation/deserialisation complexity and latency, and synchronization of DTO-style objects between services

- more complex deployments

- far more complex testing

- in-transit encryption for data and key management (eg. Istio, ...)

- network-layer issues

- circuit breakers

- caching / other performance band-aids

- graceful degradation across the stack when services fail

- sagas or equivalent mechanism for coordinating cross-service operations and what happens when things go wrong (fsm help you if you end up needing cross-service atomic transactions because of your ill-thought-out service boundaries)

- etc.

I'm honestly amazed at how many people blindly follow the "microservices good / monoliths bad" mantra given how obviously wrong it is for most teams.