Live data from Hacker News

A Plea for Lean Software (1995)

liam-on-linux.dreamwidth.org

111–120 of 136 posts

Re: A Plea for Lean Software (1995)

#111
post #98

Earlier quoted context omitted.

You seem to be choosing to engage with your own least charitable inferences rather than what reflects your counterpart's actual position. Viz: > the alternative option isn't there > I don't feel entitled. I don't have a choice in my chat app Your responses are predicated on the option being there and the person you're responding to is just not taking it. This despite the fact that his or her responses strongly sugges…

There is always an option. Threaten your employer you'll leave if they make you use Slack, quit programming and become a farmer who touches grass every day. All this Electron app complaining reads like First-World Problems(TM).

Overly-reductionist arguments are not helpful. Suggesting that I quit my job because I disagree with the tech stack of a billion dollar company might be one of the dumbest things I've seen on this site in the 15 years or so I've been here.

Re: A Plea for Lean Software (1995)

#112

If software getting larger is a sign of "progress", then someone could write a 2TB text editor right now and call it the most advanced editor ever written. Because inevitably, some day, editors with reach 2TB, right?

No worries. Once we integrate LLMs in text editors we'll get there in no time!

Re: A Plea for Lean Software (1995)

#114
post #89
post #75

Earlier quoted context omitted.

Never understood the "two pizza team" since I eat a single pizza alone.

How large are those two pizza ? I can eat a small 8" alone but a slice from a jumbo 18" is enough... Also if someone eats a 18" pizza alone, is he a 10x programmer?

That's why software development teams are bigger in Chicago than in Rome or Naples. The size of the crust is bigger in Chicago-style pizzas, whereas italian pizza has a thinner crust.

Re: A Plea for Lean Software (1995)

#116
post #53

Earlier quoted context omitted.

I blame Firefox and other web browsers which deny loading JS files if your page was loaded from file://. If you could simply run an HTML file from your hard drive and have a fully functional web application, you wouldn't need Electron.

They would also, presumably, need to provide a whole native OS api for a variety of syscalls (etc.) that wouldnt otherwise be supported.

Exactly. Electron provides a backend which allows filesystem access, device access, etc. which a plain web app cannot get access to.

Re: A Plea for Lean Software (1995)

#117
post #53

Earlier quoted context omitted.

I blame Firefox and other web browsers which deny loading JS files if your page was loaded from file://. If you could simply run an HTML file from your hard drive and have a fully functional web application, you wouldn't need Electron.

They would also, presumably, need to provide a whole native OS api for a variety of syscalls (etc.) that wouldnt otherwise be supported.

They could ship a web server that listens on 127.0.0.1 and launches the standard browser

Re: A Plea for Lean Software (1995)

#118

Walled gardens like Apple’s App Store could charge app developers based on resource usage. At the very least they could add a resource (battery especially) usage traffic light. That said, it would encourage small apps rather than efficient apps.

> Walled gardens like Apple’s App Store could charge app developers based on resource usage.

They’re taking enough heat charging for (what they claim is) the costs of the services they do provide. The absolute hurricane of doom saying that would be sparked by charging for the resources the app uses on the users machine would probably take down the internet for a day or two.

Re: A Plea for Lean Software (1995)

#119

We need something that dictates how commercial software can be distributed, installed, and what it can automate and do without your consent. Software increasingly adds itself to "run at startup" automatically. Nobody needs to have a bunch of startup user interface apps. It is completely unnecessary and has little purpose other than data collection. A work VPN I have to use requires a startup background service. I'm n…

Thinking about this recently and I’m wondering if part of this is that OS developers have stopped providing common services as part of the OS and part of it is that many apps aren’t coded to the native services the OS provides in the first place.

Most apps that throw a startup process in the background are probably aiming for (in part) an auto update service. Why don’t OSes provide a service that an app can register a URL to check for updates at? Yes the App Store does this for apps installed there, but outside the App Store there’s no way to do that and to my knowledge nothing like that exists for Linux or windows (barring the few things that seem to be available in windows updates).

The other part of course would be even if the OSes did provide this, who would write code for it? Maybe electron would have a function to register with the os native endpoint but until/unless they did, would any electron devs code for it or would they keep writing their own services?

Re: A Plea for Lean Software (1995)

#120

Very few people ever even attempt to write "lean software". The definition is a little nebulous, but "software without bloat" is a good one. This means that you have few dependencies, and the ones you have themselves have few dependencies, for a starter. But right there you have the first problem, which is that dependencies grow stronger with the number of users, and the number of users grows with applicability, henc…

It's more nuanced than that. A large share of software bloat is tied to awkward combinations of device convergence and modularity. I'll give an analogy with pens:

* Dip pens and brushes, the original inking tools, rely on the user having a pot of ink available and some fine-pointed object capable of holding the ink. It's very simple, but this two-piece design limits situational use and requires the tip to be scrubbed off like used silverware. But you are relatively unlimited in what you put in the ink and the style of the nib, making it one of the best artist's tools even today.

* Fountain pens innovated by creating a reservoir inside the pen, and a feed mechanism. This creates a modular pen body, allowing the user to customize a body with different inks, reservoir mechanisms(cartridge, piston, etc.) and nibs. However, the ink has to be liquid enough to gravity feed, and cleaning the pen and fixing feed issues is a more involved process, making fountain pens reputed as a temperamental platform with many tradeoffs for portability.

Disposable ballpoints and markers devised a one-size-fits-all solution: make refills be the "whole pen", comprising tip and reservoir, and leaving the body as just a shell. This has allowed the designs to become very intensively engineered, with customized gel ink formulas, rubberized marker tips, etc. However, most of these designs are not made for longevity in some dimension - gel refills dry up, oil-based refills fade, marker tips get smashed. As well, there is a limited range of line styles achievable from a ball or marker.

Lastly, there is a recurring Kickstarter scam in which a "printer pen" is demonstrated, with selectable RGB color. Besides the fact that this product doesn't really exist, it would make the pen into something even more complex than a fountain pen.

So in solving technical problems, I think computing necessarily converges on answers similar to how pens are engineered: if you want it to be very simple and exacting, it's a dip pen, and you have to "plug it in" each time. If you want it to be easy-use, to last a while and to get out of the way, you want a pack of Bic ballpoints. If you want some mix of those things, you end up in the space of markers or fountain pens.

But software lets us make the RGB pen, actually have it work and be used by people. And that is a problem, because now our expectations are that nobody should have to use a dip pen ever again, when a large part of the population didn't even get exposed to them and lacks the agency to choose.

Post reply on HN