I've been writing software for decades and during that time have generated a small collection of programs I've written for my own use and I plan to write more as time allows.

When I look ahead to the next twenty years I wonder if these tools will still build and run on new computers and new OS installs. I may add new features and fix bugs, that's normal and I'm ready for that. But I worry if they will still be usable in twenty years time without needing to be rewritten due to changes beyond my control.

Blub is getting older. I'm fit and mostly well, so don't worry about Blub. My patience and energy might not be enough to manage a rewrite, solve complex build problems, or fix broken dependencies ten or twenty years in the future.

Now is the time to plan ahead! 🤪

Blub will make a plan to future proof his tools now, and perhaps at the same time reduce my dependencies on third party SaaS offerings. I'm unconvinced many of the current SaaS suppliers will be around in ten or twenty years time - and I'm bored of thinking about keeping current and how I protect and not lose my data held with third parties.

Self reliance and data ownership is of growing importance to Blub as the years roll by.

My current programs run on Linux and Mac. There is a lot of C and also other languages (compiled and interpreted). Most are console based, some command line, some with TUIs. The fancy ones rely on locally run web servers, with backends, databases and browser front end UIs. Some are shell scripts. It's a mish-mash. They are aimed at managing my life and personal information in various ways and enhancing my day to day work flows. I mostly live in the terminal. These tools are for my own use - I Am The Only User.

If I go ahead and rewrite and consolidate these tools, the actual development features I need are minimal: to display information, get user input, read and write files, handle dates and times, access and enquire of the file system and execute external programs. Drawing simple charts might be useful too. I want to clearly understand all my dependencies and not have any license issues.

It's impossibly hard to predict the future twenty years from now. Will there even be laptops for developers in twenty years time? I am going to assume there will be. I'm going to also assume I can still log into a terminal in a POSIX based environment.

But what shell? This is not an innocent question. I was slightly rocked when Apple recently moved away from Bash to Zsh link as their default shell. In my project, for any scripts I need, I will choose Bash, I will be explicit about what version of Bash these scripts need and I will not deviate.

For an editor I will select VIM. The original VIM. In my tools, when I need to edit text within the tool I will often shell out to a real editor. I will use the EDITOR environment variable for this, but assume it will be set to VIM.

As a build tool I will use Make. Other tools are becoming popular, CMake, Ninja and the like, but the longevity of Make and the sheer number of projects that already depend on it are huge. It's not going anywhere. It's not changing. I'm confident it will still be here, easy to access and usable in twenty years time.

For UI I will use the terminal. Browser based UIs bring in Front End technologies. There is far too much churn and flux in that space to have any confidence in a ten or twenty year time frame for stability. Desktop UIs are ruled out. Ecosystem changes at Apple as they move to Swift imply this is a moving target for Mac's. In the Linux space nothing really appeals for Desktop UIs. I will use ncurses and TUIs and command lines. ncurses has a history going back to the early 80s. It's stable, it's unlikely to change.

Any data I store will be file based - plain text if possible. I will not use a database. I don't have that much data to warrant the additional complexity of using a database. One less (complicated) dependency to maintain and worry about. One less sub system to worry if it will still be around, easy to setup and usable in twenty years time. I'll use git for version control.

What language?

Python / Ruby / Go? A massive amount of software is being developed in these languages. But they are still evolving. Will something I write now run unchanged in twenty years time on newer versions of the language and runtime? I'm not sure.

C++ prides itself on preserving backward compatibility. But my head hurts at some of the language complexity. Yes, I'll write it professionally with pleasure, but I don't really want to use it for home projects.

Javascript? The ecosystem and how dependencies are managed doesn't give me that warm comfortably feeling I need when planning ten and twenty years ahead.

Lisp / Common Lisp? Probably a good bet. But I'm not familiar enough with the language to make this a good personal choice and if I go down that rabbit hole I may not ever come back!

Rust / Erlang / Clojure / Java / insert your favourite here. Blub isn't going to justify why I'm not choosing a specific language. I can appreciate everyone may have a view on this. That's great. Go ahead and write a blog article about it ;-)

C is pervasive. It is Standards based. It's easy to install on POSIX based systems, on Linux. This is unlikely to change. I can pick a standards version and be confident it will be available in years to come. But! I wield my pointers like the best of them and manual memory management gives me no fears, but perhaps it's time to be spoilt. I'd like garbage collection, built in dictionary support, good support for regexs and excellent string handling facilities and no hard crashes. I'd like increased productivity that using a higher level language often brings.

Lua - Adding Lua into the mix gives interesting possibilities. I'm not worried about the language changing over time. I can download, store and easily build a specific version of Lua and retain it long term side by side with the applications I write. It's small and very managable. I'm not sure I could do the same with other languages.

Building a hybrid runtime using Lua and C, with additional support for ncurses from Lua (and anything else I may need) could be an interesting way forward. My applications would be written in Lua on this runtime.

The Plan

• Build an application runtime in vanilla Standard C using Lua as the foundation with support for ncurses.
• Use no additional C libraries beyond the C Standard Library and selected POSIX OS calls. See ACE
• Use Make as the build tool and git for version control.
• Rewrite my tools for this runtime in Lua, using C only where necessary.
• Any glue scripts to be written using this runtime, or for a specific version of Bash.

This gives me a fair shot at developing tools that will still build and execute in twenty years time.

Now there is a plan in place, Blub is worried about being run over by a bus tomorrow.

What's your plan?

:-)

Blub

Subscribe to my blog via email or RSS feed.