💾 Archived View for gemini.hitchhiker-linux.org › gemlog › re_lagrange_and_bloat.gmi captured on 2024-02-05 at 09:47:45. Gemini links have been rewritten to link to archived content

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

Re: Lagrange and Bloat

2022-05-13

There's quite a long thread going on it seems.

On the one hand, we have this (on the Unix philosophy)

That said, Lagrange objectively breaks that pattern and therefore is subjectively starting to sound bloated, in my opinion. Don't get me wrong, like I said above, Lagrange is awesome. I use it every single day. At what point, though, should we stop to consider if it is following the same path to complexity as web browsers did? The root cause of that is more HTTP (Hypertext Transfer Protocol) itself, so at least we don't have that problem here in Gemini. That's my take, wholly from the perspective of looking at its feature list.

gemini://ainent.xyz/gemlog/2022-05-07-critique-of-lagrange.gmi

And then we have Skyjake's response, which I quite agree with.

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.

gemini://skyjake.fi/gemlog/2022-05_bloat.gmi

In praise of Lagrange

I'm writing my own smolnet client, but that has nothing to do with any perceived shortcomings of Lagrange. I actually use Lagrange quite heavily, and it has inspired a number of features in Eva. Skyjake is exceptionally modest in that he seems to think the Android port of Lagrange is not terribly great. My feeling is that it's already, even in pre-release form, the best client on Android. The fact that it runs cross platform is amazing, and a testament to fundamentally great programming, and the best that C has to offer.

When I think of bloat, I don't count lines of code. When it comes to a gui application I'm looking for an interface that is simple enough to be easily discoverable. By that I mean that one should be able to install the application and start using it without reading a manual first. You don't generally use all of the application's advanced features this way, at least not at first, but we've probably all been frustrated before by a dense user interface with endless heirarchical menus and multiple toolbars that might be incredibly powerful, but makes it impossible to fire it up and just go to work.

Lagrange most definitely does NOT have that problem.

On lines of code

C is one of the more verbose languages to begin with, as it does not have the abstractions that a lot of more modern languages take for granted.
10k lines of code really isn't that much (for waht you get)
Gui programs are necessarily more complex.
Multi platform applications are even more complex.

As a comparison, at it's current state Eva is 3197 lines of code, and the underlying GemView library is another 2366 LOC. That's over half of Lagrange already, aaannnddd...

Gtk+ is doing a lot of the heavy lifting.
Eva doesn't have the feature set that Lagrange does (although it's steadily becoming more capable).
Eva is only theoretically cross platform at this point. I develop it on Linux and have tested it on FreeBSD. It will most likely run on MacOS and Windows if one were to compile Gtk+ first. Android and IOS support will probably never happen.
I'm not even counting any other Rust crates in that total. Adding my Rgba-Simple crate adds another 729 LOC, and I'm fairly liberally using a number of crates that I didn't author myself. I suspect that all told it's already beefier than Lagrange.

On the Unix philosophy

I think that the Unix philosophy is not a great goal for graphical applications. I've been in the Unix world for over 20 years now, and my feelings on the Unix philosophy have evolved in that time. Let's remember that we've had 50 years of progress in the interim. Gui applications were not taken into account in 1970. Storage was tiny and expensive. The importance that networking would come to play was not yet understood. Finally, and this is important, Unix was invented by really smart nerds who do not represent the average person's ability.

I think Benno Rice makes some great points in his talk, "What Unix cost us". Sorry for the evil site link, but the other places I've seen it posted have teriible bandwidth in comparison.

https://www.youtube.com/watch?v=9-IWMbJXoLM

Benno is a long time FreeBSD contributor and Unix expert. I don't always agree with him, but I do agree that things can and should evolve. It turned out that Unix made a grreat base for an operating system and has managed to continue to work well for us for a much longer time than anyone expected, but we can and should move things forward from time to time as we find new ways of doing things. If we only ever look back, and tie ourselved rigidly to old ways of doing things, we slow or even stop progress.

What I really love about Unix

In over 20 years time using Unix and it's clones I've made some discoveries. The Unix philosophy is all right, but it's not the best thing about Unix. It's not even in my top ten anymore. More so than the Unix idea of small and simple modular programs, I appreciate the following (in approximately this order).

Open source is a better development model. Sure, there's been proprietary Unix systems. They're all dead now, while Linux and BSD live on.
The Unix filesystem is worlds better than Windows. Windows has to maintain a registry to know where the executables and libraries are, while on Unix we have known paths that we can just drop those components into. Over the years we've expanded on that to include things like standard configuration folders, architecture inependent data files, etc.
User and group priviledge separation was baked in from the start.
Development as a use case is a first class citizen on Unix. To develop for Windows or Mac you are encouraged to get and use proprietary tools and sign a bunch of EULA's. And you can't read the source, so you have to just trust the API docs they give you.
If you don't like the interface, you're free to install a different one or write your own.

On complexity

Complexity has become a dirty word in certain circles. But I want to point out that it is sometimes justified, and sometimes in fact necessary.

I've programmed in a number of different languages. I can do a bit with C, but I prefer Zig and most of all Rust. I've given oldschool languages like Fortran a go, and tried out Hare the day after Drew Devault announced it. My strong preference for Rust is because the language has managed to find a way to allow you to write close to the metal while using a lot of high level abstractions. Hare does not have generics. Neither do Fortran or C. I want my algabraic types (enums and tagged unions) and I want a strong type system that enforces code correctness.

I think C++ fails not due to complexity, but due to attempting to retrofit those concepts onto an existing language. It wasn't really designed but rather haphazardly grew as more and more bits were added. Some of those bits were mistakes, but they left them in after coming up with a replacement because hey, someone might be using them. It's messy. Rust and Zig, in comparision, feel engineered. Sure they're more complex, but the complexity is there to enable you to write less verbose and better organized code that is easier to maintain. You are forced to consider corner cases and failure modes, leading to more reliable software.

I'm a big fan of the Ford flathead V8. I've seen one that was locked solid fixed with a sledgehammer. That said, they made very little power and used a lot of gas. You had to take the heads off from time to time to de-coke the cylinders. Cracked blocks were common due to the way the exhaust routes through the block. My F150 has an aluminum block with steel cylinder liners and overhead camshafts. It also has close to 200k miles without a rebuild and is not only more powerful than a flathead but gets better gas mileage. I can deal with the additional complexity because what you get in return is a better experience all around.

Nostalgia causes us to look back on old technologies with the proverbial rose tinted glasses. But if we want to build and use the best tools going forward it pays to evaluate things with a more critical eye. Complexity can be bad if an engineer is overreaching and delivers something that is less refined as a result of that complexity, but overly simplified programs tend to create more complex workflows.

Conclusion

I can see both sides of this. At one time I would have been the guy talking about "simple programs that only do one thing". But really, until you actually write a simlilar program you're not in a great position to evaluate the decisions that went into writing something like Lagrange. My hat's off to Skyjake, because he has given us a remarkable piece of software in Lagrange. It sets a high bar, and has been a great source of inspiration for me when writing my own client.

Tags for this page

All content for this site is licensed as CC BY-SA.

Finger

Contact