/articles

A list of articles, essays, and presentations about software that I feel are worth reading.

MIT LicenseMIT

Articles, Essays, and Presentations

A list of articles, essays, and presentations about software that I feel are worth reading.

Table of Contents

Shortcomings of Object-Oriented Design

table of contents

  • Pitfalls of Object Oriented Programming, Tony Albrecht

    • An indictment of OOP from the perspective of performance in game and console development. The main thesis is that OOP's main optimization bottleneck is data-access speed. Memory access is getting slower as RAM sizes grow, so OOP patterns become less and less tenable for high-performance game development as time goes on. This problem is most easily solved by writing programs whose data-operations can be parallelized.

  • Why OO Sucks, Joe Armstrong

    • Joe Armstrong invented Erlang, one of the most important moments in the recent history of programming language design. The article expands on his feeling that "When [he] was first introduced to the idea of OOP [he] was skeptical but didn’t know why - it just felt 'wrong'..." I spent my early engineering career laboring under exactly this sentiment.

    • Since functions and data structures are completely different types of animal it is fundamentally incorrect to lock them up in the same cage

    • For some brief follow-up thoughts, see No, that's not why OO sucks, Martin Vilcans

  • Bad Properties of OO, Luca Cardelli

    • A comparison of several good-making features of programming languages between "procedural" (functional) languages and object-oriented languges.

    • Smalltalk was originally intended as a language that would be easy to learn. C++ is based on a fairly simple model, inherited from Simula, but is otherwise daunting in the complexity of its many features. Somewhere along the line something went wrong; what started as economical and uniform ("everything is an object") ended up as a baroque collection of class varieties. Java represents a healthy reaction to the complexity trend, but is more complex than many people realize.

  • OOP Versus Functional Decomposition

  • Arguments Against OOP

  • Object Oriented Programming is an Expensive Disaster Which Must End, Lawrence Krubner

    • A very systematic approach to the question, one that resonats with me as an analytic philosopher.
    • Show that the purported benefits of OOP are not unique to OOP languages (OOP is not necessary to get encapsulation, inheritance, etc)
    • Show that all OOP languages have severe shortcomings that nullify its purported benefets (OOP is not sufficient to get the kind of encapsulation, inheritance, etc that developers want)

Shortcomings of Relational Database Systems

table of contents

  • OrmHate, Martin Fowler
    • God I love this guy. Fowler argues that the biggest problem with ORMs is that the RDBMS way of modeling data is so different from the way of modeling data you want to use while programming. This resonates with me. RDBMS has never made any sense to me as an abstraction. Tables are just a terrible way of conceptualizing almost anything. Everyone hates tables. Ask yourself what you'd happily track in a spread sheet. It should be a short list. Ask yourself what you'd happily track by dynamically linking many spread sheets together in complex and sophisticated ways. It should be a shorter list.

GraphQL

table of contents

  • GraphQL and DDD: the Missing Link, Robert Zhu

    • A brief comparison between GraphQL and REST API design from the perspective of domain-driven design. I'm really interested in domain-driven design, and this relationship is one of the main things that appeal to me about GraphQL. I've felt deeply confused about the domain shape of most products I've worked on. In my experience, few people have given the fundamental shape of their product space careful attention. But GraphQL makes that process much more natural and intuitive. The technology invites a careful approach.

  • GraphQL First: A better way to build modern apps, Matt DeBergalis

  • Lessons learned wrapping a REST API with GraphQL, Joel Griffith

    • A really clean approach to using GraphQL to automate REST service wrapping.

Functional Programming

table of contents

General Software Architecture

  • Clean Code Javascript, Ryan McDermott

    • An outline of Robert Martin's Clean Code priniciples using contemporary JavaScript.

  • A Little Architecture, Robert C. Martin

    • A platonic dialogue between an aspiring software architect and an experienced one. The experienced one tries to explain what is really essential to maintainable architecture.

    • That’s right. They are. The important decisions that a Software Architect makes are the ones that allow you to NOT make the decisions about the database, and the webserver, and the frameworks.

  • Twelve-Factor Apps in Node.js, Peter Lyons

    • A detailed discourse on implenting the 12 factor app principles in a Node project. Super useful to see Node specific explanations.

  • REST APIs must be hypertext-driven, Roy T. Felding

    • A bullet list of RESTful requirements by the original author of the REST thesis. The comment thread is also very instructive. See especially comment #8

    • I think most people just make the mistake that it should be simple to design simple things. In reality, the effort required to design something is inversely proportional to the simplicity of the result. As architectural styles go, REST is very simple.

  • The Expression Problem

    • A brief summary of the most pervasive problem in all software design

Workflow and Process

table of contents

Programmer Psychology & Paradigms

table of contents

  • Re: [Eve] Re: Prototyping Eve's UI, Chris Granger
    • A brief desrciption of Granger's ambitions for the future of software development, in the context of a dramatic re-write of Eve

    • A while back I asked a question on Twitter - what if you could build a complete functional clone of FourSquare in a day? There are lots of angles you could take on that question, but the most relevant one here isn't about how the industry changes or what that means for software engineering, it's what that means for us as individuals. What could we do if the system you worked with didn't just make the cost of encoding very low, but helped you explore your idea as well? What would it mean if you really could build your entire idea in a day? The reason we started going down this UI is that we think it could be a viable path to that reality.