Rockstar Programmer

Hello, welcome, and thank you for your interest in Munchy Beta. Munchy is an iPhone app that uses AI to analyze diet. It is primarily designed with two goals in mind: • To give the user a better understanding of the food we eat • To help the user with long-term diet tracking If you’re interested in trying Munchy Beta, you’ll need an iPhone with at least iOS 16. Sorry, Android users. You can contact me through the platform where you’re reading this or send an email. Once you’ve done that, you’ll receive a reply within a few days with more details. And now you’re probably wondering: - Does it even work? Yes, it does. If you take a picture of what you’re eating, I believe I can demonstrate that the accuracy over time is better than 20%. In reality, I think it’s better than 10%, but I’d rather under-promise than over-promise. - And is 20% good? Yes, it is. Manual diet tracking takes time and always depends on either weighing the food or making a personal judgment. B...

Back in the days when real men programmed assembler , and the interwebs were nothing but a wet dream, data-driven programming (DDP) was a big thing. It was one of the most important ways of improving the capabilities of crappy assemblers and compilers and enhancing the performance of slow computers. Imagine doing a sinus calculation on a 1MHz 8-bit Motorola MPU without floating point.  Then you would know what one flop is.  The solution was to replace the insanely costly math with a sinus table, thus replacing code with data. If you wanted an arcTan function instead, it just required a new table.

So, I've opened a GitHub repository .   The idea is to provide some real code to back up my claims about building larger applications. I put a lot of thought into the platform, language, etc., that I wanted to use.  I finally settled on:

As I mentioned in my first post about building classes , I try to enforce a software design where classes are arranged in a pyramid-like hierarchy , with methods only trickling downwards and data only trickling upwards. This approach may seem a bit restrictive initially, as you often encounter situations where lower classes need to inform higher classes that something has happened. Since lower classes cannot directly call higher classes under any circumstances, this is often addressed in games by simply polling the lower classes for changes. A classic game loop would look something like this:

There are two main ways of directly dealing with error handling in modern programming: exceptions and error codes. Unfortunately, neither of them is any good. Although various techniques exists to aid in debugging - like asserting and logging - these methods are not really great for catching unexpected behaviour or the user being a douche. Essentially we are stuck with the two bad ones.

Now, if you read my previous posts, you will know that I have mentioned wrappers several times, and said that they are a very powerful but underrated tool. If you have never used wrappers before, this might seem like a fuzzy statement, because at first glance it might look like a lot of wasted work.

As I mentioned in the post about The Lego Principle , I regard the main bulk of classes as self-contained and unitform building blocks, put into a pyramid, and only knowing about classes in the layer immediately below them. As methods can only travel downwards and data only can travel upwards, classes have no need to know about classes above them. This is an extremely important point. A class should be 100% self contained, and only use functionality from classes below it and expose data to classes above . 

When my daughters were around kindergarten age, the living room would often become a train wreck of Duplo Blocks. Instead of stepping on them during the night, I would often end the evening by building a giraffe nearly as tall as myself, and the ungrateful kids would then topple it over first thing in the morning. Nothing as healthy as starting the day with a bit of destruction. I don't know if the giraffe inspired me, but later when people asked me how I was capable of writing large and complicated applications in such a short time, I came up with The Lego Principle.

So, my fellow programmers, let us have a look at the most important aspect of programming. Namely, how to get a higher salary.  No, sorry, jokes aside :)  Let us instead have a look at readability , one of the single most important aspects of building a large application. First, let me share some of my own philosophies on the subject. Bear with me on this. Imagine reading a good novel. The author ensures that the language is fluid and consistent. The sections are separated according to their content. They do not just jump to a new scene in the middle of a sentence. You will not have to backtrack the story to understand what is happening, and they will not use excessive words to convey the content. Less is more. Many of the same principles can be transferred to programming. In many ways, reading a good program should be like reading a good novel . Your code should be easy to read and easy to understa...

I think it was Bill Gates who said, “ Software is a great combination between artistry and engineering ,” and he was absolutely right. It is.  The first time I heard the term “rockstar programmer” was in relation to  John Carmack . He was the guy who first used  binary space partitioning  in a 3D game, dramatically speeding up rendering and giving us classics like Doom and Quake on a 66MHz Pentium. In the mid-nineties, Mr. Carmack was driving a red Ferrari 328 and became the synonym for the term, launching us all into a dream about becoming filthy rich game programmers. I am a guitarist and a big Rolling Stones fan, so at that point, I had already started using Keith as my online avatar, but Carmack is without a doubt a contributing factor to why it stuck.