These are some of my short-form thoughts, observations, and quick takes on various topics. Anything that's not too big to be a post but less ephemeral than a tweet would go here.

Everyone knows that LLMs are inherently non-deterministic and harnesses, MCPs, RAG, skills etc. all try to paper over this.

But this non-determinism is a feature. And the developer community is slowly beginning to embrace it. This was well elucidated by Martin Fowler on his recent podcast on The Pragrammatic Engineer. He akins this to the field of mechanical engineering with engineers building tolerances into what a structure can withstand.

Computer Science Engineers actually have an example closer to home. Not too long ago, Google ushered us all in with the MapReduce paper and the core of this architecture was GFS which inherently assumes that all underlying hardware components are unreliable. And this has prompted the industry to build strategies like replication, fault-tolerance, SRE practices around the fact that systems are fallible.

Perhaps, our industry can consider this as a watershed moment before the mother of all uncertainties becomes more mainstream - Quantum Computing.

Every interaction with the LLM to generate tokens requires subsequent prompting for tweaking. One-shot is doable but is it efficient?

Consider this - you want to generate a blog with multiple pages and you prompt your way through over time. And unless you, the prompter are prudent about reducing code-duplication, the LLM will always tend to duplicate code.

It’s very likely that LLMs of today don’t have anything in their system prompts to optimize towards code-dedupe. This also is hard owing to limited context windows.

In a world where LLMs are aware of tokenomics, even with the right system prompts, will they naturally tend to deduplication? A smart LLM that tries to optimize for the revenue of its maker is more incentivized to generate more tokens, thus favoring more duplication.

This tweet from Andrej Karpathy has been doing the rounds and I felt this quoted tweet from rahulgs was on-point based on my experience working with LLMs. The frontier is moving quickly for writing code at the least and the more harnesses and tools you provide for your engineer and the more context you provide your models, the better it is going to get over time.

Security is still an very important and sadly overlooked part at this point.

Of course, everyone is talking about this tweet by Andrej. I do feel this at times - there’s just a lot to keep up and honestly the best way I’m making progress is learning a thing or two every day and accepting that I can’t be knowing everything in one-go and trusting my future self to figure it out.

Having a bunch of pet-projects/problems to work on and putting these tools to use to work on these helps over time.

I’m proud to admit that I’m bitten by the Rich Hickey bug. As many in reddit convey, I strarted watching a video or two during my commute to work and a lot of things made so much sense that I decided to give Clojure a try. Of course, I’m not at the level where I want to run my fingers in Rich’s Bob Ross like hair. :P

What are my first impressions? There are many positives already about Clojure. I’m not a Lisp aficionado and have always despised the need for many many parentheses in a program. But Clojure, although it has a healthy dose of parentheses is different from Lisps in many regards. It’s much more simpler and consistent that Common Lisp, I’ve heard.

But the striking feature of Clojure for me so far is Programming to Abstractions. Most OO programs and C programs do not program for abstractions but to implementations. Java took a different spin on it by introducing interfaces that lets one focus on programming to conform to certain interfaces. That gave us the extremely rich and elaborate Collections library of Java. Clojure takes it to the next level since it creates intermediary structures of a certain type (say seq) and completely relies on abstractions.

Python programmers have a different name for this. I believe it originated from the Ruby world - Duck Typing. Duck Typing dictates that if something can quack, it’s a duck. Of course, IRL this is a blatant lie. I can quack too but I’m not a duck. A car has a steering wheel but it’s not a cruise boat or vice versa. While this appears to be an issue, it’s not that big a deal in an environment that strongly promotes writing small composable libraries.