🐒 Bring back Dumb Programs

Bringing back dumb apps

Sea of ideas

I have written a few different posts about the thoughts on the current state of technology. The siloing of information, sun-setting and the single responsibility principle in apps. It's easy to point at issues, but it is harder to actually do something about it.

Reading Pketh's blog about making Kinopo and Glitch; I was inspired to make my own sort of manifesto about how I want to build tech.

Tooling

I made chumbucket, as a way to make apps fast, and I made a lot of random little apps with it which are still very easy to maintain and upgrade, but building things with Typescript/JavaScript became increasingly annoying because I would have to find a wrapper system to access beautiful desktop things like files.

I tried a few languages like Nim, python, Lua and a tiny bit of Clojure, but their GUI libraries were unpleasent or few and far between, so I ended up running web servers to create the GUI making it very weird…

Karasu is a great example of this weirdness.

My solution is to translate the same code feel to flutter and make tiny, good, multi-platform flutter apps. Flutter is very nice to program with, it compiles to lots of places, and dart is pretty easy to pickup and run with.

Dart has a health community of CLI apps as well as flutter which has a health community of GUI apps. It's an absolute breeze to go back and forth between mac and Linux and compile the same project natively.

Impactful Quotes

This section from Viznut's Permacomputing when they describe dumb programs.

6.1. Dumb programs

A program that is intended to be like a tool should be understandable, predictable and wieldy.

It should be simple enough that a proficient user can produce an unambiguous and complete natural-language description of what it does (and how)...

The absolute number of features is not as important as the flexibility of combining them. Ideally, this flexibility would greatly exceed the intentions of the original author of the program.

Ville-Matias "Viznut" Heikkilä.

I think the idea of being unambiguous and easy to explain is import. Not enough people wonder how something works,

they just enjoy what it does and hope no one is being creepy.

Built to Die, and Secretive About It

Funding models explain why it’s so hard to rely on software services long-term. Not because of technical problems like crashes, but because they’re often built to die.

Interesting, cool, and nice-to-use tools and platforms come out all the time. But it’s annoying to invest the time in learning and relying on something new only for it to get acquired and sunset, or become crappy in the 🎡 pursuit of growth-at-all-costs.

Pketh - Kinopio creator

This is something that has happened to me many times on both ends, and I have been in invited to help build things that's soul purpose is to be bought out and sunset.

I think about the original Pokémon games with no internet features they are still playable and on almost any platform because they run in a virtual machine... well really an emulator, but it's a similar concept. Flutter apps are built with a similar architecture.

Pokemon Go architecture is the reserves, I have no confidence my daughter will be able to play Pokemon Go but She can always play original Pokemon.

the hamster

can rest

Online APIs are how web apps get information and save information. There are an always on, running up Cloud computing bills.

They are from conception near unsustainable, like a hamster running on a wheel until it has no more energy aka the company runs out of money.

Offline apps, on the other hand, are not subject to the same unsustainable. As long as you have the app installed on your device, it can be time locked and frozen, you will be able to use it, even if the company that developed it goes out of business. This makes offline apps a more reliable option for users who want to ensure that they will always have access to their data and apps.

Maybe everyone knows this already, and I'm just coming from a web engineering background, but I see files now as the OG decentralized APIs, you can access the same information from an "at rest" mp3 file instead of a JSON formatted object in an unsustainable Spotify API with a much better build for the future.

to maintain the Spotify you need a critical mass of user for funding because of constant security, constant storage & user management

to maintain the mp3 library you have to do nothing

Human Readable

to be inline with my thinking and what Ville-Matias said above; I wanted to use a storage format that empowers the user to

understand their data. Here is an example from a manga app

[manga.mushishi]

cover="/cover.jpg"

chapters= [

"/mushishi/01",

"/mushishi/02",

"/mushishi/03",

]

[manga.blue_period]

cover="/01.jpg"

chapters= [

"/blue_period/01",

"/blue_period/02",

]

TOML was created to be transparent, it stands for Tom's Obvious Minimal Language. I think using TOML will be a key part of my apps because its well supported and easy to read. There are other flat file databases like csvs that might be more preferment but this needs investigation after building a few apps.