A Few Good Ideas in Programming Languages

2026-05-10T00:00:00+00:00

Here are just a few programming language features I love:

1. Flow Typing</h1>

A great idea that I first encountered in Crystal</a>, is the idea of flow typing.

Crystal is a compiled programming langauge with static type-checking with syntax very similar to the Ruby programming language</a>. Something that keeps Crystal feeling like a dynamically typed language is how a variable can be assigned to multiple types throughout the course of its lifetime, unlike most statically typed languages I've used. Here is an example:

my_var </span>= </span>5
</span>
</span># my_var's type here is Int32
</span>assert(my_var.is_a?(</span>Int32</span>))
</span>
</span>if</span> some_complex_condition()
</span>  my_var </span>= </span>"hello!"
</span>
</span>  # my_var's type here is String
</span>  assert(my_var.is_a?(</span>String</span>))
</span>end
</span>
</span># What is my_var's type here?
</span>#
</span># It's Int32 | String
</span>assert(my_var.is_a?(</span>Int32 </span>| </span>String</span>))
</span></code></pre>
What's most interesting about this is that there is some time when my_var</code> is just a Int32</code>, there is a region where it is guaranteed to be a String</code> and then there is a region where the compiler cannot actually guarantee one or the other... so its type is the union of all the possibilities. Now if you try to run a String</code> method on my_var</code>, it'll fail because its not a String</code>, its a Int32 | String</code> and the compiler will force you to add a check like if my_var.is_a?(String)</code> which narrows</em> the possible types to just a String</code>.</p>
This is a great example of using fancy type inference to make a compiled language feel</em> dynamic without paying much of a runtime penalty.</p>
Typescript also has flow typing</a> and type narrowing</a>!</p>
2. Borrow Checking</h1>
Rust</a> is a systems programming language which guarantees memory safety without a garbage collector.</p>
One large class of memory safety bugs in concurrent programs is the loathsome data race: when multiple threads read and write the same memory location simultaneously without synchronization.</p>
The borrow checker is how Rust is able to statically prevent data races at compile-time. It enforces the following rules</a>:</p>

Any borrow must not out-live the scope of the owner</li>
You can EITHER have:

exactly 1 mutable reference (&mut T</code>)</li>
OR 1 or more immutable references (&T</code>)</li>
</ul>
</li>
</ul>
This might remind you of a readers-writer lock</a> which is a lock which allows many readers OR a singular writer. This is because to prevent data races, we only need to synchronize reads with respect to writes. The point of concurrent synchronization is to serialize the writes to a given memory location.</p>
I love the borrow checker because it is such an elegant solution to the problem of data races and are a zero-cost abstraction which only comes at the cost of compile-time checks and added complexity. Added complexity is a real tradeoff but if you are writing concurrent programs, this complexity is inherent to the subject matter.</p>
3. Contract Programming</h1>
If you've programmed much, you've probably come across the humble assert statement, which is used to error / report if a given invariant isn't upheld. Every program has invariants that it needs to uphold. Things like "this date is always past this other date" or "this tree is always balanced."</p>
The D programming language</a> (such an underrated language) supports contract programming</a> where it provides syntactic support for describing more complex invariants which can be at the function-level or object-level.</p>
D has standard assert statements:</p>
double </span>always_positive </span>= </span>100</span>;
</span>assert</span>(</span>always_positive </span>> </span>0</span>);
</span></code></pre>
But D also has enforce</code> which is used to mark a difference in semantics. Asserts are used for program invariant violations. If an assert is triggered, this should indicate a correctness bug in our program. enforce</code> instead throws an exception due to some external issue: something like a user input out of bounds or environment issue.</p>
enforce</span>(</span>length </span>>= </span>7</span>, </span>"Must be at least 7."</span>);
</span></code></pre>
Additionally, D has syntactic support for pre- and post-conditions for functions.  Here's an example taken from Programming in D</a>:</p>
int </span>daysInFebruary</span>(</span>int </span>year</span>)
</span>out </span>(</span>result</span>) {
</span>    </span>assert</span>((</span>result </span>== </span>28</span>) </span>|| </span>(</span>result </span>== </span>29</span>));
</span>
</span>} </span>do </span>{
</span>    </span>return </span>isLeapYear</span>(</span>year</span>) </span>? </span>29 </span>: </span>28</span>;
</span>}
</span></code></pre>
Here the daysInFebruary</code> function has a post-condition which is that it should only ever return 28 or 29; everything else is definitely a logical error in the function.</p>
And finally, D has class-level invariants which are used to guarantee that object data is is always consistent. Here is a slightly more complex example tying everything together:</p>
class </span>BankAccount {
</span>    </span>private double </span>balance</span>;
</span>
</span>    </span>invariant</span>() {
</span>        </span>balance </span>>= </span>0; </span>// object-level invariant, always checked
</span>    }
</span>
</span>    </span>this</span>(</span>double </span>initialBalance</span>)
</span>    </span>in </span>(</span>initialBalance </span>>= </span>0, </span>"Initial balance cannot be negative"</span>)
</span>    {
</span>        </span>balance </span>= </span>initialBalance</span>;
</span>    }
</span>
</span>    </span>void </span>deposit</span>(</span>double </span>amount</span>)
</span>    </span>in  </span>(</span>amount </span>> </span>0, </span>"Deposit amount must be positive"</span>)
</span>    </span>out </span>(; </span>balance </span>== </span>balance </span>+ </span>amount</span>) </span>// checked after method returns
</span>    {
</span>        </span>balance </span>+= </span>amount</span>;
</span>    }
</span>
</span>    </span>void </span>withdraw</span>(</span>double </span>amount</span>)
</span>    </span>in  </span>(</span>amount </span>> </span>0,           </span>"Withdrawal amount must be positive"</span>)
</span>    </span>in  </span>(</span>amount </span><= </span>balance</span>,    </span>"Insufficient funds"</span>)
</span>    </span>out </span>(; </span>balance </span>>= </span>0,       </span>"Balance must remain non-negative"</span>)
</span>    {
</span>        </span>balance </span>-= </span>amount</span>;
</span>    }
</span>
</span>    </span>double </span>getBalance</span>()
</span>    </span>out </span>(</span>result</span>; </span>result </span>>= </span>0, </span>"Balance returned must be non-negative"</span>)
</span>    {
</span>        </span>return </span>balance</span>;
</span>    }
</span>}
</span></code></pre>
This invariant()</code> block is far cleaner and easier to maintain than having some consistency check function run at the beginning and end of every class method, and it has idomatic meaning.</p>
-- Pranoy</p>

AI Fear and Uncertainty 2026-04-12T00:00:00+00:00 "We mustn't be caught by surprise by our own advancing technology." -- Aldous Huxley </blockquote> But we often are. Technologies like the printing press, the radio, the television, the internet, and the smartphone have all outpaced any sort of institutional understanding or regulation. In many ways this has to be the case. At least in the US, this is how our governing institions were designed. And how do you go about regulating a technology you don't understand? This latest wave of AI is the next such technology which will outpace us, and we are not ready. I see disaster in the future. It's not hard to see. While the most vocal proponents of AI promise that it will be a technology which will revolutionize all work, automating away grudgery while at the same time curing all ailments, I fear that most people do not see it this way. If you see AI as a gift to humanity, we should take a step back and think about how AI has affected the majority of people. Say you are the average person: Maybe you've noticed that the internet you once knew is gone. That social media sites you visit are flooded with slop and bots. AI scrapers lead to sites you visit needing to put up migitations.</li> Maybe you've noticed that you have to be more on guard when viewing images and videos. Sure photoshop has been around for a while but you realize that AI has dropped the skill required to generate realistic looking media. You worry about how this will affect our politics.</li> Maybe you've noticed that almost every piece of software you use has annoying AI features shoved in your face. Maybe you've noticed that only a few of these features are actually any good.</li> Maybe you've noticed that the S&P 500 is more than 7% just NVIDIA. Maybe you worry about this so called "AI bubble." You worry about it popping.</li> Maybe you've noticed that our schools and universities aren't equipped to deal with ChatGPT powered cheating. Maybe you yourself are gen-AI-ing your way through school. Everyone else is doing it.</li> Maybe you've noticed that you are more worried at work. You worry that your boss thinks that AI can automate you away. Maybe you worry that your boss expects double the output because AI will magically make you much more productive. Your boss probably doesn't understand Amdahl's law.</li> Maybe you've noticed that you are worried about layoffs. Everyone's doing them now because of AI, right? If it's not AI, its probably AI spending.</li> Maybe you've noticed that deepfakes are a huge problem that we haven't addressed yet. Maybe you realize that AI has automated revenge porn.</li> </ul> Oh and yeah I guess it's nice that AI makes it easy to generate an email or something. People are not stupid. They realize that AI can lead to a great bifurcation. Even in tech circles people meme about "a permanent underclass." People worry that if AI succeeds, it will take away their jobs... and if it doesn't? If this "AI bubble" pops... They except to lose their jobs to a great recession. They expect to have their savings wiped out. People feel that our current configuration of society will lead to them not getting to really taste the fruits of AI. And when you fill a populous with fear, resentment, anger, uncertainty, and desperation... I wonder what happens. I'm not saying that all of this is true. I'm saying that it doesn't take much to read the room and see that this is the general sentiment. And these feelings matter. If you want AI to be successful, if you really think it will do all these great things, we'll have to change the configuration of society to assure people that they will benefit. What this means, I'm not sure. I think a stronger welfare state is necessary. -- Pranoy On Tony Hoare 2026-03-12T00:00:00+00:00 Every so often something happens that makes me remember that computer programming is a new thing. Something that makes me remember that we are still in the infancy of computing. That we don't really know what we are doing and we are still figuring it out. We can't boast the long histories of fields like math, medicine, or mechanics. Sir Tony Hoare's recent passing made me remember that. Computing is such a young field that many of our pioneers are still around.[^2] Hoare is an inspiration to me and I thought it would be nice to write a little about his many contributions to our young field. While Hoare was most known for Quicksort[^1], I want to cover some of his other work: Record Handling (structs, enums, null)</li> Monitor Synchronization</li> Floyd-Hoare Logic</li> Communicating Sequential Processes</li> </ul> Record Handling (1966)</h1> Hoare introduced the idea of "record structures" which are now just called structs. In this same essay, he introduces "record subclasses" which are akin to discriminated unions (think Rust enums). Finally, if that wasn't enough, he introduces the notion of a "null reference" which he calls his "billion dollar mistake." Anytime you get a NullPointerException? That's him too. Monitor Synchronization</h1> Hoare elaborated and popularized the Monitor concurrency primitive invented by Per Brinch Hansen. Monitors solve a common issue in concurrent programs: making threads (efficiently) wait for a condition to become true before continuing. Floyd-Hoare Logic</h1> In "An Axiomatic Basis for Computer Programming" (1969), Hoare develops a systematic method for reasoning about the meaning of computer programs. One of the key ideas of this logic is what is now known as a "Hoare triple": P {Q} R</code> where P</code> is a precondition, Q</code> is a program, and R</code> is a postcondition. If P</code> holds, then running Q</code> will lead to R</code> being true. With axioms and inference rules for imperative programming, you can write a proof about the behavior of programs which is exactly what modern verification languages like Dafny</a> and Verus</a> do! Communicating Sequential Processes (CSP)</h1> The core idea of CSP is modeling concurrent systems as a set of independent processes which do not share memory but instead communicate through "channels." Processes can send messages cross these channels, and other processes can recieve messages through them. You can see the echos of CSP's influence in languages like Erlang and Go. These are just some of Tony Hoare's most influencial ideas but I need to stop somewhere (and it's 1:40AM here so I should logoff...). Rest in peace. [^1] Rust</a> and C++</a> both include a "sort" algorithm which is a hybrid sorting algorithm which uses Quicksort for large arrays, and fallsback to heapsort and insertion sort for smaller arrays. The details vary from language to language but Quicksort is still state of the art! [^2] Alan Turing could've probably made it to the 1990s if the Brits weren't as homophobic. He would be 114 today. Configuration Languages Should be Strongly Typed 2026-03-05T00:00:00+00:00 Nothing in an undergraduate education in computer science prepared me for the amount of YAML I would have to stare at as a software engineer. Whether its to configure k8s, docker, CI, my eyes start to glaze over. The indentation guides on my favorite hipster IDE blend together as I try to figure out whether the snippet of config I copy-and-pasted from another codebase is correctly aligned. This sucks. Much of the infastructure that powers our world is build on a foundation of oceans of JSON and mountains of YAML. I think the configuration languages we use should be more like programming languages. In specific, they should have a strong type system with the ability to effectively convey constraints, and require schemas. Here's an example. server: port: "8080" # string or int? timeout: 30 # seconds? milliseconds? ssl: "yes" # bool? string? "yes"/"true"/1? max_connections: -1 # valid? sentinel for "unlimited"? log_level: "verbose" # what are the valid options? retries: 3.7 # fractional retries make no sense </code></pre> Now while this is just a random bit of YAML I produced, we can already start to see the limitations of YAMLs types and how it is conveyed to the programmer. Let's see how we can do better using something like Zod, a TypeScript schema validation library. const ServerConfig = z.object({ port: z.number().int().min(1).max(65535), timeout: z.number().positive().describe("Timeout in milliseconds"), ssl: z.boolean(), maxConnections: z.number().int().positive().or(z.literal(Infinity)), logLevel: z.enum(["debug", "info", "warn", "error"]), retries: z.number().int().nonnegative(), }); </code></pre> This is an example of the sorts of constraints which would be really great to be able to express in a configuration language. Here, we can tell that: port must be within the range [1, 65535]</li> logLevel must be one of the options instead of an arbitrary string</li> </ul> and so on. Strong types let us convey constraints clearly and regardless of whether we convey it to the user, all of our programs have constraints. This is why a schema is also important. Regardless of whether we provide a schema to the user, there is always an implicit schema. This schema-on-read is built in to the way that our program parses (and validates... we are validating user-provided data, right?) the config file. Now take a look at this config file: let LogLevel = < Debug | Info | Warn | Error > let MaxConnections = < Unlimited | Limit : Natural > let ServerConfig = { port : Natural , timeout_ms : Natural , ssl : Bool , log_level : LogLevel , max_connections : MaxConnections , retries : Natural } let config : ServerConfig = { port = 8080 , timeout_ms = 5000 , ssl = True , log_level = LogLevel.Info , max_connections = MaxConnections.Limit 100 , retries = 3 } in { server = config } </code></pre> This is a configuration language called Dhall</a>. You can think of it like "JSON + functions + types + imports." This Dhall file actually compiles into server: log_level: Info max_connections: 100 port: 8080 retries: 3 ssl: true timeout_ms: 5000 </code></pre> but it is so much clearer. To conclude, types and schemas are really our best friends for dealing with all sorts of problems we can run into when writing configuration state in brittle formats such as JSON or YAML. There are many other interesting higher level configuration languages to try like Dhall, Apple's Pkl</a>, and Google's Starlark</a>. If jumping in the deep end is impractical, even just combining an existing JSON config file with a JSON Schema</a> is a great first step, and provides real benefits. -- prydt Further reading</h2> https://beza1e1.tuxen.de/config_levels.html</a></li> https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/</a></li> </ul> Albums I Listened to in College 2026-01-08T00:00:00+00:00 Music has the uncanny ability to always remind me of certain people or certain times. Last year I graduated college, and I wanted to share some of the albums that stuck with me the most. You'll definitely realize that these are mostly in the vein of hyperpop or indie rock adjacent stuff. I'll include a few songs from each album that I think are standout so you can give each a quick taste but each and every one of these albums has been picked for being pretty cohesive and consistent in quality. Here's a brief set of "tasting notes" from some of my favorite albums of recent years: 1. 100 gecs - 1000 gecs</h2> (okayyyy... this album might not be the best to start off with. many others on this list are way more approachable. if this isn't your cup of matcha soy milk latte , i very much get it. but for the freaks like me... this will change your life ) </blockquote> got me into hyperpop</li> shrill, harsh</li> bombastic</li> autotune, catchy as hell</li> doesn't take itself too seriously. very fun</li> </ul> top songs: 745 sticky, money machine, ringtone 2. underscores - fishmonger / fearmonger</h2> The goddess of fortune was smiling on me when by chance, i attended a 100 gecs concert where the opener was none other than Underscores. She quickly became my favorite favorite favorite hyperpop musician of all time. </blockquote> extremely approachable hyperpop</li> very catchy, very tasteful</li> some of the best production ever</li> </ul> top songs: second hand embarrassment, bozo bozo bozo, spoiled little brat, your favorite sidekick if you like this album, go listen to Fearmonger and story of s*nny</a> (on soundcloud only???? WHY) 3. glass beach - the first glass beach album</h2> lowkey emo</li> thoughtful lyrics</li> energetic</li> really raw vocals</li> </ul> top songs: cold weather, bedroom community, classic j dies and goes to hell part 1, glass beach 4. wild party - phantom pop</h2> no skip album</li> just really really good indie pop.</li> nothing more to really say</li> if there was any justice, it would've been far more successful when it came out. (like Tally Hall)</li> </ul> top songs: OutRight, Life's Too Short, Take My Advice, Violet, Chasin' Honey, Lo-Fi Children 5. jhariah - a beginners guide to faking your death</h2> One of the most cohesive albums on this list. Tells a very fun story. </blockquote> jazzy</li> musicial</li> genre bending</li> incredible vocal range</li> villainous</li> </ul> top songs: ENTER: A BEGINNERS GUIDE TO FAKING YOUR DEATH, PRESSURE BOMB 3?!?!, DEBT COLLECTOR, Flight of the Crows 6. good kid - good kid</h2> really solid indie rock</li> songs are similar, but in a good way</li> </ul> top songs: Alchemist, Tell Me You Know, Witches 7. vampire weekend - vampire weekend</h2> saw them live, one of the best concerts I've been to. oldest album on this list which has a very recent skew </blockquote> fancy indie rock</li> ivy league vibes</li> aristocracy</li> </ul> top songs: Campus, Mansard Roof, Oxford Comma, M79 8. friday pilots club - nowhere</h2> Honestly just go listen to everything made by them. Lots of great singles not on this album. </blockquote> dark</li> haunting vocals</li> high energy</li> </ul> top songs: Vampire Disco, Nowhere, Spectator 9. happy fits - Concentrate</h2> happy</li> a tinge of melancholy, the right amount</li> </ul> top songs: Best Tears, "Alright, Cool, Whatever", Achey Bones Please go listen to these and tell me what you think! Fuzzing Binary Search 2025-11-10T00:00:00+00:00 Something close to a holy grail for me in programming is an automated test generator. Given some function, I would love to be able to throw my code at another program which probes my function and tries all the weird edge cases that I am sure to forget when writing unit tests or defensive asserts. Writing tests manually? That's boring! And oftentimes when something is boring, getting a computer to do it is a solution. Symbolic Execution (Klee)</h2> At first, I wanted to try out symbolic execution with Klee</a>. Klee is a symbolic execution engine for LLVM which runs programs with symbolic values for the variables, which allows it to effectively simulate running the program on all possible inputs at once! This is extremely cool, although you can probably already guess that this can be quite computationally expensive, even with Klee being extremely clever. But for constrained enough tasks, this absolutely fits my defintiion of a holy grail. The issue is that I wanted to try this with Rust, and it looks like using Klee with Rust is not currently well supported</a>. Alright... well maybe I'll try to get that working sometime later, but for now let's try something else. Fuzzing! Fuzzing</h2> Fuzzing is a technique for finding interesting test cases using randomized inputs. While this by itself is not too ground-breaking, more sophisticated fuzzers like American Fuzzy Lop (AFL) use techniques for directing the random input to maximize code coverage of the test cases. This allows fuzzers to try to take every path within your code and weasel their way into control-flow states you might not have expected. For my very basic trial of fuzzing, I will be using two libraries: proptest</a>1</a> and cargo-fuzz (libfuzzer)</a>. The problem</h2> I want to test these libraries on a small but important well-known bug: integer overflow in binary search</a>. public static int binarySearch(int[] a, int key) { int low = 0; int high = a.length - 1; while (low <= high) { int mid = (low + high) / 2; // BUG: low + high can overflow int midVal = a[mid]; if (midVal < key) low = mid + 1; else if (midVal > key) high = mid - 1; else return mid; // key found } return -(low + 1); // key not found. } </code></pre> Here the code is in its original Java from the article. I've rewritten it in Rust because I wanted to try fuzzing / property testing in Rust2</a>. pub fn binary_search(needle: i32, haystack: &Vec<i32>) -> Option<usize> { let mut low = 0; let mut high = haystack.len() - 1; while low <= high { let mid = (low + high) / 2; let mid_val = haystack[mid]; if mid_val < needle { low = mid + 1; } else if mid_val > needle { high = mid - 1; } else { return Some(mid); } } return None; } </code></pre> I've modified the signature for simplicity. In the original Java binarySearch</code>, a failure to find the item returns a negative insertion index, the index where the item would be inserted into the list. I've replaced that with an Option</code> type which makes the failure clearer, although it removes some information. In the Rust standard library, they return the insertion index with a Result</code> type. Now something I didn't realize immediately while translating this code manually: in the Java code, low and high are int</code>s (32-bit), while in Rust, they are usize</code> (pointer-sized unsigned int). This leads to some issues since the implementation assumes that high can be negative in the case of an empty list. -- This is where proptest and cargo-fuzz come in! proptest</h2> use proptest::prelude::*; #[allow(dead_code)] fn needle_and_haystack() -> impl Strategy<Value = (i32, Vec<i32>)> { ( 0..100i32, proptest::collection::vec(prop::num::i32::ANY, 0..100), ) } proptest! { #[test] fn proptest_binary_search((needle, mut haystack) in needle_and_haystack()) { haystack.sort_unstable(); let result = binary_search(needle, &haystack); match result { Some(index) => { prop_assert_eq!(haystack[index], needle); }, None => { prop_assert!(!haystack.contains(&needle)); } } } } </code></pre> proptest is a property-testing framework for Rust which automatically shrinks failing test cases. Here is the result of running the proptest: thread 'proptest_binary_search' (95480) panicked at src/main.rs:36:1: Test failed: attempt to subtract with overflow. minimal failing input: (needle, mut haystack) = ( 0, [], ) </code></pre> It correctly found that an empty list is an error since high is now a usize! cargo-fuzz</h2> #![no_main] use fuzz_binary_search::binary_search; use libfuzzer_sys::fuzz_target; fuzz_target!(|input: (i32, Vec<i32>)| { let (needle, haystack) = input; let result = binary_search(needle, &haystack); match result { Some(idx) => assert_eq!(haystack[idx], needle), None => assert!(!haystack.contains(&needle)), } }); </code></pre> cargo-fuzz, which uses LLVM's libfuzzer under the hood, is also able to find several errors with this implementation which has been shoddily translated. P.S. wanna get your LSP to work in the fuzz/</code> directory that cargo-fuzz uses? You need to add this to your Cargo.toml. [workspace] members = [ ".", "fuzz" ] </code></pre> Some remarks</h2> Although proptest felt a little more clunky when defining input constraints, this does help speed up the search through guidance. Something that I didn't expect but had fun learning was that actually reproducing this bug from 2006 in Rust would have led me to write some quite awkward Rust^{3</a>! This is exactly what I want from a programming language. I want to be nudged in the correct direction. Rust makes it difficult to "hold it wrong." Modern programming languages really ought to be poka-yoke</a>.} This was just an excuse to play around with fuzz testing and it works remarkably well for the amount of effort it takes. I think that if you are writing some data structure or some non-trivial transformation, there's really no reason not to fuzz your program. Fuzzing is of course no cure-all, but it is easy enough to setup that you don't really have an excuse not to try it! I've made a git repo for these little experiments so if you want to see the complete code for any of these examples, here: https://github.com/prydt/etudes/tree/main/fuzz-binary-search</a> Further reading</h2> The Proptest Book</a></li> The Rust Fuzz Book</a>, covering cargo-fuzz and AFL</li> Pulling JPEGs out of thin air</a>, a really neat example of the powers of fuzzing</li> </ul> Footnotes</h3> ^{1 proptest is actually a library for property testing which is slightly different from fuzzing. Property testing has more guidance from the programmer for how the inputs are generated, while fuzzing tends to be more black-box. </div> ^{2 Why for real? -- For fun! </div> ^{3 I would have needed to intentionally cast low, high into i32</code> and then cast back into usize</code> for indexing. </div>}}} another day, another blog 2025-09-17T00:00:00+00:00 Writing is nature's way of telling us how lousy our thinking is. - (This quote is sometimes attributed to Leslie Lamport, but he is actually quoting Dick Guindon</a>) </blockquote> Although I've had a blog in one form or another since 2017</a>, blogging never became a habit for me. I'd always have ideas but either never written them down. Whenever I did write something, I tried to do something too big or too polished. Here's how I plan to change this. 1. Quantity has a quality all its own.1</a></h2> It's unintuitive, but I believe that lowering my standards to some degree will actually improve my writing quality in the long run. The desire to have a blog with only the highest quality posts is actually hampering my ability to become a better writer. While I don't think you throw out all quality control, loosening standards in favor of consistency will hopefully result in increased quality. 2. Don't futz with it.2</a></h2> Like so many aspirational bloggers, I fell into the trap of spending more time on my blogging setup than actually writing. I started on Jekyll</a>, switched to Hugo</a>, and now I'm on Zola</a>. None of this matters to me or to readers. While it's nice to have a cool custom theme, etc, etc, nothing matters more than just writing. I've settled on a setup and I'm not going to futz with it anymore. 3. Make it social!</h2> I've enlisted a group of friends to join a "blogging circle" where we all share our writing and keep each other encouraged to continue to be consistent with it. I will link my friend's posts here from time to time and I can't wait to do this more. Blog Trailer</h2> Here are some topics that interest me and I hope to cover in no particular order: Distributed Systems</li> Programming languages</li> Concurrency</li> Hashtables</li> Politics</li> Music</li> Anything I'm reading</li> ... really anything, we'll see.</li> </ul> Here's to consistency! -- Pranoy Footnotes</h3> ^1Attributed to Karl Marx</a>, often misattributed to Stalin. </div> ^2Don't futz around with these hashbrowns</a> </div>

Monitor Synchronization</h1>
Hoare elaborated and popularized the Monitor concurrency primitive invented by Per Brinch Hansen. Monitors solve a common issue in concurrent programs: making threads (efficiently) wait for a condition to become true before continuing.</p>

Further reading</h2>

https://beza1e1.tuxen.de/config_levels.html</a></li>
https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/</a></li> </ul>

9. happy fits - Concentrate</h2>

happy</li>
a tinge of melancholy, the right amount</li> </ul>
top songs: Best Tears, "Alright, Cool, Whatever", Achey Bones</p>
Please go listen to these and tell me what you think!</p>

A Few Good Ideas in Programming Languages

AI Fear and Uncertainty

On Tony Hoare

Configuration Languages Should be Strongly Typed

Albums I Listened to in College

Fuzzing Binary Search

another day, another blog

A Few Good Ideas in Programming Languages

AI Fear and Uncertainty

On Tony Hoare

Monitor Synchronization</h1> Hoare elaborated and popularized the Monitor concurrency primitive invented by Per Brinch Hansen. Monitors solve a common issue in concurrent programs: making threads (efficiently) wait for a condition to become true before continuing.</p>

Configuration Languages Should be Strongly Typed

Albums I Listened to in College

1. 100 gecs - 1000 gecs</h2> (okayyyy... this album might not be the best to start off with. many others on this list are way more approachable. if this isn't your cup of matcha soy milk latte , i very much get it. but for the freaks like me... this will change your life )</p> </blockquote>

2. underscores - fishmonger / fearmonger</h2> The goddess of fortune was smiling on me when by chance, i attended a 100 gecs concert where the opener was none other than Underscores. She quickly became my favorite favorite favorite hyperpop musician of all time.</p> </blockquote>

9. happy fits - Concentrate</h2> happy</li> a tinge of melancholy, the right amount</li> </ul> top songs: Best Tears, "Alright, Cool, Whatever", Achey Bones</p> Please go listen to these and tell me what you think!</p>

Fuzzing Binary Search

Some remarks</h2> Although proptest felt a little more clunky when defining input constraints, this does help speed up the search through guidance.</p>

another day, another blog

Monitor Synchronization</h1>
Hoare elaborated and popularized the Monitor concurrency primitive invented by Per Brinch Hansen. Monitors solve a common issue in concurrent programs: making threads (efficiently) wait for a condition to become true before continuing.</p>

9. happy fits - Concentrate</h2>

happy</li>
a tinge of melancholy, the right amount</li> </ul>
top songs: Best Tears, "Alright, Cool, Whatever", Achey Bones</p>
Please go listen to these and tell me what you think!</p>