Every time someone asks me which retro handheld gaming console to buy, I point them towards an Analogue Pocket, or the cheaper cartridge-based emulator the Evercade. But that story is far from complete: there is much more choice than I initially realized. Still, how to choose? Fear not—observe the following Decision Tree:

The decisions I’ve included are the following, from left to right:

• An original DS Lite (white, of course) or a New 3DS XL. Both can be hacked to install custom firmware for homebrew. The DS Lite still supports Game Boy Advance cartridges though, so if 2001 retro carts is your thing, you might want to go with that. The New 3DS XL will serve you well when it comes to Nintendo’s golden age of DS and 3DS games. Budget: hard to say, depends on your second hand dealer or eBay scores. Some DS Lites go for €70.
• A modded original Game Boy Advance or Game Boy Color. If these machines don’t emit retro, I don’t know what does. Be sure to replace the screen with a backlit variant. There are ample of other cool mods that further increase the price, but you can get a GBA for €45 and a spare screen for €35 to solder it in yourself. The GBA still supports original GB and GBC games, although the resolution is very limited due to the widescreen layout. If you prefer 8-bit goodness, I’d buy and mod a GBC. Unless you have the money to get an Analogue Pocket, of course.
• A PSP Slim or PS Vita with custom firmware installed that can boot ISOs instead of that horrible miniCD loader. These are actually popular choices in the retro community: the screen is excellent, they’re not that expensive, and you can run Sony’s entire PSP and PS1 library, besides the conventional (S)NES emulators! Be careful with PSP Slim revision numbers, some are more easily hackable (and wanted, thus more expensive) than others.
• An Evercade for those in need of physical cartridge loading that want something different than Nintendo’s popular machines. It is very affordable—for €90, you have the handheld with three carts!—but comes with a sub-par screen. Its cart library is rapidly expanding, but still only contains a bit more obscure games. Remember that this is still emulation, albeit in a properly licensed way. The battery life sucks though.
• The Play Date, a weird newcomer with a crank and a monochrome screen that, as The Retro Book dictates, isn’t even backlit. It comes with a subscription service and is fairly expensive itself (€180), but game development support is great. This is one of those new old retro devices. Let’s hope long-term support will be lasting.
• The Analogue Pocket, one of the more expensive machines—Europeans, watch out with hidden import taxes. This thing’s screen is one of the best I’ve ever seen and it carelessly gobbles up any GB(C)(A) cart I throw at it. Supposedly comes with save state and screenshot etc support, but the OS is for the moment still a bit lacking. If you want to go physical cart hunting and want only one device, this or the (3)DS is probably it.
• The Switch Lite. If you want a retro fix (through emulation and a monthly subscription service) but still want to play newer games now and then, you can’t go wrong with a Switch (Lite). There are so many superb retro-inspired games released on the Switch lately, it’s becoming hard to keep up! Nintendo’s own older console emulation support is not great but at least this is a sure way to play N64 games. I don’t recommend getting an original Switch, the Lite is where the real handheld fun is at: the D-pad is better and it (almost) fits in your pocket.
• The Anbernic RG351V and its variants. This is a Chinese quad core emulation machine with supposedly great PS1 and N64 emulation (don’t believe that). However, with only €105, you can’t go wrong. Do remember that you’ll have to dip a toe in that shady looking gray area of “stumbling upon” ROM files, or have to dump them yourself with the help of GBxCart-related PCBs. You can slot in any Chinese or Raspberry Pi-based emulation solution in here.

To follow the tree, answer the following questions:

• Is your budget > €150?
  • If yes, do you also want to play more modern games?
    • If yes, get a Switch Lite!
    • If no, do you have or want to buy physical cartridges?
      • If yes, get an Analogue Pocket!
      • If no, get a Play Date!
  • If no, are you okay with emulation?
    • If yes, do you want legally licensed games?
      • If yes, get an Evercade!
      • if no, do you care about proper PS1/PSP support?
        • If yes, get a PSP Slim/Vita!
        • If no, get an Anbernic variant!
    • If no, do you want more than 1 screen?
      • If yes, get a DS Lite or New 3DS XL!
      • If no, get a modded GBA/GBC!

I purposely left out the recent Steam Deck since that’s anything but a retro machine. And to all Sega Game Gear or Neo Geo Pocket fans: sorry! Replace the modded GBA/GBC with your favorite nineties handheld. The Analogue Pocket supports Game Gear games through a converter at an additional cost. Also, there’s the Neo Geo Pocket Color Selection Vol.1 (among others) available for the Nintendo Switch, but it does run on emulation.

Happy handheld retro gaming!

By Wouter Groeneveld on 23 May 2022.  Reply via email.

When it comes to teaching software engineering, I’ve been thinking “We’re doing it wrong” for a while now, and the recent ACM Tech talk “Lessons From the Fifty-Year Quest to Turn Programmers into Software Engineers” only confirmed my suspicion. Adam Barr, a seasoned software consultant that was involved in major Microsoft products for years, gave a surprisingly sobering talk by serving us quotes from fifty years ago. How about this one from E. Dijkstra in 1972 (emphasis by Barr):

It would be very nice if I could illustrate the various techniques with small demonstration programs and could conclude with “… and when faced with a program a thousand times as large, you compose it in the same way”. This common educational device, however, would be self-defeating as one of my central themes will be that any two things that differ in some respect by a factor of already a hundred or more, are utterly incomparable.

Guess how we still teach software engineering—and computing in general? Right, small demonstration programs! Here’s a function:

int add(int one, int two) {
	return one + two
}

Write a unit test for it! Here’s one as an example:

TEST(AddTest, ShouldAddOneAndTo) {
    EXPECT_EQ(add(1, 2), 5);
}

There, you now know how to unit-test stuff. What’s next? Right, design patterns. Here’s a factory—etc, etc. Of course, you have to start somewhere, and syntax and ecosystems are usually the first trip wires students struggle to overcome, so throwing them in the deep end by presenting a huge project with thousands of unit tests or all too pragmatically implemented design patterns will be of little help here.

So we start out small. The problem is, we usually also end small and never neatly string everything together across courses. No way, that would mean collaborating with another teacher, woah there. Academia can be a sad state of affairs sometimes, and although this is not always the case, it’s much more common than you think. It’s somehow surprisingly hard to present a uniform picture to the students from the teaching staff as one team instead of a collection of individuals with their own style and preference for tooling, that causes further confusion.

Within my own courses, I try to relate the small examples to the work field by digging into source code from bigger repositories available at GitHub. It’s both educational and a lot of fun to dabble in the Quake 3 or BoardGameGeek app source code, looking for examples of dependency injection and smart usage of factory classes (or, in the case of Quake’s C code, structs). What is strange, however, is that this problem is far from new, if we are to believe Adam Barr. Here’s another lovely quote, from Harlan Mills in 1980:

If precision and scope are not gained in university education, it is very difficult to acquire them later, no matter how well motivated or adept a person might be at individual, intuitive approaches to problem solving.

It’s a quote I completely disagree with. I learned almost all the ropes after university education: both precision and scope. But still, it proves that in the eighties they didn’t quite yet solve the quest to turn programmers into software engineers.

Barr explains that academia overly focuses on what he calls “individual problem solving”: small subsets of algorithmic problems, that have little to nothing to do with real-life software engineering problems. Another classic example would be teaching and proving complexities of various sorting algorithms. Sure, they have their use, but mastering those problems by hacking away individually has little to do with team-based software engineering.

I used to think that the difference between the titles “programmer” and “software engineer” is just a matter of vanity, but in Barr’s context, a programmer will struggle to pick up the role of a software engineer, and in university, we’re teaching students to become programmers, while we actually need software engineers. Stop focusing on performance and algorithms. Focus on readability and code. The same is true for research, according to Barr: where is all the empiric software engineering research¹ that focuses on how writing code in practice works? Instead, we’re publishing heaps and heaps of… individual program analysis results?

Isn’t it telling that in the seventies, both academics and industry experts like Dijkstra and Mills warned us that this ain’t the way to teach computing? Fifty years later, the situation apparently hasn’t changed much. This isn’t just according to Barr, or according to my personal experience with teaching, but also according to the research I’ve encountered and conducted myself by analyzing learning outcomes of computing-related course material across European universities.

There is no single explanation for this, but I feel that we aren’t really trying hard enough to solve it. Instead, we’re just minding our own business and securing our position by upping the P score through publishing stuff (anything goes!). I’ve been known to criticize how academia works before, and although I have little influence and am often wrong, I have the feeling the critical mass is way too small to radically innovate in that world.

Adam Barr warns academics that code bootcamps might take over—and perhaps rightly so. A few other observations that might contribute to the issue:

• In academia, programs and code is mostly throwaway garbage—write-once objects to grab results and publish. This emphasizes the wrong aspects (Barr’s algorithms VS clean code).
• There are too little entry points to conduct empirical software engineering research using “real people” instead of students as the test subjects.
• The structure in academia is much too rigid. Its culture facilitates slow reactions, individualism, and focus on research instead of education, with little incentive to change.
• There is surprisingly little real-world experience within academia. Many professors never really faced Dijkstra’s “a program a thousand times as large”, so how are they supposed to teach how to handle that?

Barr ended his talk with a few recommendations: let students taste real-world code by exploring open source projects, give them bigger open assignments, etc. These conclusions can be read in pretty much every single paper on computing education, and as good as this practical advice is, I wonder why it’s almost never taken to heart. Even if it is, will it be enough? I wonder whether other universities might be more progressive than the ones I have experience with.

All things considered, in my opinion, the future is looking bleak. I’m still convinced students only really start learning as soon as they graduate and start working (and by “work”, I mean in industry, not staying around and doing a PhD!). Hopefully they end up in a company that cares about life-long learning, assigns them an amicable coach, and employs pair programming to quickly bring their knowledge above the minimum level. The more I think about this, the less I think academia—at least in its current state—will be able to rectify this.

And without a critical mass, there’s little I can do besides getting even more frustrated.

By Wouter Groeneveld on 18 May 2022.  Reply via email.

May 2020 was unusually hot. According to European service Copernicus, May 2020 was the hottest since the beginning of the measurements. But May 2022 is also unusually hot—and very dry. In Belgium, so far, there has been 1 mm of rain, that would be the second driest month since 1983, where only 37.6 mm of rain was measured during the whole spring period. This persistent period of drought regularly appears in the local news:

Het neerslagtekort in Vlaanderen is op dit moment al groter dan dat van de extreem droge zomers van 1976, 2018 en 2020. Dat blijkt uit cijfers van professor waterkunde Patrick Willems (KU Leuven).

(The precipitation deficit in Flanders is on this moment already bigger than that of extreme dry summers of 1976, 2018, and 2020. This is evident from numbers of hydrology professor Patrick Willems (KU Leuven)).

The article then proceeds to deal out very practical tips such as “do not leave the tap running” (really?) and “place a rain barrel in your garden”. Aha, we’ll get back to that.

I care about the weather, not only to have something to say when greeting neighbors during a walk with the dog, but also because I want my lettuce, courgette (I’m sorry Americans, sure, summer squash, whatever), and beets to grow. We only have a humble vegetable garden, and every single year I’m too late to the party or forget to sow, but it’s still something I deeply enjoy. Rooting in the earth takes me back to earth and keeps me away from a keyboard. Sometimes the chickens are permitted to help.

These thirsty plants thrive with the right combination of sun, compost, and water. The latter is becoming a problem. My father has a huge greenhouse that is served by a combination of a groundwater well plus catching plenty of rainwater, while we only have a meager 220 l water barrel connected to the drains of our garage. If I’m being very frugal, the garden requires at least four refills of a 5 l watering can. That means within ten days, our barrel is empty.

The alternative is tap water, which is getting very expensive too, next to the ridiculous natural gas prices. The unit price of a cubic meter of water was €1.9652¹ in March (excluding various fixed costs), which would be €0.039 for 20 l of vegetable joy. Even though that doesn’t sound like much, I’m being very conservative on the calculations, and I’d rather “catch it falling” instead.

How much rainwater can we catch, though? There are handy tools for this (in Dutch) that, depending on your location (Limburg: average rainfall of 62.5 mm per month), the size of the garage roof (60 m², just a wild guess) and type of roof (tiles, flat, …) gives an estimate on how much rain you can collect in a year: 40 m³ or 181 times the 220 l water barrel. That sounds like a lot of room for improvement! The calculator suggests to install a water tank of 3 m³, while we have one of 0.22. Ouch.

Except that the Belgian KMI institute measures on average 46.7 mm total rainfall each month instead of the above 62, and it’s likely going to drop even further. Also, DuckDuckGo’s image search result for “water barrel” is much more modest, like the one we have in the photo above, compared to a “water tank"—a huge container we first have to figure out where on earth to put! Likely, indeed, on earth, preferably our own personal piece of earth. I’ll ask the chickens to move. Again.

I’m not quite sure where I’m going with these numbers, except that I need to remind myself to attach the second barrel we have lying around for a while now.

There’s an upside to the persistent drought: no pesky snails that make the tiny plants disappear.

Addendum, 17th May: Michael Hamann suggested to use a mulch method which involves a layer of hay to drastically reduce the need to water the vegetable garden. This is supposedly called the Ruth Stout method. Interesting, thanks Michael!

By Wouter Groeneveld on 16 May 2022.  Reply via email.