💾 Archived View for skyjake.fi › gemlog › 2022-05_bloat.gmi captured on 2023-11-14 at 07:53:12. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Bloat

Ainent has concerns about Lagrange's scope:

Lagrange objectively breaks that pattern [of the Unix philosophy] and therefore is subjectively starting to sound bloated

I, too, deeply appreciate the Unix philosophy when it comes to system-level utilities and command line tools, but when it comes to GUI apps, and cross-platform ones at that, things get a lot less clear.

Software being "bloated" is an interesting concept. It is a very relative term, for one thing. Something that was considered bloated 20 years ago is extremely small and zippy by today's standards. We didn't have an expectation of needing 8-16 GB of RAM in our computers back then... One way to look at bloat is to invent/find an alternative implementation that achieves the same functionality with less "bloat", but this is open to subjective importance placed on things like UX quality. The term is also vague enough to apply to non-technical aspects. Bloated software may have too broad a scope, having too many features that only loosely fit together. An overly long feature list can be a point of concern, much like when a restaurant's menu covers too many cuisines — surely the execution can't be top notch all around. In a very concrete way, the number of features is a measure of the complexity of the code base, and higher complexity can be linked to "bloat", bugs, and generally poorer software quality. But the thing is, features aren't all equally complex and large. A 100 small and simple features is more manageable than 10 large and complex features.

If you take a peek under the hood, Lagrange is not that complicated. If we include my the_Foundation library, because it's an integral part of the app:

 Component      | KLOC
----------------+------
 audio          |   5
 stb            |  11
 ui             |  34
 rest of "src/" |  19
 the_Foundation |  30
----------------+------
 Total          |  99

KLOC isn't a perfect metric, but since most of the code is written by a single author in a consistent style, at least the numbers should be comparable across the code base.

The network code that Ainent is worrying about is a total of 1040 LOC, including all the supported protocols, and 1640 LOC more for TLS connections and server/client certificate management (1 KLOC of that is in the_Foundation). Comparing to the GUI, which is essentially what Lagrange is, that is a pretty small amount of code. So, if we were to apply the Unix philosophy here and build a Gemtext viewer app that interfaces with various protocol backends, the architecture would certainly become more flexible — we could add even more protocols! — the app wouldn't be that much smaller, and it would also become more complex in new ways. The advantage of the monolith has always been tighter integration, with internal efficiencies due to not having to rely on external generic libraries for shared functionality. Not being a monolith would also make it considerably more difficult to have the app be cross-platform (over desktop and mobile).

📅 2022-05-08

CC-BY-SA 4.0