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.
Sometimes I still find the need to write a lot on a phone and it's thumb typing in a touch mobile device that frustrates me the most. I believe a good add-on keyboard, preferably just as portable as the phone, would have more use cases than a hollow laptop that can be just as big (and similarly less convenient) as a normal laptop.
I would be interested with an ability to temporarily filter (show only from / hide from) shared links from a specified domain or see all posts of the same type (e.g. Ask HN, Tell HN). But without having to be a full blown search.
If you have time, blog or share code. If things work well, you could get audiences, but there is much less socializing. Writing also helps in becoming more articulate when opportunities for conversations arrive.
Yes, unfortunately. I hope though that LLM's reliance on training data would at least give human writers an advantage when it comes to novel content such as new tech.
I'm actually biased towards older articles, given the rise of SEO oriented writing, and now, LLM generated content. Standing against the test of time should be a badge of honor. But readers like me may be the minority.
I feel weird about edible artwork. Do I buy it for food or do I buy it as a piece of art? How many of it would I ever buy? Then there's also the added costs to both sides. It might be very niche.
For those who want to broaden their options and are not really constrained to only using SF2, the SFZ format has a similar purpose and there are many free instruments as they are easy to create (a text markup referring to the, typically WAV, audio files as is). Plogue sforzando [0] (freeware) is my favorite plugin for SFZ files. I learned about SFZ via an orchestra set called the Sonatina Symphonic Orchestra [1,2].
When working with non text file formats (e.g. coding a parser or file generator) hex editors are convenient for checking that data are where they're expected to be, finding out where they are otherwise, or checking what values they have. Even compressed file formats have header information that can be inspected if you have the format's specification.