🐒 Bring back Dumb Programs

Bringing back dumb apps

Source: Simian Reflux

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.

Source: marnie

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.

Source: chxrrypie

Tooling

Source: Cat's Cafe Comics

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…

Source: Omatarox
Source: Molly Jacques
Source: Katy Wang

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.

Source: LaGrandeGru

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.

Source: chxrrypie

Impactful Quotes

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

Source: bryson mcbee

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)...

Source: Nattogif

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.

Source: Moreno's Park

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

Source: mottoajans

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.

Source: undefined

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.

Source: undefined

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.

Source: undefined
Source: chxrrypie

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.

Source: ITechArt Life

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.

Source: DR.ME

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.

Source: Adult Swim
Source: ramcsquirrel

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

Source: badblueprints

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

Source: Giflytics
Source: 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.

Source: Pivovar Svijany
Source: Eledraws (Eleonore Bem)

Gatherers & Consumers.

Source: Lazy Corgi

Because most of the world is online, I think I will need 2 types mind sets for apps

A gatherer will get information, create the decentralized APIs by store them as files it could be a text files, image, GIF, video, or audio

a consumer would be something that shows, organizes or transforms that information.

Source: Dispo

So for example a gallery app that reads pictures and creates albums that's a consumer because without photos It's basically nothing.

Source: ZoetryandLetters
Source: cremefleurs

Principles

Source: natasha

- be unable to sunset

- treat the Internet like a tap that's on or off.

- be obvious and explicitly when it's connecting to the Internet

- Files will be the primary input and output (TOML preferably).

- no login, no accounts

- personal information should be avoid or encrypted

- Draggable UX or Keyboard focused UX are preferred

(feeling like an instrument)

- old Ugly is the new cute

- Minimalistic

- Non internet sharing is preferably (offline QR Code).

Source: Kriestengarten
Source: Bortusk Leer

What am I going to build?

I'm not sure yet, I have a lot of ideas but in no particular order know I want to rebuild

otxto: offline kanban manager currently using todo.txt standard

manabee: offline manga reader with built-in offline Japanese dictionary

Karasu: an offline PGP key manager and message encoder

Niwa: an offline infinite canvas mood board used for creative project or memories

Made on mmm