or why taste is not subjective, featuring a classic Paul Graham essay.

In the world of AI, taste seems to be becoming increasingly important. Therefore, I think it is necessary to shortly look at the core of taste and beauty and examine the objectivity of taste. Here is my take on the topic, but feel free to let me know what you think as well.

The Paradox of Objective Taste

Since I was young, I’ve often heard the claim that “taste is subjective.”
People state it as if it were an obvious fact, but I’ve never found it fully convincing.

Take a rose. Its beauty is broadly recognized. People are drawn to lush gardens and instinctively avoid rot and decay. That at least suggests our senses are shaped by evolution to move us toward good and away from bad.

I agree that small preferences in taste may vary, for example when it comes to fish or cheese. But beauty itself seems to have an objective core.
This is also because of the inherent objectivity of joint human subjectivity.
When many, at least partially independent, subjective views are aggregated, an objective view emerges.

However, a paradox exists: for this collective objectivity to be valid, individuals must believe their taste is personal. If people perceive beauty as a fixed standard, they are liable to mimic the consensus rather than form their own judgments, i.e. groupthink. Therefore, the illusion of subjectivity is required to reveal the reality of objective beauty.

Taste for Makers — an essay by Paul Graham

For a long time, I felt alone in thinking this way. I didn’t find much support for the idea that beauty could be objective. That changed when I read PG’s essay on taste. It put into words what I had been thinking all along.

He describes the current confusion about taste very directly:

“If you mention taste nowadays, a lot of people will tell you that ‘taste is subjective.’ They believe this because it really feels that way to them. When they like something, they have no idea why. It could be because it’s beautiful, or because their mother had one, or because they saw a movie star with one in a magazine, or because they know it’s expensive. Their thoughts are a tangle of unexamined impulses.” — Paul Graham

Moving beyond the critique of subjectivity, Graham constructs a framework for objective quality, identifying several immutable characteristics of good design, that I strongly agree with:

Simplicity
“When you’re forced to be simple, you’re forced to face the real problem. When you can’t deliver ornament, you have to deliver substance.”

Timelessness
“Aiming at timelessness is a way to make yourself find the best answer: if you can imagine someone surpassing you, you should do it yourself.”

Suggestiveness
“Jane Austen’s novels contain almost no description; instead of telling you how everything looks, she tells her story so well that you envision the scene for yourself.”

Utility
Design must not merely exist; it must fulfill its intended purpose.

Strangeness and Humor
Graham notes that truth often carries an inherent oddity: “Einstein didn’t try to make relativity strange. He tried to make it true, and the truth turned out to be strange.”

Furthermore, he suggests a link between levity and quality: “Good design may not have to be funny, but it’s hard to imagine something that could be called humorless also being good design.”

The Illusion of Ease
True mastery conceals the effort required to produce it. “If you’re not working hard, you’re probably wasting your time,” Graham asserts, adding that “Great designers make it look easy. Mostly this is an illusion.”

Symmetry and Nature
Finally, he appeals to the ultimate standard: “Nature has had a long time to work on the problem. It’s a good sign when your answer resembles nature’s.”

I would appreciate, if you leave a clap. But, only if you liked the article.
Also, let me know your questions or comments as well.

Regards,

Rashid Harvey

On Taste was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

When building AI agents, one of the biggest problems is hallucinations. But how can we prevent or mitigate them?

Hallucination

First, we need to understand what hallucinations are and why they occur. Generally, the term ‘hallucination’ refers to an LLM (confidently) making things up. But why does this happen?

The LLM is trained to give probabilities for each possible next token of a text. For training, a large corpus of data is used, which necessarily contains lots of data from the internet. Therefore, the models generally generate content similar to that which can be found on the internet, e.g. Wikipedia.

This is where lots of the antipatterns come from. For example, on the internet (and, tragically, in life generally) you will only rarely find someone admitting that they are wrong or that they do not know something. The LLM is therefore trained to just say something rather than say it doesn’t know. Luckily, this has already improved.

Fine-tuning and RLHF

Fine-tuning is the process of training the model further after its general pretraining (GPT = General Pretrained Transformer). This for example includes following instructions or training for specific domains like legal, math or coding. Recent models have been specifically trained to avoid hallucination using reinforcement learning using human feedback (RLHF)

The other reason, hallucinations occur is that once a token is generated, the LLM can’t take it back. It must simply continue; accepting the token. This means that one bad token can hijack the whole response. A funny example of this is the seahorse emoji 🌊🐎. Until recently, asking ChatGPT whether a seahorse emoji exists, would send it spiraling, generating all possible related emojis until finally exhausted, admitting defeat.

For example, see this blog post, which btw also shows that it’s not (just) the LLMs that are hallucinating (Mandela effect), but it also goes into much more technical detail explaining what happens inside the model.

This specific problem is now mostly fixed through fine-tuning, reasoning and online search as you can see here:

The Solution(s)

Because fine-tuning is so difficult and the most powerful models aren’t openly available anyway, we are left with prompt engineering, i.e. the harnessing around the LLM. Here are some techniques I found useful:

1. A way out
2. Preprocessing
3. Reasoning
4. Post-processing

I hope this helps

1. A way out

In my personal anecdotal experience, I have noticed giving the model a way out, i.e. giving it a plausible thing to do if it doesn’t know the answer, already helps. For example, for coding, you could tell it that it’s a junior engineer, and it should ask the senior engineer if it is stuck.

On the other hand, you can tell the model to only talk about a certain topic it is an expert in and refuse to answer questions regarding any other topic.

The general prompt engineering rule applies:
Never give the model a choice, always tell it exactly what to do.

2. Preprocessing

Preprocessing is all about giving the LLM the information it needs to fulfill a task or answer a question. One of the most-widely deployed approaches is retrieval-augmented generation (RAG). Before the LLM is given the query, the query is passed to a retriever, which finds documents from a database that fit the query, i.e. semantic search. These documents are then passed to the LLM together with the query.

A similar approach is online search, which has the additional benefit of providing real-time data like date, time, weather or news.

3. Reasoning

Just like a human should think before he speaks, we can use reasoning models which are trained to do just that.

Reasoning allows the model to

1. Formulate a response before “submitting” it,
2. Revise any inconsistencies,
3. Summarize findings and
4. Follow a chain of logical steps, like a mathematical derivation:
   “this leads to that, which leads to the following”

This is especially powerful together with retrieval.

Even without explicit reasoning models, you can ask the model to first start with the reasoning/explanation and then follow it up with the answer. This avoids the bad token generation problem, where the LLM is only left to justify a wrong answer.

The more natural way would often be to provide the answer first, e.g.:
“Yes, penguins can fly because they are birds.”

Here, after the “yes” is generated, the LLM can only try to find the best justification, but it can’t naturally say something else. It would rather continue saying something wrong than write something absurd like:

Can penguins fly?
Yes, penguins can’t fly because their wings aren’t made for it.

4. Post-processing

Depending on the domain, post-processing is more-or-less difficult. The general question to be asked is: Is this answer even plausible?

Verifiability: Often checking correctness, is much easier than generating a correct solution. For example, for Sudoku.

One way to check a generated response is by simply asking the model:
“Are you sure?” If the model is sure, you can keep the original answer. If it isn’t, there are several ways to go. Best is to try out different approaches like retrying or summarization. You could call this approach reasoning-lite.

Another approach is to verify the result of one LLM with another.
This works even better because the different providers are diverging farther and farther away from another in an attempt to compete.
This means they use different model architectures, different training data, different fine-tuning and different human feedback.

Andrej Karpathy brought this concept to attention and also to a beautiful extreme with his latest contribution: LLM Council

I’ll let him explain in his own words:

This repo is a simple, local web app that essentially looks like ChatGPT except it uses OpenRouter to send your query to multiple LLMs, it then asks them to review and rank each other’s work, and finally a Chairman LLM produces the final response.

I hope this was a useful overview of hallucination, and you can benefit from this in your own work. Please be aware that, due to the attention mechanism of transformers, you can do a lot with prompt engineering.
Use this power wisely.

Signing out,

Rashid Harvey

For quite some time now, I have been thinking about how to build effective AI teachers. I myself have been a lifelong student and teacher and aim to continue this beautiful effortful struggle — as Derek Muller would put it.

However, as a software developer and AI engineer, I want to believe that it is possible to build AI teachers that are almost indistinguishable from real humans; essentially passing the Turing test for teaching.

In this article, I will firstly lay out the difficulties, and then continue with my idea for the future of AI tutors and what would be necessary for them to become reality (which will probably be the most interesting). I will leave the assessment of current solutions “as an exercise” to the reader.

Definition of Teaching

To really understand what we are talking about, we should define it.

First, let’s look at the definition Google gives for “to teach”:

1. impart knowledge to or instruct (someone) as to how to do something.
   “she taught him to read”
2. give information about or instruction in (a subject or skill).
   “he came one day each week to teach painting”
3. work as a teacher.
   “she teaches at the local high school”
4. cause (someone) to learn or understand something by example or experience.
   “travelling taught me that not everyone shared my beliefs”
5. encourage someone to accept (something) as a fact or principle.
   “the philosophy teaches self-control”

In summary, I would define teaching like this

teaching: the transfer of knowledge

Knowledge can be very simple information like the date of the end of the second World War, or it can be much more complex like driving a car, composing music, solving math equations or speaking a language.

A predicament for the transfer of anything is of course that the thing already exists. The teacher must in some way or form already have the knowledge to be able to teach it.

Also, teaching cannot be separated from learning. There is no teaching without learning, and no teacher without a student. Teaching is a two-way process, which makes it so intimate and fulfilling.

Fundamental Difficulties

1. There is very little (textual) data available for teaching
2. Teaching is very difficult to verify: “Verifier’s law” by Jason Wei
3. Teaching is even difficult for humans. Most humans don’t know how to effectively teach. Teaching is a rare skill.

Data Availability

Firstly, most teaching still happens in a — non-digital — classroom, which are not recorded.

Secondly, published teaching materials like books, articles, courses and lectures are designed in a completely different manner than one-on-one tutoring. This is a general problem for conversational AI.

Finally, teaching requires a lot of non-verbal cues, because the teacher needs to know what the student understood and understanding is mostly communicated non-verbally (nodding, frowning, sighing, etc.)

Verifiability

“The ability to train AI to solve a task is proportional to how easily verifiable the task is. Any solvable, easily verifiable task will eventually be conquered by AI.”
 — Verifier’s law by Jason Wei
https://www.youtube.com/watch?v=b6Doq2fz81U

He also gives 5 criteria for verifiability

1. Objective Truth
2. Speed
3. Scalability
4. Low noise
5. Continuous reward

For learning, the ultimate objective is, as we determined above, the transfer of knowledge (to a human). How are you supposed to verify the transfer of knowledge objectively, fast and scalable? Teaching has extremely high noise (i.e. randomness and entropy). However, I believe learning can be assessed on a scale quite well.

Takeaway ⇒ AI could use tests or exams not only as a measurement of the student's capabilities, but possibly also as an assessment of his own?

Other idea: what about neural imaging to quickly verify learning effects?

General Difficulty

Teaching is even difficult for humans. How many of your teachers would you say were good teachers? And those people studied education for at least two to five years and probably had decades of full-time experience.

I believe that teaching is a skill that does not come naturally to the human. It requires an understanding of not only your own cognition, but also that of someone else. Almost like cognitive empathy.

Have you ever heard your mother (or someone close to you) say something like: “I already told you this a hundred times, and you still do it.” If your mother was a natural teacher, she would understand that she is doing something wrong if she is telling you something so many times without any effect on your behaviour. Clearly, she should try an alternative approach.

The fact that she, at least subconsciously, believes that, if she just tells you often enough, you will change, is kinda mind-blowing.

Summary

Teaching is difficult for humans, not digital, and it is difficult to get or synthesize data. This makes it impossible for AI to master.

Requirements for good teaching AI

But let’s at least try to find some requirements for good AI teachers so that we can get closer to finding it.

Driving

What LLMs are amazing at is providing structured and, mostly, accurate information. This has already made self-driven, intrinsically-motivated learning much easier, but I wouldn’t call it teaching, just like Wikipedia isn’t teaching anything. Because teaching is an active process, not a passive or, in the case of LLMs, reactive process.

A teacher needs to drive the student, not the other way around. Current LLMs sycophancy makes them too easy to push-over and simply not assertive enough.
A teacher needs to have a plan of what knowledge he wants to teach, and he needs to know how he can teach it effectively.
A teacher must often withhold knowledge while providing the tools necessary to acquire it autonomously. A teacher must be able and ready to push a student beyond his limits to enable real growth.

A side note: LLMs have actually massively hurt education by making it much easier to solve exercises without doing the hard work that is necessary for learning. Think of physical exercise:

“You wouldn’t take a fork-lift to the gym. The point is to make the reps.”
 — Charlie Gedeon in Is AI making us dumber? Maybe.
TEDxSherbrooke Street West, September 2025

Memory and Personalization

One recent improvement of AI agents is memory. Good memory is essential for teaching.

Firstly, the student’s knowledge must be known to be able to expand it. Initially building and expanding a mental model of the student’s knowledge is in itself a highly difficult problem. I think, it requires the teacher to already have his own knowledge mapped out.

Secondly, every student has his own personal quirks, strengths and weaknesses, difficulties, motivations and interests. Without a sufficient personalization, it is unreasonable to expect teaching to be equally good for every student. The teacher must be able to adapt to the personal needs of each student to an extreme level.

One of the reasons I stopped using Duolingo, for example, was that it would constantly give me exercises for the Arabic alphabet even though I didn’t need it, so it felt like a chore. It was so annoying that I stopped learning Arabic and later stopped using Duolingo altogether. I couldn’t bare it.

Personality

AI teachers must not only be personalized but also personal. This is probably not possible at the moment, but is definitely being worked on.

Personality means:

• Bias, quirks and weirdness
• Real-world stories and anecdotes
• Relationship and accountability
• Humour and emotion

Teaching requires holding the student accountable and constantly motivating the student, especially if the student is not intrinsically motivated to learn. You need to show the student the fruits of his work and the light at the end of the tunnel.

A teacher needs to incite fascination, inspiration and curiosity, break the student’s mind, put their head upside down and push them to their limits, be funny and humorous, and tell stories, give parables and mnemonics.

For example, I can still remember the Pythagorean theorem and the simple integer solution 3²+ 4² = 5² from the story of the Egyptians measuring their fields along the Nile. The more vivid the story and the more imagination is involved, the better.

Multi-modal I/O

Everyone is talking about the next AI UI. Everyone knows that it isn’t a chat. But what is it?

• Chat is good because it’s relatively unambiguous and easy to use. Also, it’s the native I/O for LLMs currently.
• Voice is necessary because it is much faster input (3–4x) and the native I/O of humans. However, current voice approaches are simply lacking. Currently, the user input is converted to text then fed into an LLM and then converted back to voice. This throws away so much context.
• Video would be optimal to also read gestures, facial expressions (AI is better at reading micro-expressions than humans due to its speed) and body language. But it probably is a UX disaster because the cost of privacy and compute outweighs the benefit too much.
  Note: I once gave a student no-camera lessons via Zoom, and we both quickly noticed how difficult it was to give lessons without the instant visual feedback video provides.
• One of the more interesting ideas is graphical and manual I/O. A digital playground or whiteboard like Miro or tldraw that both the teacher and the student can use to sketch ideas, underline stories and show examples would have an enormous benefit. Or think interactive animations and simulations like Brilliant, but spontaneously generated.

Please note that people learn best with multimodal learning approaches: visual + auditory + manual, as Veritasium shows in their video
The Biggest Myth In Education.

Learning Teaching

A truly successful AI teacher must be able to dynamically learn (globally) how to teach. The difficult thing is measuring and verifying teaching, as mentioned above. The next step is fine-tuning and reinforcement learning.

Technical Challenges

Let’s look at the technical challenges these requirements pose and some ideas on how they can be solved.

[AI agents] just don’t work.
They don’t have enough intelligence.
They are not multi-modal enough.
They can’t do computer use […].
They don’t have continual learning.
You can’t just tell them something and they’ll remember it. […]
It will take about a decade to work through all of those issues.
 — Andrej Karpathy in an interview with Dwarkesh from October 2025.

Andrej’s Problems

1. Reasoning
2. Multi-Modality
3. Tool-use
4. Continual learning
5. Memory

These are all things that are already being worked on quite heavily by different people, but they are still in their infancy, and so I think there will be concrete work-arounds necessary.

Work-around 1: prompt engineering

Don’t let the AI reason about teaching. Teach it yourself using effective and concise prompt engineering. Prompt engineering is quite under-rated and can even avoid hallucinations and sycophany in my experience.

Work-around 2: fine-tuning and RL(HF)

Fine-tuning with (Q)LoRA and reinforcement learning (from human feedback) isn’t perfect, but works, and can be used to replace, or at least augment, real continual learning, reasoning, prompt engineering and enhance tool-use capabilities.

Work-around 3: memory

Just like with prompt engineering, I believe, memory management shouldn’t be left to the agent, keyword: context engineering.

Firstly, the agent should remember things from previous conversations. There are two state-of-the-art methods:

1. The agent can retrieve from previous conversations (RAG)
2. After each session, the agent summarizes the contents.
   The log of summaries are fed into the context.

Secondly, there probably needs to also be a more structured memory.
This needs to be human-designed and should be customized to the subject and learning object. For example, this could be a record on different concepts that should be learnt.

Generally good ideas

Some other ideas and concepts will not hurt as well:

• pre-processing
• post-processing and plausability filtering
• sub-agents with seperate contexts

The application needs to be smart. Read my article on smart algorithms to understand what this means. In short:

Smart Algorithms are algorithms that have maximally valid/desirable output with minimally valid/desirable input.
You will need a lot of ifs and elses and error handling.

Latency

Another practical challenge is latency. A set of self-deployed self-trained models close to the user are a good idea. The other way to reach lower latencies is adaptive reasoning: less reasoning and smaller models for easier problems.

Bonus: Useful experiments

Here are some useful (technical) experiments you can try to test whether AI tutors can be good at the moment. I’ll keep this section short.

• Can AI draw things on a whiteboard. Let it draw a right-angled triangle. Then let it explain the pythagorean theorem visually.
  Finally, ask it to assess it’s own work.
• Design a memory layout to make the AI agent record specific information like the user’s name. Build tests. How reliably does it work?
• Fine-tune a small AI model that was trained before tool-use to use a specific tool you designed. Test again!

Wanna build any of this? Hit me up at r.harvey[at]outlook.de

Signing out,

Rashid Harvey

Why building AI teachers is impossible was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last Christmas, I wrote about an interesting Secret Santa combinatorics problem. The question is: If you randomly assign who gives a gift to whom, how likely is it that two people gift each other? Everyone needs a gift and must give a gift, and no one can gift themselves.

In mathematical terms, to get the likelihood we are looking for, we can divide the number of positive events, two people give each other a gift, by the total number of possible events. Now we just need to know what these numbers are.

In the last article, we came up with not less than two recursive definitions for the total number of possible gift arrangements.

However, I wasn’t able to provide an exact or a recursive definition for the number of such arrangements that do not contain a pair.

So what now?

There must be some use to going to uni, I thought, and so I asked people about the problem. A professor told me, after thinking for a few seconds, that I should put the first members of the series on oeis.org, as surely there must have been someone who already thought of this before.

Sure enough, of course there has. oeis.org is the “Online Encyclopedia of Integer Series”, and I found both the series we were looking for:

Firstly, the number of all possible arrangements is, funnily, called derangements: the permutations of n elements without fixed-points.
Fun Fact from the encyclopedia: Euler proved both recurrences in 1809.

Secondly, the number of positive events are the number of derangements with at least one two-cycle. The encyclopedia even gives the first 200 elements of the series!

However, the most interesting are the functional approximations, which are also given:

Number of derangements: a(n) = round(n!/e)
With at least one two-cycle: a(n) ~ n! * (exp(-1)-exp(-3/2))

If we put this together, we get the following analytical approximation

Which is almost exactly the result we got last time already, but now we have it analytically and can definitely say that the probability will revolve around this value for any group size n.

3 : 0 / 2 -> 0.0
4 : 3 / 9 -> 0.3333333333333333
5 : 20 / 44 -> 0.45454545454545453
6 : 105 / 265 -> 0.39622641509433965
7 : 714 / 1854 -> 0.3851132686084142
8 : 5845 / 14833 -> 0.39405379896177445
9 : 52632 / 133496 -> 0.39425900401510156
10 : 525105 / 1334961 -> 0.39334856973349785
11 : 5777090 / 14684570 -> 0.39341226879643054
12 : 71555121 / 176214841 -> 0.40606750597130464
13 : 901364100 / 2290792932 -> 0.3934725340771219
14 : 12618959353 / 32071101049 -> 0.3934682296600936
15 : 189284859750 / 481066515734 -> 0.393469205523884
16 : 3069424181265 / 7697064251745 -> 0.39877855775585236

Exact results up to n=16

The lessons

I learned quite a lot from this short mathematical adventure, that you need to ask the right people if you want to be successful. The thing is: Even though I knew about the encyclopedia, I didn’t think of using it. It might seem like a random coincidence that the professor gave me the idea, but in some sense it wasn’t.

Now, I also understand more that you need to learn where and how to search for what you are looking for. The internet has undoubtedly made this much easier.

Signing out,
Rashid Harvey

PS: The LaTeX renders were made using quicklatex.com. Give it a try!

I tried StackBlitz’s bolt, Lovable, and TraeAI by TikTok. In general, I was really impressed. However, there are still some things missing: After the AI did 80% of the work, the final 20% were not too enjoyable.

Agentic AI editors consist of a chat where you tell the AI what you want to build, and the bot plans and edits the source files to reflect your wish. While bolt, Lovable and others are purely for web development, Trae, Cursor and others are IDEs or IDE extensions that run locally and can do essentially anything:

What do you want to build? — bolt.new
Lovable is your superhuman full stack engineer. — lovable.dev
Trae is an adaptive AI IDE that transforms how you work,
collaborating with you to run faster. — trae.ai

Let me start chronologically with my experience using bolt.

1. Building a mobile public traffic display with bolt

I live in Berlin and we recently moved. This came with a lot of change, for example in our transport connections. My mom told me that she would love a way to know which train or bus was coming when, from the comfort of her home, to decide when to leave and which mode of transport to choose. This can be done using either Google Maps or the official BVG (public transport provider in Berlin) app. However, they were both not very comfortable: Google Maps requires you to input where you want to go and then shows you all possible routes. It almost does too much when you already know how you can reach your destination. The official app, on the other hand, was not viable either, because it can only show departures for a single station at the same time.

So, I decided to build a web app that I could deploy for free on Netlify and that my mom could save as a shortcut to her home screen. But really, I had been waiting for an excuse to try out the shiny new thing that Fireship had “advertised” in one of his videos: bolt by StackBlitz. I had already used StackBlitz and bolt was free.

The app “I” built allows the user to search for and select several stations. All departures from all stations are then shown together in a list sorted by soonest departure time. The departure times are updated regularly (~ every 10 seconds).

I wrote quite a detailed prompt, and quite quickly the AI had already built a working web app using Next.js. Initially and repeatedly, it did throw many errors, but I basically just pressed the “fix” button every time and the AI figures out what it has to do on its own by reading the error message. Interestingly, it even got the BVG API calls correctly, which exceeded my expectations. The frontend was written with React and Tailwind and as far as I can tell consisted of good and readable code. After about two hours of tweaks and adjustments, I had a working and deployed live web app. Of those two hours, I was only actively doing something a quarter of the time, and I could work on other things simultaneously. Deploying and transfer to GitHub was also just the click of a button. Try it out if you live in Berlin.

BVG View - digital departure board for Berlin's public transport

However, I have to say that I didn’t really choose to stop after two hours. Suddenly, without prior notice, my tokens were empty, and I was told to wait a day. Luckily, the app was already in a state where I could proudly present it to my mom, and she was satisfied.

After a few days, I had tested the app quite extensively (mostly on my mobile) and immediately noticed that the app was not optimized for mobile and constantly overflowed the screen width. Also, none of the very important SEO/meta things had been handled. I had to create different icons, the title, and description as well as the card image you can see in the embed above all by myself. As you can imagine, fussing with AI-generated Tailwind classes and Next.js configurations was quite tedious, but with the help of the internet I was able to solve most problems. It did, however, take quite a few hours to resolve all final issues and reach a point where I could proudly set the visibility of the GitHub to public.

After some time, I got an email by GitHub’s dependency bot. Apparently, the Next.js and PostCSS packages were outdated and had known vulnerabilities. While it was easy to fix in this particular case, it exposes a fundamental problem with these AI agents: They cannot operate effectively in an always changing, fast-paced world if their training data is not very recent — which is not really possible when you take the huge amounts of data into consideration that are required to train such a capable LLM.

2. Building a chess site with lovable

A friend of mine sent me a link to Lovable, and so I decided to give it a try, after I had used up my bolt tokens building the last project.

For a startup idea, I wanted to build a landing page: It’s all about the next-generation, all-encompassing chess learning app. My original codename was OreoChess (because Oreos are black and white, just like the players in chess). However, I didn’t want to risk a trademark infringement, and so I decided to pivot to Chess Cookies.

I love the cookie theme Lovable created. Integrating with Supabase (“free” and painless backend) and Stripe (ubiquitious payment provider) was almost too easy. I was quite satisfied, for example it also let me add legal pages for Germany, specify the fancy Cookie font or upload my own cookie icon. However, I felt like the underlying AI model employed by bolt was a bit better. For example, with Lovable the hero title is cut off at the bottom, even though I tried three times to fix this. Trying to get the AI to build a working chess board failed horribly.

Chess Cookies

What do you think? Tell me in the comments.

Bolt vs Lovable

bolt and Lovable feel the same, look the same and do the same.
They are the same.

• Both have simple GitHub logins
• Both make it easy to integrate Supabase, Lovable also supports Stripe
• Both make egress and deployment relatively easy. Moving my Lovable app to Netlify was a bit more difficult and required some debugging.
• The advantage of StackBlitz is that it offers a lot of starter templates that ensure that everything runs in the beginning. On the other hand, Lovable is much better at creating a community (feeling) with their carefully crafted emails and their showcase.
• Regarding the quality. Lovable and bolt both work well, but in my experience they still have problems with responsiveness (Lovable with very large and bolt with very small resolutions).
• For perfect results, a lot of manual work is required. This is amplified by the fact that the tokens quickly run out when you try to get the AI to change little things.
• Polish is not the AIs strength.
• Finally, both bolt and Lovable have a quite limited free tier.

For example, this is a sitemap that Lovable generated.
The last modified date: 2023–07–01!

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://your-domain.com/</loc>
    <lastmod>2023-07-01</lastmod>
    <changefreq>monthly</changefreq>
    <priority>1.0</priority>
  </url>
</urlset>

In conclusion, I would suggest using these for fun hobby projects. However, you can also use them for the initial scaffolding of a serious app if you are willing to dig through code you didn’t write — and possibly don’t understand — and put the final touches.

The only other way to get beautiful apps deployed so quickly is templates and no/lo-code editors like Webflow or Bootstrap Studio, which are all paid if you want decent results. In that sense, bolt and Lovable are really recommendable. Try them out on your next hobby project.

You have nothing to lose.

3. Trae — an AI-powered IDE

I learned about Trae from Theo, and I was amazed that TikTok, of all companies, made an IDE that could very well compete with Cursor, which raised $105M in their Series B in the beginning of this year (2025).

But when I tried to install Trae, it wasn’t available for Windows. Luckily, they had a waitlist signup form …

A few days ago, I finally got an email with a link to install Trae for Windows. I was excited and knew exactly what I wanted to build:
The chess cookies app.

So, I started building. First, I asked the AI for advice what frontend framework to use. I already knew I wanted to build a stand-alone app with Rust and Tauri for optimal performance and easy front-end development. But I wasn’t sure about the frontend: vanilla HTML/CSS/JS, TS with preact, Next with React or Svelte/Solid. I landed on Svelte because it’s simple, stable, compiled, and I enjoyed the tutorial when I tried it a year or so ago. This is what I told Trae:

Ok, I want to build a desktop app using Tauri with a Rust backend that can call custom Python code paired with a high performance instant feeling frontend (possibly even a SPA) using Svelte. Tell me how you would setup the development and production environments

Because I was in builder mode, it immediately started going at it in the empty directory. Next time, I would definitely do the initial setup myself. Trae messed it up quite badly and installed incompatible (and outdated) packages: SvelteKit 1 with TypeScript 5, Tauri 1. In the end, I had to do most of the operational work, like following Tauri’s SvelteKit-Tutorial and migration guide myself.

But suddenly, everything just worked, and I had a running app with a text input and a submit button that allows the user to run arbitrary python code. Not exactly what I meant when I said “a Rust backend that can call custom Python code”, but good enough anyway.

Even though it was quite a hassle to get everything running, it felt quite magical. This is how the legendary Andrej Karpathy (student under Geoff Hinton, founding member of OpenAI and head of Tesla AI) describes it:

I just see stuff, say stuff, run stuff and copy paste stuff, and it mostly works.

Is that the future of building software products? Maybe.

Final Judgment

The biggest issue with AI agents is probably their missing knowledge of anything recent (especially libraries) and their inability to produce non-text assets. I really advise you to check your dependencies or set them in the beginning when working with AI coding tools.

I’ll definitely spend the next few weeks using Trae as much as possible until it eventually becomes paid just like every other AI coding tool.

However, make no mistake. Not a single word in this article is AI-generated. If you like and respect my work or found any useful insights in this article, please leave a clap. Also, check out my other articles. There is probably something you will enjoy ; )

Signing Out,

Rashid Harvey

Using Agentic AI Code Editors was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Christmas Math — Secret Santa

Christmas is the perfect time to think about tricky math problems in the cozy embrace of your home, looking into the vast gray of the sky.

The particular problem presented in this article is inspired by a real Christmas tradition: Secret Santa (or “Wichteln” in Germany). Out of n people, every person gets assigned one other person whom they have to gift something for Christmas, so that everyone gets a gift. The question is: How likely is it that two people are assigned to another?

Let’s do some examples:

• For 2 people, the answer is 100%: They must be assigned to each other
• For 3 people, it’s the exact opposite. If two people were assigned to each other, the third would be left out.
• For 4 people, the question becomes a bit more difficult, but is still manageable with some basic knowledge of combinatorics: First, 1 picks 2. Now, 2 has a likelihood of 1/3 to pick 1, which results in two pairs, and a likelihood of 2/3 to pick 3 which results in a full cycle.

Can we come up with a general formula for the probability of two people being assigned to each other? Does the probability decrease, increase, or diverge around a value when adding more people?

To find the probability P, we can divide Aₚₐᵢᵣ, the number of configurations that contain a pair, by A, the total number of all possible configuration.

Simulation

When solving math problems like this, writing some code to simulate the problem can be a good first approach to understand the problem better and avoid tedious manual work.

from functools import cache
from itertools import chain

@cache
def _simulation(n1, n2):
    if not n1:
        return (tuple(),)
    return [
        *chain.from_iterable(
            [
                [(x1,x2),*result] for result in _simulation(
                    n1[1:], n2[:i]+n2[i+1:]
                )
            ] for i,x2 in enumerate((n2)) if (x1:=n1[0]) != x2
        )
    ]

def simulation(n):
    return _simulation(
        tuple(range(1,n+1)), tuple(range(1, n+1))
    )

This simulation creates all possible gifting constellations for n people. @cache is a trade-off between memory and speed. The code runs faster, but requires more memory.

This was the result for n=1 to n=4:

[]
[[(1, 2), (2, 1)]]
[[(1, 2), (2, 3), (3, 1)], [(1, 3), (2, 1), (3, 2)]]
[[(1, 2), (2, 1), (3, 4), (4, 3)],
 [(1, 2), (2, 3), (3, 4), (4, 1)],
 [(1, 2), (2, 4), (3, 1), (4, 3)],
 [(1, 3), (2, 1), (3, 4), (4, 2)],
 [(1, 3), (2, 4), (3, 1), (4, 2)],
 [(1, 3), (2, 4), (3, 2), (4, 1)],
 [(1, 4), (2, 1), (3, 2), (4, 3)],
 [(1, 4), (2, 3), (3, 1), (4, 2)],
 [(1, 4), (2, 3), (3, 2), (4, 1)]]

We can see that for n=4, there are 9 possibilities, 3 of which contain two pairs: the first, the fourth, and the ninth. This confirms our prediction from before. The probability is 3/9 = 1/3.

For higher values of n, the list becomes exponentially larger, and so I only printed the totals A and the computation time:

1       : 0 in 0.0 s
2       : 1 in 0.0 s
3       : 2 in 0.0 s
4       : 9 in 0.0 s
5       : 44 in 0.0 s
6       : 265 in 0.0 s
7       : 1854 in 0.0026404857635498047 s
8       : 14833 in 0.03130531311035156 s
9       : 133496 in 0.4279468059539795 s
10      : 1334961 in 5.012750625610352 s
11      : 14684570 in 80.85578060150146 s

For n=12 the computation time was in the tens of minutes until the program crashed with a MemoryError.

After a closer inspection of the results above, I noticed that the values for A were actually growing faster than any constant polynomial nᵃ or exponential aⁿ. Instead, they were growing almost like n! ∈ O(nⁿ):

This formula becomes most clear when looking at n=10 where the value literally just got a 1 appended in the decimal system. But it also holds for all other values, as you can assure yourself.

For comparison, I plotted nⁿ (red), n! (blue), and the data points (green) from the simulation on a logarithmic scale.

We see that the green data points align pretty closely to n!. For further analysis, it might make sense to approximate accordingly: A = b·n!; b∈ ℝ.

For example, if we approximate and write aₙ as this explicit form

and further assume n is even, we can split the odd and even terms with a surprising result.

Now let’s find Aₚₐᵢᵣ the number of constellations with a pair. Here I printed Aₚₐᵢᵣ/A=P for n up to 11.

2       :  1 / 1 = 1.0
3       :  0 / 2 = 0.0
4       :  3 / 9 = 0.3333333333333333
5       :  20 / 44 = 0.45454545454545453
6       :  105 / 265 = 0.39622641509433965
7       :  714 / 1854 = 0.3851132686084142
8       :  5845 / 14833 = 0.39405379896177445
9       :  52632 / 133496 = 0.39425900401510156
10      :  525105 / 1334961 = 0.39334856973349785
11      :  5777090 / 14684570 = 0.39341226879643054

Although, there is no pattern immediately visible for Aₚₐᵢᵣ, the resulting fraction is already starting to close in on 0.393… at these fairly low values of n. Even without proof, we can already pretty confidently say that for higher values of n the probability will not change dramatically and stay somewhere around 39%. But let’s dive a bit deeper.

A more thorough mathematical analysis

The total combinations for a number n can be found by looking at all the combinations with one less person, and then inserting the nth person after every other person. This accounts for aₙ₋₁· (n-1) combinations.

n=3:
for [(1, 2), (2, 1)]
  insert 3 after 2: [(1, 2), (2, 3), (3, 1)]
  insert 3 after 1: [(1, 3), (2, 1), (3, 2)]
-> a_{n-1}*(n-1) = 1*2 = 2

n=4:
for [(1, 2), (2, 3), (3, 1)]
  1: [(1, 4), (2, 3), (3, 1), (4, 2)]
  2: [(1, 2), (2, 4), (3, 1), (4, 3)]
  3: [(1, 2), (2, 3), (3, 4), (4, 1)]
for [(1, 3), (2, 1), (3, 2)]
  1: [(1, 4), (2, 1), (3, 2), (4, 3)]
  2: [(1, 3), (2, 4), (3, 2), (4, 1)]
  3: [(1, 3), (2, 1), (3, 4), (4, 2)]
-> a_{n-1}*(n-1) = 2*3 = 6

But we are still missing some combinations where we introduce new pairs which are the combinations of aₙ₋₂ and n-1:

n=4:
for [(1, 2), (2, 1)]:
  1: [(1, 4), (2, 3), (3, 2), (4, 1)]
  2: [(1, 2), (2, 1), (3, 4), (4, 3)]
  3: [(1, 3), (2, 4), (3, 1), (4, 2)]
-> a_{n-2}*(n-1) = 1*3 = 3

If we put this together, we find the original formula, but also another formulation that reminds of the Fibonacci series (the Fibonacci series has an explicit formula, can we find one here as well?).

Now for the tricky part: To solve this problem, let’s consider any constellation C of n people to consist of k sets with a might of at least 2. More generally: “with a might of at least m.” We can redefine P in this way:

Unfortunately, I was not able to further break this down purely mathematically. Do you have an idea?

However, using this code from Stack Overflow to generate the permutations, I made a little script that comes farther than the first one, but still not nearly as far as I would like. This is because generating all possible partitions is quite tedious work (n!), and Python is not the best to do this kind of work.

def get_prob(n):
    lst = list(range(1, n+1))
    a2 = [*series(n)][-1] # the series we defined earlier
    s3 = get_partitions(lst, 3)
    a3 = sum(
        math.prod(
            fact(len(c)-1) for c in part
        ) for part in s3
    )
    print(n, ":", a2-a3, "/", a2, "->", (a2-a3)/a2)

Here is the result for n up to 16

3 : 0 / 2 -> 0.0
4 : 3 / 9 -> 0.3333333333333333
5 : 20 / 44 -> 0.45454545454545453
6 : 105 / 265 -> 0.39622641509433965
7 : 714 / 1854 -> 0.3851132686084142
8 : 5845 / 14833 -> 0.39405379896177445
9 : 52632 / 133496 -> 0.39425900401510156
10 : 525105 / 1334961 -> 0.39334856973349785
11 : 5777090 / 14684570 -> 0.39341226879643054
12 : 71555121 / 176214841 -> 0.40606750597130464
13 : 901364100 / 2290792932 -> 0.3934725340771219
14 : 12618959353 / 32071101049 -> 0.3934682296600936
15 : 189284859750 / 481066515734 -> 0.393469205523884
16 : 3069424181265 / 7697064251745 -> 0.39877855775585236

The absolute numbers are actually getting ridiculous. Further analysis would have to reduce the problem and find some kind of formula for A₃, like the one we found for A₂.

So to answer the question: When doing Secret Santa, for a medium-sized group (6–16), the chance that at least two people will prepare a gift for each other is approximately 2/5. Most likely, this is also true for larger groups.

I hope you had some fun and could follow. If not, feel free to ask for clarification. If yes, leave some feedback. Did you find a better or a different solution? Do you know of more resources regarding the topic? Share your thoughts.

The LaTeX renders were made using quicklatex.com. Give it a try!

Signing out,

Rashid Harvey

PS: Find out a better way for comparing sets, or why all numbers are imaginary.

Secret Santa (A Christmas Math Problem) was originally published in IntuitionMath on Medium, where people are continuing the conversation by highlighting and responding to this story.

Rust is a programming language with a very minimal standard (std) library. This is by design to make the programming language as light-weight as possible. However, this also means that you will need to install external libraries (called crates) for most projects. But at least it is very simple to install crates because Rust, in contrast to C for example, has a dedicated crate manager (cargo) that does most of the work for you. Another cool thing is that the Rust ecosystem is very focused on providing one good crate for each use case. In most ecosystems, you will see that there are several competing packages that essentially do the same thing/solve the same problem (JavaScript is famous for this). In Rust, however, there is mostly exactly one crate that you are looking for and that all sources will point you towards. Which is very relieving as you never have to make decisions on which crates to use, when it probably doesn’t make a difference anyway. Also, this makes it so that these crates essentially become an extended standard library.

In this article, I want to show you a few of those crates and introduce them shortly, which you will likely need to build your next Rust project. I also often fell into the trap of trying to reinvent the wheel. Maybe I can save you from making the same mistakes with this comprehensive article.

Random

Almost every language in the world has support for rudimentary random number generation (RNG) built-in. Rust is an exception. To generate (pseudo)random numbers, you should use the rand crate. To add it to your project, you can simply run cargo add rand in your command line. This is the same for all the crates I am going to show you here.

You can then use it to generate numbers, distributions, and even cryptographically secure random values. For example, to generate a random number from 1 to 10 as a CLI application, you can do this:

use rand::Rng;

fn main() {
    let mut range = rand::thread_rng();
    println!("{}", range.gen_range(1..=10));
}

Lazy statics

In Rust, there are four kinds of variables. There are compile-time constants: const, run-time constants: static, immutable values (default): let, and finally there are mutable values: let mut. Sometimes you want to have static variables that are only initialized at run-time. This is however not possible by default, because even though static variables are only run-time constants, they must be known at compile-time.

However, when dealing with the operating system (opening files, starting threads or opening network ports, etc.) for example, it is necessary to create these static variables during the run-time. Ideally at the start of the program are at least before they are used the first time. These lazy statics are virtually staticvariables that are automatically initialized when they are accessed the very first time:

lazy_static is one of the foundational crates in the Rust ecosystem.
It lets us use static variables without an explicit initialization call.

— Max on dev.to

Regex

Let’s see an example use case: Compiling a regular expression (regex). Theoretically, a regex should be compiled at compile-time, duh! However, afaik there is currently no stable implementation. Instead, the regex needs to be compiled during run-time. To still use the benefits of static variables, like global access from anywhere, we can use lazy_static in combination with the regex crate. If you don’t know how regular expressions work or want to learn more, regexr.com is a good place to go. In this example, we use a regular expression for YYYY-MM-DD dates.

With lazy_static! we can set up our lazy statics. Regex::new() compiles a given string into a regular expression. Finally, we can use our expression to match a given date object.

use lazy_static::lazy_static;
use regex::Regex;

lazy_static! {
    /// This is the static regex
    static ref EXPR: Regex = Regex::new(r"^\d{4}-\d{2}-\d{2}$").unwrap();
}

fn main() {
    let date = "2021-01-01";
    if EXPR.is_match(date) {
        println!("{} is a valid date", date);
    } else {
        println!("{} is not a valid date", date);
    }
}

Error handling

In Rust, errors are return values and there exists simple syntax to propagate errors.

Here is an example. Error1 and Error2 are custom errors. Our functions raise_error1() and raise_error2() return these errors with a Result return type. It either contains the actual value or the error type. In combine_errors() we propagate both errors using the ?. This will return any error in the outer scope immediately, or pass on the result value if there is no error.

struct Error1;
struct Error2;

fn raise_error1() -> Result<(), Error1> {
    Ok(())
}

fn raise_error2() -> Result<(), Error2> {
    Ok(())
}

fn combine_errors() {
    raise_error1()?;
    raise_error2()?;
    Ok(())
}

You might have noticed that I didn’t add a type for combine_errors() because it is ambiguous. Instead, we would need to use a dynamic Box as shown in the Rust-by-example book. However, an even easier approach is to use the rust crate anyhow. Install anyhow by running cargo add anyhow in your CLI. You do need to implement std::fmt::Display and std::error::Error to use it, but that is pretty straightforward and not necessary when you don’t use custom errors.

#[derive(Debug)]
struct Error1;
#[derive(Debug)]
struct Error2;

impl std::fmt::Display for Error1 {
    fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
        write!(f, "Error1")
    }
}

impl std::fmt::Display for Error2 {
    fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
        write!(f, "Error2")
    }
}

impl std::error::Error for Error1 {}
impl std::error::Error for Error2 {}

fn raise_error1() -> Result<(), Error1> {
    Err(Error1)
}

fn raise_error2() -> Result<(), Error2> {
    Err(Error2)
}

fn combine_errors() -> anyhow::Result<()> {
    raise_error1()?;
    raise_error2()?;
    Ok(())
}

I would also love to refer you to this blog post by AntoineRR where he introduces the topic just like me, but then also goes into more detail into how you can create your own anyhow errors.

Parsing

Parsing has always been an unreasonably difficult task in statically-typed languages. However, there is one ubiquitous module that makes parsing in Rust easy-peasy: Serde. I will let it speak for itself:

Serde is a framework for serializing and deserializing Rust data structures efficiently and generically.

The Serde ecosystem consists of data structures that know how to serialize and deserialize themselves along with data formats that know how to serialize and deserialize other things. Serde provides the layer by which these two groups interact with each other, allowing any supported data structure to be serialized and deserialized using any supported data format.

— Serde documentation

However, most of the time, you will use a derived package that can serialize and deserialize a specific data format, like the very popular JSON. The corresponding crate is serde_json. Install it with, you guessed it, cargo add serde_json. But we will also need serde: cargo add serde --features serde_derive. With everything set up, let’s implement a simple program.

The JSON file looks like this

{
  "value": 0
}

The program tries to read this file. If it doesn’t exist, the program will assume a default. Then we increment the value and write the JSON back to the file. If the JSON doesn’t fit our requirements, we can simply raise an error using anyhow.

use anyhow::{Result, anyhow};
use serde_json::{from_str, to_string, Value};

fn main() -> Result<()> {
    const FILE: &str = "data.json";
    let contents = std::fs::read_to_string(FILE)
        .unwrap_or("{\"value\": 0}".to_string());

    let mut data: Value = from_str(&contents)?;

    let error = Err(anyhow!("Unexpected json")); 

    match data {
        Value::Object(ref mut map) => {
            if let Some(Value::Number(value)) = map.get("value") {
                if let Some(number) = value.as_i64() {
                    map.insert("value".into(), (number + 1).into());
                    std::fs::write(
                        FILE,
                        to_string(&data).unwrap(),
                    )?;
                    return Ok(());
                }
            }
            return error
        }
        _ => error,
    }
}

anyhow makes this so much easier by allowing us to freely return different types of errors, and even custom errors. This code works perfectly fine and increments the value reliably and extremely fast (<20ms).

{"value":7};

When I give it an incorrectly formatted file like the above, for example, it gives me the error:

Error: trailing characters at line 1 column 12

When there is a different error, it returns the Error: Unexpected JSON we specified above. We could make this error message even more informative, but this isn’t necessary for now.

However, you might think this is quite a lot of code just to increment a value in JSON, and you are right. There is a much better, more declarative, way. This is Rust, a statically-typed language with extremely powerful macros, that we will make use of by defining a strict statically-typed interface which makes both the code and the errors much more readable:

use anyhow::Result;
use serde::{Deserialize, Serialize};
use serde_json::{from_str, to_string};

#[derive(Serialize, Deserialize)]
struct JSON {
    value: i32
}

fn main() -> Result<()> {
    const FILE: &str = "data.json";
    let contents = std::fs::read_to_string(FILE)
        .unwrap_or("{\"value\": 0}".to_string());

    let mut json: JSON = from_str(&contents)?;

    json.value += 1;

    std::fs::write(FILE, to_string(&json)?)?;

    Ok(())
}

We use the JSON struct to tell serde how we expect our data to look like. Then serde_json has an easy time to convert the JSON, so that we can increment the value field and then convert it back. The errors are also much more helpful:

{“valu”:24}

Error: missing field ‘value’ at line 1 column 11

{"value":""}

Error: invalid type: string “”, expected i32 at line 1 column 11

So you have seen how serde, serde_json and anyhow can make your life parsing JSON much easier by providing concise, declarative APIs and simple error handling.

Async

If you want an introduction to async in Rust, I would recommend the free and open-source Asynchronous Programming in Rust book.

Even though Rust supports syntax for async, it does not provide anything to actually run asynchronous code at all. The real work is left to constantly evolving community crates, like tokio. Tokio is the crate to use when you need an asynchronous run-time in Rust. For this example, you should install it with all features enabled: cargo add tokio --features=full

HTTP client

This is where most other standard libraries stop as well, and here we can also observe many similar library implementations. However, a good starting point is reqwest. Which is a feature-full library that supports asynchronous and synchronous HTTP fetching. In our example, we will try to request two different resources simultaneously. To do that, we use a join, which is provided by tokio. It also enables us to have an async main function, which is very handy.

#[tokio::main]
async fn main() {
    let fut1 = reqwest::get("https://www.rust-lang.org");
    let fut2 = reqwest::get("https://tokio.rs/tokio/tutorial/hello-tokio");
    match tokio::join!(fut1, fut2) {
        (Ok(resp1), Ok(resp2)) => {
            println!("Rust lang: {:#?}", resp1.status());
            println!("Tokio: {:#?}", resp2.status());
        }
        _ => println!("There was an error")
    }
}

This will get https://www.rust-lang.org and https://tokio.rs/tokio/tutorial/hello-tokio at the same time and tell us whether the requests were successful. The result should be:

Rust lang: 200
Tokio: 200

I hope this short article helped you. If you have any further questions or remarks, please leave a comment or visit the package documentation.

So the 7 Rust crates you will probably need in Rust are:

1. Random
2. Lazy static
3. Regex
4. Anyhow
5. Serde
6. Tokio
7. Reqwest (or a different HTTP client)

If you have any must-have crates I forgot, add them in the comments. Also, if you have any questions, don’t hesitate to ask. All the code can also be found on GitHub with quick-install instructions.

Signing out,

Rashid Harvey

Inheritance got a lot of hits recently. Many say that interfaces, or protocols as they are called in Python, are just better: Composition over inheritance, they say. In this article, I want to show you how you can write enjoyable code using inheritance that triumphs over composition.

As an example, let’s start with code that expects any object that can be drawn. That means it has a draw method that expects a surface and a rectangle and draws something to the surface in the given bounds. This seems like a perfect job for a protocol. In the following code samples, I am making up some types and methods and assuming they are provided. I am borrowing mostly from pygame, as I have used it a lot, especially most recently.

from typing import Protocol

class Drawable(Protocol):
  def draw(self, surface: Surface, rect: Rect):
    ...

def my_code(drawable: Drawable):
  """ Do something cool here """

And our job is done. This looks perfect! Now, any static type checker will ring alarm bells if anyone even tries to pass something that is not a drawable. But, anything that is drawable works fine. We could for example make a drawable color.

class DrawableColor:
  def __init__(self, color: Color):
    self.color = color

  def draw(self, surface: Surface, rect: Rect):
    draw_rect(surface, self.color, rect)

my_code(DrawableColor("red"))

If this is so awesome, why use inheritance?

Well, I’ll show you. Instead of using protocols, we will use an inheritable object as a type.

class Drawable:
  def draw(self, surface: Surface, rect: Rect):
    ...

def my_code(drawable: Drawable):
  """ Do something equally cool here """

Now, you might ask yourself why this is better. Don’t I just need to add more code to every drawable class?

from _ import Drawable

class DrawableColor(Drawable):
  def __init__(self, color: Color):
    self.color = color

  def draw(self, surface: Surface, rect: Rect):
    draw_rect(surface, self.color, rect)

my_code(DrawableColor("red"))

Well yes, but the upsides are only coming

Supplying extending methods

Due to our careful construction, we can now easily add extending methods to all Drawables by simply adding that method to the Drawable class. For this example, we might want to add a method for creating a new surface from the drawable given a size.

class Drawable:
  def draw(self, surface: Surface, rect: Rect):
    ...

  def to_surface(self, size: tuple[int, int])->Surface:
    surf = Surface(size)
    self.draw(surf, Rect((0,0), size))
    return surf

This code now gives every Drawable anywhere this method. But they can also override the method if the default implementation is not desirable!

Of course, there could be collisions theoretically, if some drawable already implemented its own to_surface method for a different use before adding the extending behaviour. So theoretically it’s a breaking change. But in most cases, it’s unlikely. Also, I am assuming you are developing small libraries quickly and have an overview over most inheritors. If you are using SemVer and Drawable is part of your public API, you should theoretically bump your major version nonetheless when adding such a functionality after 0.y.z.

A new concept: Creating a default base object

Well, instead of just extending the functionality of our class, we can also supply a default implementation in our base class. This has several advantages:

1. When you inherit the base class, everything is already set up. You can then implement every method piece by piece
2. When implementing the methods, you can look into the default implementation for reference on what a method is supposed to do, additionally to the documentation.

To elaborate, let’s assume your protocol/base class has n methods that must be implemented. Using a protocol, every single method needs to be implemented correctly before you can run the code or make a commit, etc. This is very limiting, especially when n ⇒ ∞ or if you have no clue about a good implementation for certain functions that perhaps you know will never actually be called in your specific circumstances.

I want to give you a last example and then wrap this up: a Stream that you can send data to.

from typing import Self

class Stream:
  def send(self, item)->Self:
    print(item)
    return Self

def my_code(stream: Stream):
  stream.send("Hello, ")
  stream.send("World!")

Now you can build your own Stream piece by piece. You don’t need to implement all the methods yourself (in this example it’s only 1 thankfully) or any method at all:

class MyStream(Stream):
  ...

my_code(MyStream())

The above works just as well as the fully implemented version (which would have been required to work with a Protocol):

class MyStream(Stream):
  def __init__(self, file: Pyth):
    self.file = open(file, "a")

  # Here we see another advantage, 
  # you can leave out the explicit type annotations
  def send(self, item):
    self.file.write(str(item))
    return self
  
  def __del__(self):
    # I know this isn't the most beautiful code
    self.file.close()

my_code(MyStream("out.txt"))

The only issue with this approach is really only the __init__ function. If your default implementation needs an __init__ function with parameters to work, then that could be a problem because your inheritors are then not totally free to do their own thing. So, you should refrain from that by either writing a custom init function (not a method) or hard-coding any parameters.

In this article, you have learned why inheritance can often be better than protocols when you focus on implementing things rapidly.

1. The difference in code is minimal
2. You can easily extend the functionality of your objects in one place with minimal risk and the possibility to override the default
3. You can treat the base class as a reference implementation, which allows you to code incrementally.
4. Quality of life changes: Less explicit typing and more auto-completion

I hope this made sense to you, and thanks a lot for reading so far. Please tell me what you think about the examples given or the topic inheritance in general. Also, if you learned something new, clap for the article. My mission is to inspire my readers to discover new ideas.

Signing Out,

Rashid Harvey

The simplest case

The simplest case is where the ball is thrown from the ground and lands on the same even ground. Then there are two important equations we need to find the optimal angle. The first gives us the x-position of our ball as a function of time. The second gives us the y-position also as a function of time:

I x = vx*t

II y = vy*t - ½gt²

Where vx and vy are the horizontal and vertical starting velocities of the ball, t is the time and g is the earths constant of gravitation which is generally set to 9.81 m/s² though it depends on the location on earth. We assume that the starting velocity of our ball is independent of the angle. So we are ignoring all anatomical factors. At least for me, those are big mysteries anyway.

We want to know how far the ball has travelled when it touches the ground. Therefore, we set y to 0, and additionally we will replace vy and vx with the starting velocity v and the starting angle a using simple trigonometry:

I vx = v * cos a

II vy = v * sin a

0 = v sin a * t — ½gt² generally has two solutions: t = 0 and t = 2v sin a / g. However, the first solution is not interesting to us because this is at the exact moment the ball leaves the ground. Instead, we need the second solution when the ball hits the ground after flying through the air.

For simplicity, I will replace sin a with s and cos a with c.

When we substitute t into I, we get x = 2v²sc/g (or alternatively, x = v²sin(2a)/g). To get the angle that maximizes x we need to find the angle where x’ = 0. To get to the exciting part, I will skip the rest and link this answer on Quora.

Throwing the ball a bit better

Now we want to step up our game and throw a bit farther. For example, we could maybe start throwing from above the ground? But for that, we also need to step up our physics game a bit. To begin with, we need to add a starting height h to our second equation.

II y = h+vy*t — ½gt²

Again, we set y to 0. Afterward, we move all t terms to one side and then complete the square to solve for t:

Now we use the binomial, take the square root and move over vy/g

Now we put that into I:

And there we have a formula for x. We can now plot this given some g, h and v:

We immediately notice some things. The curve isn’t really symmetrical anymore. Before, the distance at 30° was the same distance as at 60°, for example. Now, the curve is skewed towards smaller degrees. And while you can’t read the maximum exactly, it looks like it’s less than 45°=π/4. To find the maximum exactly, we equal the differential to 0 again: x’ = 0.

To start, we pull out v/g right at the beginning and apply all the differential rules we learned in analysis:

Now we multiply with the root term to isolate the root to one addend, then we move that to the other side and square the whole equation. On the way, we also replace cos(a)² with 1-sin(a)² and sin(a)² with r:

This looks quite complicated, but bear with me because all of this collapses piece by piece to:

Resubstitute:

Just for fun, let’s try h = 0:

That worked really well 🥳. We didn’t just find the general solution, we also witnessed extremely complicated and long equations and terms (I spared you from most of it) simplifying into such a concise formula, which feels quite awesome.

Thanks for staying with me on this adventurous ride, and maybe we’ll learn about the effect of air resistance in the next article.

Please leave me a comment on how you found the article, what you understood, what you didn’t and what I could improve.

Signing Out,

Rashid Harvey

I’ve prepared an example in CodePen. It’s very simple code that lets an ::after element with an x appear in a .dismissable when it's :hovered.

CodePen Embed - Clickable pseudo-element

Now the hard part is making it clickable. You can’t really select the pseudo-element, and it also doesn’t appear in the click event when listening to a click event on the .dismissable.

Naturally, I turned to the internet and stumbled onto exactly the question I had: “jquery detect ::after css selector click event.” This question is a prime example of how bad SO actually is, and the situation depresses me a lot, to the point that I don’t ask any questions anymore. The question was closed as a duplicate, even though the referenced question is absolutely different.

Neither the original question nor the referenced question had any answers that were able to solve my problem. I still liked both the original question and the single answer, as they could be valuable to others, and I wanted to show those people some love for their time and effort.

Detecting that the pseudo-element was clicked

So now let's get to the real stuff. The essential idea is a mixture of two ideas.

1. Get the attributes of the pseudo-element with getComputedStyle
2. Check the mouse position relative to the pseudo-element

We can get the pseudo-elements style with getComputedStyle(elem, ":after") this is extremely useful in our situation.

With .getPropertyValue we can then get the computed values of top, height, left and width, which allow us to delimit the pseudo-element. Importantly, the computed values are just strings that look like {num}px. To get just the number, we slice off the last two characters and then parse the strings as Numbers.

We get the mouse positions relative to the .dismissable by accessing the layerX and layerY attributes.

The final step is a simple bounds check. If it is successful, we can do whatever we desire. In this case, I made the .dismissable simply disappear by setting its display attribute to "none", but normally you might want to do different things as well.

const handler = (e)=>{
  // First we get the pseudo-elements style
  const target = e.currentTarget || e.target
  const after = getComputedStyle(target, ":after")
  if (after) {
    // Then we parse out the dimensions
    const atop = Number(after.getPropertyValue("top").slice(0, -2))
    const aheight = Number(after.getPropertyValue("height").slice(0, -2))
    const aleft = Number(after.getPropertyValue("left").slice(0, -2))
    const awidth = Number(after.getPropertyValue("width").slice(0, -2))
    // And get the mouse position
    const ex = e.layerX
    const ey = e.layerY
    // Finally we do a bounds check (Is the mouse inside of the after element)
    if (ex > aleft && ex < aleft+awidth && ey > atop && ey < atop+aheight) {
      console.log("Button clicked")
      target.style.display = "none"
    }
  }
}

Again, try this out in the CodePen and have fun:

CodePen Embed - Clickable pseudo-element

Signing Out,

Rashid Harvey