Articles on Philosophy
Last updated: 2023/03/09
Top deep-dives on Philosophy
Yeah it's mostly philosophy related to writing code and not super technical, but we really surround ourselves with a lot of philosophy when programming (design patterns, language patterns, architecture styles to name a few). In this insightful article, Jamie Brandon explores the validity of advice received over 12 years of working with code, and shares thoughts on observed patterns.
Recursion can be difficult to understand, and as a result of that, it is frequently misused or just flat out not used. That's a shame though, because it can be very useful for certain situations. The author of this article outlines some of the common functions used to teach recursion, why they're not very good lessons, and finally a better way to teach recursion, as recommended by How to Design Programs.
It has been said that as programmers, we spend more time reading code than writing it. It reminds me of what my boss once told me when I was interning at an electrical engineering company, something along the lines of most good engineers ending up writing more than they end up doing actual engineering. Well Lucian Radu Teodorescu's article explores how we reason about code, by transforming a normally intuitive process into something mathematical.
Full disclosure, this article is a decade old. However, I found its concepts were timeless, so figured no harm in featuring it. Bret Victor's exceptionally interactive article "presents the ladder of abstraction, a technique for thinking explicitly about [different levels of abstraction], so a designer can move among them consciously and confidently".
More of a philosophical/self-help piece that looks at improving your programming abilities. Jamie Brandon describes some of the methods he uses to speed up his process for writing code. Specifically, Jamie covers how to make decisions, improve focus, batching, making small changes, shortening feedback loops, writing stuff down, reducing frequent mistakes, making low level skills automatic, and reflecting.
Alex Ellis talks through the different approaches for visualizing code and underlines some available tooling one could use.
This is more of a philosophical article, where Jonathan Goodwin explores the nuances of what a programming paradigm is, very much in a Theory of Knowledge-esque essay for anyone who did the IB. Jonathan first looks at the "unhelpful" Wikipedia definition, then Thomas Kuhn's, ultimately ending with an analysis of George Floyd thought and the relevance of both opinions in the 21st century.
This article kind of resonated with me, because it's kind of how I do things. Laurence Tratt discusses his approach to practicing programming by implementing real life applications in different languages or using different tools.
This could probably be considered a controversial piece, but if I wasn't exposing you to different perspectives and ideas, I wouldn't be meeting the expectations of this newsletter. Jake Bauer's article explores how free software (not to be confused with open source software) is ultimately a failed ideology and culture. Jake also picks apart the GPL and free software's relevancy.
Sean Mack takes a thorough look at technical debt; its history, the different forms it comes in, and ultimately how it can be measured/calculated.
Dan Lew discusses the different approaches one can take towards making sure the code that is written is "correct".
I constantly hear about frontend engineers getting a bunch of crap for not being "real" programmers. As a non-frontend guy who has dabbled extensively in the field, that sounds like a bunch of BS to me. In this philosophical article, Jared Gorski explores some of the diffiiculties of frontend engineering and building human-data interfaces. Although I don't agree with all of his points (I don't think backend is often obvious), Jared highlights a couple of important points in regards to the difficulties of making data palpable for humans.
When you're developing a product, you might be inclined to add features or extra code to handle things in the future. You might spend a lot of time doing it, only to find out later that you're not even going to use it, because your users don't want to use it. Simón Muñoz's article illuminates this issue and the general problem of overengineering, going through the what, why, and how to avoid it.
Llorenç Muntaner explores Extended Backus-Narus Form, the language that describes the syntax rules of programming languages.
Xe Iaso starts a discourse by presenting some of the issues resulting from the modern devops philosophy.
A new top-level syntax for programming languages is proposed by Alex Rogozhnikov to show advantages of this method.
- Write all code with the delimiter first
- New syntax is arguably as simple, but more consistent, better preserves visual structure and solves some issues in code formatting
- Exploring new ideas like this is helpful for the evolution of programming language design
Bob Rudis goes on a technical deep-dive of how to take care of your most important tool and piece of equipment, yourself.
When I write code for any nontrivial system, it feels like I'm on tightrope for each new feature, balancing how long something takes and the extendability of the result. At the same time, there's a blindfolded user at the end, precariously swinging a cutlass around the connection to the platform, potentially cutting the feature at any moment. Well this article by Steven Wittens won't help you with that existential crisis, but he does analyze what makes a system extensible, using birds.
Fred Hebert elaborates on errors in software engineering/site reliability, and the "human" factor in interpreting, understanding, and ultimately solving them.
Fabian Zeindl discusses different ways to improve the quality of software systems. Fabian groups different qualities into a pyramid, with lower parts of the pyramid supporting the parts further up.
- Keep the build graph simple by grouping related tasks together and eliminating unnecessary work
- Use a caching mechanism to avoid rebuilding the same thing multiple times
- Avoid installing dependencies multiple times by using a dependency manager
Although more philosophical in nature (it has code too though!), this article by Macoy Madson focuses on exploring an important question all programmers have to face; at what point should you automate a task? Macoy uses an example of having to keep the user interface responsive during a full system file scan to justify the use of macros with Cakelisp.
Dan Luu takes a stab at explaining why effective purchasing is so difficult, and how it relates to writing software for a business. I know, I know, doesn't sound super technical, but this piece struck a chord with me, especially when it comes to the decisions of "should I build this myself, or SaaS it up?".
Tim Cochran and Carl Nygard discuss why technical debt arises, how to keep track of it, and how to get rid of it. Not a technical deep-dive per se, but relevant to programming nonetheless. Unless you're some maniac who never has technical debt, in which case kudos (or maybe that's a problem too as highlighted by this article?).
Jordan Kaye discusses the idea of "striped development", which is an iterative approach to designing and implementing software. In this approach, work is organized into three repeating phases: design, striping, and implementation. The most important part of this strategy is that it is circular, meaning that the design phase is updated after each stripe is implemented. This allows for new information to be taken into account and for the design to be improved over time.
Claude Roux describes some of reasons as to why someone would choose to use a Lisp language over more conventional C resembling alternatives. If you haven't attempted to learn a Lisp language yet, I'd really recommend it.
- Lisp is homoiconic
- An advantage of Lisp is that there is no need to invent different programming styles to integrate new features
- Lisp is a way of representing and executing programs in an intermediate form between man and machine
This article is about the benefits of using models to combat the complexity of software. Alex Weisberger argues that models are essential to software minimalism and that they offer a number of benefits, including simplifying testing and proofing.
- Models are easy to understand
- Models are cheaper to make
- Models need to be kept in sync with actual implementation
Scott Aaronson explains why he's not afraid of AI.
- Compares it to bullying nerds and worse
- Exceptionally intelligent people generally aren't evil?
- This article is just philosophy on a technical topic (no code!)
Caleb Hearth explains the "Law of Demeter", which "says that an object should not 'reach through' its collaborators to access their collaborators’ data, methods, or collaborators", using examples from Ruby.
Tom Niget explains recursion and how it can be used to solve various programming tasks. Tom also talks about the disadvantages of recursion and how it can be inefficient.
- Multiple programming languages used for examples
- Dives into how functions work from bottom up
- Implements a stack
As humans, we're subject to believing in what people we admire or respect say, often times without taking a second to double check if said statement is true or "correct". This assumption of truth doesn't only extend to people. In this appeal-to-reason article, Alex Weisberger discusses and presents examples of how "this progam was formally verified, so please stop asking me if there are any bugs" doesn't really mean much when the initial specifications were wrong.
Philippe M. Groarke philosophizes on "a different way to write templated C++ and type traits".
In this series of articles, Russ Cox discusses why and how transparent telemetry can help improve open source software projects.
- "Without telemetry, developers rely on bug reports and surveys to find out when their software isn’t working or how it is being used"
- Not having detailed information about how the software is being used makes it difficult for maintainers to implement essentials fixes/features
- Transparent telemetry collects as little as possible (kilobytes per year from each installation) and then publishes every bit that it collects, for public inspection and analysis
Rachel Kroll describes a technical approach to task priority handling using a dependency graph with two examples.