If it would be less trouble (because of customs and other external factors), and assuming it can help, maybe a phone keyboard can also be considered? An OTG cable plus a normal USB keyboard might also be a solution if portability is not a requirement.
While I gladly embrace the shift to solid state, I find the mechanical engineering in old electronic devices, cameras in particular, quite fascinating.
The name, monocle, also further misleads those expecting the physics topic. They actually have a nice logo with a lens and the lambda symbol which is often the symbol used for wavelength.
Entrepreneurship sure may be difficult as a whole. However, some difficulties are not really necessary. For me, it's a matter of seeing the end goal and removing as much obstacles as possible to get there faster (optimizing for time). I see the need to have a proper job or chase funding as additional obstacles if you are abroad.
Opportunities that require big risks is also another factor. My academic acquaintances abroad may be doing well financially and travel-wise, but they all have to live their foreign bosses' ambitions despite being very bright people. It's far easier to take crazier entrepreneurial risks with the safety nets in one's own home-country.
Having built both desktop-native and browser-based apps, I think there is an efficiency in doing the widget layouts textually via code/markup once you get over the learning curve. I believe Qt and wxWidgets also have automatic layout features, but doing this on top of C++ maybe makes the experience less smooth. So far form designers in Visual Studio require manual pixel layouting, which becomes tedious as the GUI evolves to be more complex. This is great for beginners as dragging and dropping controls is so easy to learn. But as soon as you have a dozen or so controls, you start to notice the time spent manually dragging/aligning/sizing that is absent in markup-based or procedurally generated GUIs that do the layout calculations for you.
It gets worst when these users/students run to others when the AI generated code doesn't work. Or with colleagues who think they already "wrote" the initial essay then pass it for others to edit and contribute. In such cases it is usually better to rewrite from scratch and tell them their initial work is not useful at all and not worth spending time improving upon.
My personal/work files for which the physical media of origin no longer exists. Source codes, mine and of others that I care about. Compilers. Lots of books and Wikipedia.
Build/make something. Preferably something new to you and preferably on your own as much as possible (even if you're following someone else's instructions).
Maybe cheating a bit if we allow compilers to run on more powerful machines, different from where the program will run. It could be possible to utilize more modern or "ergonomic" programming languages or rely on convenient libraries (assuming they are also efficiently coded). Programming languages in the 80s would not be as fun as what we have today partly because they were designed for limited hardware and partly because there's not a lot of other languages to learn from yet. IDEs, tooling and libraries have also come a long way.
Knowledge access is also something that has improved significantly. Programmers back then may not have had all the information that could have improved their work.
I believe Audible is already using non human speakers as well and just making up names for the narrators. I can tell since sometimes pronunciations are wrong and sound similar to TTS mistakes.
Have read the first few chapters and it expects that you either read the accompanying source code or implement your own and pass the tests. The pseudo code presented in the book often look like function calls with the inner details not there in the book. Furthermore, as already pointed out in another comment, the available implementation is in OCaml, which is probably not something many C programmers have experience with.
Nevertheless, I think I'm learning more from this book than most other books I've tried before that are far more theoretical or abstract. I'm still eager to reach the chapter on implementing C types. I think it's a good book, but it requires more effort than something like Crafting Interpreters or Writing a Compiler/Interpreter in Go, while also covering topics not in those books.
I use Audacious on Ubuntu as I can almost get the same UI configuration as foobar2000, tabs of playlists which can be made on the fly or from saved files. A music player app is something I always use on the background, so all the fancy visualizations or album art are not so useful for me. It's also sad that the default music player on Ubuntu (Mate) doesn't have a volume control out of the box.
Thorsten Ball's books are the closest thing to Crafting Interpreters. Not just by topic, but also with how the code is presented. By far these are among the few books I know that take the effort to guide the reader to programming something complex from scratch, while also being testable as the program grows. This means that previously presented code changes along the way as new features are added.
A lot of other "code yourself" books, on the other hand, simply slice already finished codebases, and there's no way to test a simpler incomplete version of the program unless the reader makes extra effort and go beyond what is presented in the book.
While there is a lot of overlapping topics in Nystrom's and Ball's books, there are also enough differences to learn something new from the other. Ball's books uses the same parser and AST as front ends to both tree-walking and VM interpreter. CI, on the other hand, skips the AST for the VM interpreter, and also teaches extra topics like implementing garbage collection, dictionaries/hashtables and class-based OOP.
I find memes to be more annoying as the meme stock images are far less likely to be relevant and to add any value. AI generated images, on the other hand, are sometimes used to illustrate something useful. Given a choice, I would personally still prefer non AI images though as I appreciate the effort and the "personal touch".
begin/end might be more familiar. Some languages don't even have the equivalent of (Pascal's) "begin" since other keywords are already associated with starting a block.