nlkl

I see this mentioned again and again, but I don't buy it.

For power users or users with niche use cases, sure there might be specialized software that lock you into Windows or Mac.

But for most casual home users, I think Linux would be perfectly adequate, and familiarity being the only real detractor.

Assuming someone can help install a friendly Linux distribution (and that the hardware is compatible), then what are the big blockers? Gaming maybe, for those where it is relevant.

But looking at all my not so tech savvy family members and friends, a browser, online versions of MS Office (or Libreoffice for sure), maybe Spotify or the like, would really be enough. Being able to install apps via an (actually useful) app store is a big win in itself.

Looking at those friends/family members, it is not like they are able to support their Windows machines either when something goes wrong or needs to be changed - I (or someone else technical) always need to help out anyway, fixing driver issues, installing software, changing any non-trivial settings, and so on. And I could just as well do that on Linux - and whether I need to pull up a terminal is irrelevant.

I see this argument again and again, but I would imagine most people reading this have separate work and home computers?

For the average home user I can see gaming - while hugely improved in recent years - could still be a showstopper.

But surely for the average user Libreoffice or online versions of MS Office will suffice? Surely there cannot be _that_ many average PC users that need the full power of Photoshop?

Of course I expect the average HN user to be quite different from the average user in general, but I really do think that many casual users get no advantages from Windows apart from familiarity.

I think the above post must refer to how it works in MacOS. In Gnome, the app quits when the last window is closed (by default at least).

I guess this is a matter of taste, but personally I strongly dislike the way MacOS works here.

A bit of a shameless plug, but maybe it could be of interest. Having been through a similar journey some years ago I spent some time back then to design a variation of Knizia’s Battle Line/Schotten Totten for a standard deck:

https://boardgamegeek.com/filepage/191552/vassal

It is not the first such variant, but one that I felt a bit more pleased with than the other variants I found.

I use Mac for work, Linux/Gnome for personal use, and have used Windows up to and including 11 both personally and professionally in the past (although a lot less recently).

In terms of the desktop environment, I feel Mac is severely lacking behind. I know there are very mixed opinions on Gnome, but to me the Gnome UX feels extremely well thought out in comparison.

The apple ecosystem might be very well integrated, but in terms of the macOS UX it feels the exact opposite. Why can’t I close an app from mission control? Why can’t I launch apps from mission control, but need to e.g. open launchpad first? In Gnome the activities view unities all of those experiences in a way that is seamless and just clicks for me, but in macOS everything seems to be separate apps/features that don’t play together at all (out of the box at least). Add to that all the other small frustrations that you need to address with third party tools, it is - for me at least - a very unproductive out-of-the-box experience.

Of course this is subjective, and might be partially an issue of (my lack of) skill/experience.

I can recommend Timendus test suite (which includes the one mentioned as well), as a more thorough set of tests and verification utilities: https://github.com/Timendus/chip8-test-suite

There are a lot of other useful references and tools worth mentioning, depending on how much hand-holding you want when implementing the emulator:

  - http://johnearnest.github.io/Octo/
  - https://laurencescotford.com/chip-8-on-the-cosmac-vip-index/
  - https://tobiasvl.github.io/blog/write-a-chip-8-emulator/

Additionally, note that there are lot of variants of the instruction set / system-specific quirks, which you probably don't want to entirely ignore in an implementation. In particular, the Cowgod's reference doesn't cover this fully (Matt Mikolay's is more thorough, but doesn't cover everything either).

Once you get the hang of at least one programming language where nulls do not exist, you realize just how much unnecessary pain they cause.

There are of course several ways to represent the absence of a value, fit for different paradigms and programming styles, but I think most of us can agree at this point that having untyped null values is a very bad idea in most cases.

Whenever I program in C#, I always have to be overly paranoid, as more or less anything can be null. Option types certainly introduce some development overhead up front, by forcing the developer to handle the possibility of an absent value, but in my experience this is still far less than the amount of defensive programming necessary to handle nulls correctly.

As a response, I decided to implement a practical and safety-focused C# option type, and now use it more or less everywhere.

Reference: https://github.com/nlkl/Optional

Certainly, this does not guarantee that values are not null, but it allows you to be explicit about absent values in your own APIs, which is of great value. In turn, null checks become much easier as you do not have to accept nulls as legal values (except at boundaries to external code), and working with potentially absent values become much less cumbersome, due to a convenient API.

Interesting things are happening to programming languages these days, and I am quite curious to see the next steps. The C# language team as well has some focus on this (https://github.com/dotnet/roslyn/blob/features/NullableRefer...).

Just as a note: I am aware that this is yet another maybe monad implementation in C#. However, this is one that suits my needs, while staying simple and easy to use.