Live data from Hacker News

Did we lose our way in making efficient software?

rufatmammadli.medium.com

191–200 of 515 posts

Re: Did we lose our way in making efficient software?

#191
post #6

I want to make native apps but Apple and Microsoft seem to be trying really hard to stop me. I have to buy developer accounts, buy certificates for signing binaries, share 30% of my revenue with them for barely any reason and so on. Not to mention the mess they've introduced in their APIs - especially Microsoft. So of course we choose the much simpler, much cheaper way of the web.

> share 30% of my revenue with them for barely any reason Does the App Store collect sales tax and remit on your behalf? If it does then I think it's worth it or face registering both in the EU and UK ($0 tax threshold) as well as 50 US states (once you hit the allowed limit) will take you a long time.

30% cut for handling taxes? That's wild.

Re: Did we lose our way in making efficient software?

#192
It's interesting: minimal software is out there, but folks don't tend to choose it. I spend a fair amount of time thinking about how to be conservative in my dependencies, and this encourages a lightweight stack that tends to perform pretty well. These days, I'm favoring tools like Lua, SQLite, Fennel[0], Althttpd[1], Fossil[2], and the Mako Server[3] and find that great, lightweight, stable, efficient software is to be had, for free, but you have to go a bit off the beaten path. This isn't stuff you hear about on Stack Overflow.

In terms of frontend, which the post focuses on (Google Docs and a 30MB doc), I guess I'm conflicted. While I tend to favor native apps + web pages, I'm also a daily Tiddlywiki user, and I really think web apps have their place (heck, one idea I'm working on is a lightweight local server that lets you run web apps like Tiddlywiki). But without a doubt, Tiddlywiki is more resource intensive than Emacs (my go-to for notetaking when I'm not on TW). My tab for a 6MB Tiddlywiki file uses 155MB of RAM, and my (heavily customized, dozens of open buffers) Emacs session uses 88MB. So I do think the author has a good point.

[0]: https://fennel-lang.org/ [1]: https://sqlite.org/althttpd/doc/trunk/althttpd.md [2]: https://fossil-scm.org/home/doc/trunk/www/index.wiki [3]: https://makoserver.net/

Re: Did we lose our way in making efficient software?

#193

One problem is that we use a full word processor that's powerful enough to typeset a book to distribute basic text documents when simple markup would be just as readable, and more easily usable on a wide variety of devices (and easier to make accessible for disabled people) So when my doctor sends me a one page checklist of how to prepare for a procedure, I have to open it in a powerful word processor and since it's…

Not until long ago, we had RTF, a simple and universal rich text format that was free, simple and available on all platforms.

On Windows, Wordpad was plenty enough for most needs, came preinstalled for free and barely consumed any resources, but I understand it's no longer shipping with Windows. Office 365 is now where the money is, even for basic needs.

Re: Did we lose our way in making efficient software?

#194

In the early 90s, I believe MS Word came on a few floppy disks and the main executable was 2MB. It ran fine on a 16Mhz 386 with a total of 2MB RAM (let that sink in!) It did pretty much everything it does now, only lacked a grammar checker. (WordPerfect had one.) Now we measure things in GB units. 1000X bigger, but what was gained? We not only lost the way, we don’t even know the destination any more.

The exe for Word 2 was about 1MB. I remember it because it was by far the largest exe I had ever seen. It didn't have the red underlines for spell-checking but it did have all the other word-processing features I use now.

Re: Did we lose our way in making efficient software?

#195

“My father told me he wanted Microsoft Word on his laptop. So I told him to use Google Docs instead. When that turned out to suck, I installed Libre Office instead.” Why didn’t you just, like, get him Word? Why did you make him try to use a shitty web app that assumes everyone’s computer is brand new, then install an open-source program that’s going to be constantly playing catch-up with Word’s updates and may cause…

Aren't Microsoft trying their best to turn Word (and the rest of Office) into a shitty web app?

Totally. It’s getting difficult in Outlook to figure where window boundaries are. A lot of menus also look pretty amateurish compared to native menus.

Re: Did we lose our way in making efficient software?

#196

This seems to take a moral stance that efficient is better. However that’s not always practically true. Efficiency often means inflexible and brittle with respect to change and time. Abstraction generally trades efficiency for ease in change over time, or parsimony for the developer in exchange for expense at runtime. If it doesn’t matter - it doesn’t matter. If the goal is making a document format that is flexible e…

> Maybe as a moralistic measure it’s offensive that something lacking parsimony is practical. But from any meaningful measure - the users perspective, the developer, even the company paying for the processing - if it doesn’t matter - it literally doesn’t matter.

Except the post you're responding to was literally in response to a user problem trying to edit a 30MB document in Google Docs. So it very much does matter, from the user perspective.

> Comparing Google Docs to a program hosted on an Apollo era flight computer is obtuse to an extreme, and I would rather write my collaboratively edited documents with Google Docs than Apollo era flight computer any day no matter whether one is less parsimonious than the other.

Straw man. The post compares Google Docs to LibreOffice (a competing product), and points out that LibreOffice solves the user's problem (editing a 30MB document) and Google Docs cannot.

Re: Did we lose our way in making efficient software?

#197
post #95

Earlier quoted context omitted.

> It was the path of least resistance, so we took it. Well said. I believe many of the "hard" issues in software were not "solved" but worked around. IMO containers are a perfect example. Polyglot application distribution was not solved, it was bypassed with container engines. There are tools to work AROUND this issue, I ship build scrips that install compilers and tools on user's machines if they want but that can't…

It's very platform specific. MacOS has had "containers" since switching to NeXTStep with OS X in 2001. An .app bundle is essentially a container from the software distribution PoV. Windows was late to the party but they have it now with the MSIX system. It's really only Linux where you have to ship a complete copy of the OS (sans kernel) to even reliably boot up a web server. A lot of that is due to coordination prob…

Is it? I'm using LXC containers, but that mostly because I don't want to run VMs on my devices (not enough cores). I've noted down the steps to configure them if I ever have to redo it so I can write a shell script. I don't see the coordination problem if you choose one distro as your base and then provision them with shell scripts or ansible. Shipping a container instead of a build is the same as building desktop apps instead of electrons, optimizing for developer time instead of user resources.

Re: Did we lose our way in making efficient software?

#198

Again and again people complain about this. But it remains a fact that essentially nobody actually wants this. Developers certainly like to have their completely integrated, connected and universal computing platform (the web). And users do not seem to particularly care about performance as long as it is good enough . And that is exactly the standard that is set, software is allowed to be so bad that it doesn't reall…

Yep. The most successful startup I worked at had a SPA that downloaded 5MB bundle and preloaded a bunch of data. Took nearly 10 seconds to startup. Nobody complained about that. In fact, few people complained about a few portions of the app that had abysmal performance. It often wasn’t until 60 second load times that customers started complaining. They still raved and raved about that software because it solved an ex…

Startup time of an SPA is meaningless when it's for the sort of app you open once in the morning and then use during the rest of the day. It's a single startup-hit, and the user suffers it in between closing the tabs from the previous day and fiddling with some emails. Doesn't matter it is 10-20 seconds.

The problem with the long startup is that it tends to cloud any discussion on performance. Code loading and parsing is basically the biggest bar in the app-perf breakdown of your profiles, and thus spins this narrative that this is the thing to optimize for, because it's the biggest bang. Rather than say, responding to user selections, reducing jitter and sluggishness while scrolling, etc...

I'm starting to believe that for a large class of apps, developers should look at it as if they are writing video games: the user will tolerate the spinner before the level, but then it needs to be silky smooth after. And the _smooth after_ requires a whole class of other optimizations; it's striving for a flat memory profile, it's small ad-hoc data transfer, it's formatting data into usable layout at lower levels in the stack, it's lazy loading of content in the background, etc... Those are the areas where web-devs should be looking a

(again, this only applies for that sort of SPA; e.g read-only content, blogs and such, should display _fast_).

Re: Did we lose our way in making efficient software?

#199
> I think we lost our way of developing optimized, efficient, and performance-wise applications.

I'm not going to deny that we could do better, but it is more nuanced than that:

OP uses Word as an anecdotal example, but Word is not designed with a goal of being optimized. It is designed with a goal of being backwards-compatible to decades of history.

We cannot assume that all software shares the same goals because they simply do not. When we look at the problem any given software is trying to solve, performance optimization is almost always important, but almost never #1... #1 is "solve the problem". Doing it fast is always secondary to doing it at all.

Re: Did we lose our way in making efficient software?

#200
post #6

I want to make native apps but Apple and Microsoft seem to be trying really hard to stop me. I have to buy developer accounts, buy certificates for signing binaries, share 30% of my revenue with them for barely any reason and so on. Not to mention the mess they've introduced in their APIs - especially Microsoft. So of course we choose the much simpler, much cheaper way of the web.

> share 30% of my revenue with them for barely any reason Does the App Store collect sales tax and remit on your behalf? If it does then I think it's worth it or face registering both in the EU and UK ($0 tax threshold) as well as 50 US states (once you hit the allowed limit) will take you a long time.

If you live in the US the only entity you need to collect sales tax for is the state you live in. Despite what they may say you are under no legal obligation to collect sales tax for the other 49 states, nor the EU or UK.
Post reply on HN