Building Better Building Blocks
In search of the simplification of our software building blocks
These are not the droids you are looking for
I spent the past year writing the most improbable of books. The book is a story about how to learn and effectively leverage a twenty-one year old collections library, built in Java, for Java developers. The book contains knowledge learned in the last century, in the days when developers wielded Smalltalk like a light saber. The book lowers the cost of learning a feature-rich, million plus LOC Java collections library named Eclipse Collections to help developers write more concise and readable code. It does this by leveraging information chunking techniques to group hundreds of methods in its rich API into several method categories explained with color syntax highlighted code examples in eight chapters. The book is a reminder that programming is fun, not just a tedious necessity.
The book contains some revelations, and effective strategies for many developers to leverage in the building of their own better building blocks. It is a reminder that the code we build our applications with is important. It is also a reminder that every developer who invests in themselves and others for the long term is going to be more valuable than every LLM that they may decide to leverage to augment their own development speed.
We’re not there yet
I believe using LLMs to generate code based on the building blocks we have today is going to be a costly decision. I think it would be much better to focus significant energy and resources on building better building blocks to help us simplify how we build applications. If AI can be used to help build those better building blocks, then great! One of the biggest problems that we face with technology today is the sheer complexity of the building blocks we need to deal with when building applications. 3d printing our applications with AI code generators trained on code we and others have written previously will not improve the complexity we need to deal with. It will just generate a huge morass of code, that someone down the road will still need to understand and maintain. This is not a problem caused by the LLMs, it is a problem we caused for ourselves.
Today, when we build applications we use the equivalent of Lego, Erector Set, Lincoln Logs, Etch-a-sketch, Play-doh, and copious amounts of Super Glue. We have to be experts in all of them.
I see the gradual improvements being made to languages like Java (and other JVM languages), Python, C++, C#, JavaScript, Rust, Go, Swift, and can’t help wonder what will happen when we use fast concrete to quickly build apps based on soon to be outdated versions of all these languages. Multiply all of these by the huge number of libraries build in each of these ecosystems. Tools like OpenRewrite will likely see significant use in trying to keep applications up to date and current, but I think we will quickly forget how to keep our developers up to date on all of the components and versions.
Where do we go from here
I would like to see much more investment into the underlying infrastructure (programming languages, libraries, etc.) that we use to build our applications. Let’s simplify things, before we drown ourselves in the fast concrete homes that AI salespeople promise us that LLMs will build for us.
In 1997, I built Distributed Smalltalk applications with DB2 as a relational back-end. Everything from the UI, to the RPC, to the data access and integration logic (e.g. direct manipulation of Excel files) was built in a single language — Smalltalk. The client app was built in Smalltalk. The server apps were built in Smalltalk. The remote monitoring and administration app was built in Smalltalk. One person could understand and maintain the application in its entirety, even though it was a multi-tier distributed app. The days of this kind of uniform simplicity are long gone, and I never quite understood why we headed down the road of complexity we now find ourselves in.
The web got us strangely dazed and confused in the late 1990s and early 2000s. We started building apps with multiple teams doing front-end and back-end development. We went quickly through numerous generations of UI frameworks, RPC solutions, backend mapping layers, and database storage platforms. The first to deliver solutions were often rewarded, even though the underlying infra was often slapped together. Those that could evolve to scale continued to survive.
The problem with generating our applications based on where we are, is that we will wind up exactly where we are, just with too much code for too few well trained, and experienced developers to maintain. We have some very smart people working on developing programming languages and libraries. I hope we continue to invest sufficiently in them so we can help simplify our building blocks.
I encourage you to keep investing in yourselves and other developers in your communities. We will need to help each other to keep ourselves from drowning in the complexity of our own making. I wrote my book to pass on so many of the lessons I have learned in the past 35 years of my own career. I hope the knowledge I share serves you well, and that we all wind up in a better software development future, not just stuck firmly where we already are. I hope others will continue sharing their stories in blogs and books. Not to feed the LLMs more text, but to feed each other new ideas so we can survive and thrive.
I can’t predict the future, but my hope for the future is for billions of happy and healthy humans exploring and expanding upon their creativity, aided by better tools that we can all hope to understand. Thanks for reading.
I am the creator of and committer for the Eclipse Collections OSS project, which is managed at the Eclipse Foundation. Eclipse Collections is open for contributions. I am also the author of the book, Eclipse Collections Categorically: Level up your programming game.
