Live data from Hacker News

Did we lose our way in making efficient software?

rufatmammadli.medium.com

111–120 of 515 posts

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

#111
post #95

My opinion about this is that yes, we lost our way, and the reason is very simple, it is because we could. It was the path of least resistance, so we took it. Software has been freeriding on hardware improvements for a few decades, especially on web and desktop apps. Moore's law has been a blessing and a curse. The software you use today was written by people who learned their craft while this free-ride was still ful…

> 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 problems. Linux is UNIX with extra bits, and UNIX wasn't really designed with software distribution in mind, so it's never moved beyond that legacy. A Docker-style container is a natural approach in such an environment.

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

#113

Earlier quoted context omitted.

Ok Set up CC processing on the web: How much are you going to pay stripe? 2.9% + 30¢ ... that means you have to charge 10 bucks to get down to a 6% transaction fee. Quite the price floor and an interesting cap on your pricing model! What does managing chargebacks cost you? The moment your taking money your going to hire in customer service, or spend time dealing with CS. What happens when you get a chargeback, or do…

Even when using Stripe (which is a premium payment service that's more expensive than most options) you'd be better off than the 15% from Apple as long as you sell for more than $2.5. And that's not even counting the up from cost that come with Apple (subscription + the need to buy a Mac). How is chargeback being managed on Apple? I doubt they are swallowing the cost on their side, so I don't really see the differenc…

At 5 bucks a customer, you need 200k new ones a year to break a million bucks.

TO break even with apple you have about 80k a year all in cost to deal with all your refunds and charge backs.... after taxes, insurance and overhead that's 40-60k take home for a CS agent.

What is the charge back rate on digital goods? Im going to tell you that if your a small player it will be WAY higher than apple. Apple will cut a consumer off if they have a high refund rate, your CS agent will have no such insight.

%5-10 of your charges will just turn into refunds. Is that a process where you're killing license keys? Oh did you forget you now have infrastructure to run to issue and maintain said key? What is that going to cost you? Dont want to run like that... well ok then expect your return rate to go even higher. That discount CC processor is going to look at your refund and charge back rate and jack your fees up sky high (because that's the name of the game).

Once you get past a million bucks the open question is "do I do enough business to negotiate with apple". IN the case of a dry business oriented app, that has enough popularity to make that much, you might see apple willing to negotiate with you much sooner than a game dev who has sneaky buy options and huge charge back rates.

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

#114

We recently moved an old page from plain html and everything generates by the backend to react and we had a drop down take several seconds to open with a thousand or so items in it. Was like 100ms to open the entire page before. It was suggested to only display the first 100 items and let the user type in 3 characters until it started rendering. Unfortunately this is the reality for many these days. Of course instead…

A select with thousands of options sounds like terrible UX.

If the new frameworks make the problem blindingly obvious so that someone can actually justify fixing it, all the more reason to use those frameworks.

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

#115
post #14

I may be way off-base here but this is what I imagine the problem is: 1. Company executive decides their developers need top-of-the-line hardware to remain competitive in today's market 2. Developers make web apps on their company-provided M5 Ultra Pro Max 128GB RAM powerhouse laptop 3. They never test it on their father's old 2010 family PC, or at least they don't test often/thoroughly enough to realize many parts a…

You're not off base. The article was about imagined problems.

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

#116
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.

whenever I do native (native as in, compiled without going through some bytecode / VM / interpreter ...) apps for mac / windows / linux I don't have to do any of this, I just use Qt

I do as well. I program everything in C++ with Qt 6 (commercial license), compile statically where convenient, and use a single code base for all platforms (mobile, desktop, web). I handle the responsiveness of interfaces, DPI, and other micro-adjustments directly in a simple QML template.

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

#117
I liked this post by Terry Crowley: https://terrycrowley.medium.com/software-ecology-bb4653046fd...

"The classic response to accusations of bloat is that this growth is an efficient response to the additional resources available with improved hardware. That is, programmers are investing in adding features rather than investing in improving performance, disk footprint or other efforts to reduce bloat because the added hardware resources make the effective cost of bloat minimal. The argument runs that this is in direct response to customer demand.

It is most definitely the case that when you see wide-spread consistent behavior across all these different computing ecosystems, it is almost certainly the case that the behavior is in response to direct signals and feedback rather than moral failures of the participants. The question is whether this is an efficient response.

The more likely underlying process is that we are seeing a system that exhibits significant externalities. That is, the cost of bloat is not directly borne by the those introducing it. Individual efforts to reduce bloat have little effect since there is always another bad actor out there to use up the resource and the improvements do not accrue to those making the investments. The final result is sub-optimal but there is no obvious path to improving things."

Web pages/applications are probably even worse in this regard because I'm not sure users even conceptualize them as using resources on their local computers, so they don't get blamed for it (people seem to attribute resource usage only to the web browsers, not the sites themselves)

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

#118
post #54
post #17

Earlier quoted context omitted.

You can't use Qt?

Qt licensing is its own mess. For commercial software, the pricing is 350-500$ per developer, per month. Seriously [1]. The company that now owns the framework doesn't seem to acknowledge the gap between big enterprises and solo developers/smaller teams. [1] Yes, one can use Qt for commercial software without buying a license (as long as it is dynamically linked), but their marketing does everything it can to hide th…

Mess?

Here are the most commonly used options:

- Go LGPL. Sure, you will need to ship binaries and libs, but there are tools within the SDK that do this automatically for you (windeployqt, macdeployqt, etc.). And as others have stated, it is a problem that was solved years ago.

- Go Commercial to link statically. If you are a single developer, there is an annual license available for $499 (up to $100k yearly revenue).

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

#119
post #65

Earlier quoted context omitted.

> Now we measure things in GB units. 1000X bigger, but what was gained? Functionality and graphics. For instance 'dict.words' alone on Linux is 4.8MB. Arial Unicode is a 20MB-ish font. The icon for an application I work on is 400K. The Google Crashpad handler for handling crashes is somewhere around several MB. A 4K true color display is 138 times larger than 640x480x16 colors.

Let's ask the question differently: what problems were solved? With your examples, it could be: - introduce global spell checker. - have emoji? - fix blurry icons? - being able to search through crash logs? - not having to switch between windows. Do we need GBs instead of MBs for that? Why? Was that problem not fixed already? Could we not fix it in a way that didn't demand magnitudes more resources? I'm asking, becau…

The problem is that everyone here is looking at it from a software design standpoint, not a software development standpoint. Once you look from the latter it's obvious why things are the way they are: businesses are trying to cheapen out on software development costs. As a result, software quality cheapens.

For example, if disk space is abundant and very cheap, and optimizing software to use as little as disk space as possible is relatively more expensive than throwing more disk space at the problem, you shouldn't be surprised that software starts using more disk space than necessary, because what's being optimized is software development costs.

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

#120

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.

Our docker file for running some ML code at work is 6GiB. That does not include the model files. What the fuck, Nvidia? Am I downloading thousands of permutations of generated code for things I’ll never use?

If using C++, clang and boost are going to take up a substantial portion of that 6 GB
Post reply on HN