Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Did we lose our way in making efficient software?

rufatmammadli.medium.com

Post reply on HN
Print view View original

121–130 of 515 posts

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

#121

Post by Arnt »

delduca wrote: post #110
BearOso wrote: post #51

Earlier quoted context omitted.

You can static-link in all of Qt. Just build Qt yourself. It can strip out all the things you don't need, even symbols from the libraries you do use, so your binary isn't going to be that big.

I do not think it is possible to have a commercial application, you have to pay Qt’s license.

Nah. But do it.

You just have to open your source, that part which depends on Qt. It's not a real problem. But get a commercial license anyway, the cost is small compared to the other costs of developing your program, and you want to be friends with them.

(There's someone on HN who lives on a single-line modification of an open source program. Trust me, source availability of the source code of your client app won't really make a difference.)

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

#122

Post by RetroTechie »

AdrianB1 wrote: post #48

We can write efficient software, but many times we decide not to. 1. Why bother optimizing when the developer's time is more expensive than RAM and CPU power? I see this a lot. 2. From the times that I can remember (mid '80) till now, only top developers write efficiently software that is efficient. Most developers are average (this is not bad, it is just an observation) and for the average developer software optimiz…

> Why bother optimizing when the developer's time is more expensive than RAM and CPU power?

The comparison should be between developer's time, and time spent (wasted) by all users combined. This depends on # of users, and how often they run the software.

For a one-off, with a few dozen users running it occasionally, yes developer's time is expensive.

For popular software with 100M+ or billions of daily users, developer time is practically irrelevant, and spending weeks/months to shave off 1/10th of a second for each user's run, would be a no-brainer.

Most software sits somewhere in between.

But... developer is paid by company not by end users. And company cares about other things than the interests of society-at-large.

So it's mostly a case of bad incentives. Companies don't care about / aren't rewarded (enough, anyway) for saving end users' time. Open source developers might, but often they are not rewarded, period.

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

#123

Post by KayL »

Wait, is it true? Did you encounter a bug? or browser extensions issues? It may not be as efficient as native, but I downloaded some sample files and repeated them until hit Google Docs limits. It is about 450 pages with some images. It is smooth and usable. There's zero delay. (and only 1000MB ram usage with many broswer extensions enabled. I think it's fair...)

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

#124

Post by contextfree »

AdrianB1 wrote: post #48

We can write efficient software, but many times we decide not to. 1. Why bother optimizing when the developer's time is more expensive than RAM and CPU power? I see this a lot. 2. From the times that I can remember (mid '80) till now, only top developers write efficiently software that is efficient. Most developers are average (this is not bad, it is just an observation) and for the average developer software optimiz…

Also, RAM, CPU and disk space are shared resources on PCs. If your computer is slow you don't necessarily attribute it to any particular program, let alone website. As Terry Crowley says here https://terrycrowley.medium.com/software-ecology-bb4653046fd...

"... 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."

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

#125

Post by berkes »

dale_glass wrote: post #78
berkes wrote: post #65

Earlier quoted context omitted.

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…

> Let's ask the question differently: what problems were solved? A few more: * Seamless internationalization. If you're a native English speaker you probably never experienced the "fun" of dealing with French and Russian in the same text document. Pre-Unicode supported English + one other language, if that other language wasn't too weird. * Lots of tiny life quality improvements. Eg, not seeing windows repaint costs…

My point is that we are improving the experience.

But that the "cost" to do so, isn't what's technically required to improve it. You can achieve all these improvements, solve all these problems, probably without much more resource usage. Or negligible added resource usage.

Therefore my conclusion is that the reason e.g. slack usage x1000 what my old IRC or Jabber cliënt used, isn't technical. It's a deliberate choice made for reasons of budget, time to market or another trade-off.

I'm certain that Slack could build a client that does all what slack does, in a client that's hundred(s) of times snappier, smaller, less CPU and memory using. But probably not with their current pace, budget, team or wages.

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

#126

Post by dale_glass »

berkes wrote: post #125
dale_glass wrote: post #78

Earlier quoted context omitted.

> Let's ask the question differently: what problems were solved? A few more: * Seamless internationalization. If you're a native English speaker you probably never experienced the "fun" of dealing with French and Russian in the same text document. Pre-Unicode supported English + one other language, if that other language wasn't too weird. * Lots of tiny life quality improvements. Eg, not seeing windows repaint costs…

My point is that we are improving the experience. But that the "cost" to do so, isn't what's technically required to improve it. You can achieve all these improvements, solve all these problems, probably without much more resource usage. Or negligible added resource usage. Therefore my conclusion is that the reason e.g. slack usage x1000 what my old IRC or Jabber cliënt used, isn't technical. It's a deliberate choice…

> Therefore my conclusion is that the reason e.g. slack usage x1000 what my old IRC or Jabber cliënt used, isn't technical. It's a deliberate choice made for reasons of budget, time to market or another trade-off.

That was never not the case.

Jabber makes a big usage of XML, which back in the day was very much seen as overkill. It requires a pretty complex parser, and increases the amount of data considerably.

They could have gone with a much more compact binary protocol with ID/length/value pairs, where there's not even field names, but say, a 16 bit integer where IDs are allocated from a central registry.

Even going back to DOS, you could shrink a program with measures like outputting "Error #5" instead of "File not found", and require the user to look up the code in a manual.

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

#127

Post by Klonoar »

drewcoo wrote: post #114
oellegaard wrote: post #13

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.

I can’t believe I’m arguing this, but: it actually might be fine UX?

As long as they’re sorted and I can jump with the keyboard, that bare-ass drop-down is probably going to “just work” with default behavior. Anything further and we don’t know the intended use case for the element itself, but on the surface… it could be fine.

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

#128

Post by goalieca »

dale_glass wrote: post #78
berkes wrote: post #65

Earlier quoted context omitted.

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…

> Let's ask the question differently: what problems were solved? A few more: * Seamless internationalization. If you're a native English speaker you probably never experienced the "fun" of dealing with French and Russian in the same text document. Pre-Unicode supported English + one other language, if that other language wasn't too weird. * Lots of tiny life quality improvements. Eg, not seeing windows repaint costs…

I don’t know about nextstep but macOS had all this stuff when I first used it 20+ years ago. It featured compositing rendering, had the apps, supported ppc/x64 in an app image, had a microkernel. I even remember it got an emulator for running ppc code on an x64.

The newest macOS still needs more memory and suffer bloat but 8GB is still perfectly useable if you avoid google chrome. 8GB is also perfectly usable for Linux too.

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

#129

Post by jokethrowaway »

zer00eyz wrote: post #105
tomhallett wrote: post #75

Earlier quoted context omitted.

$10 = 6% fee; $5 = 8% fee. Both of which are far better than apple’s fees, so that point is a bit confusing. Chargebacks = customer support. I agree with that, but if you have a B2C business which has any non-trivial revenue (OP is talking about word doc apps, so we’re obviously not talking about indie $2 side project apps), then you would already have CS anyway. I fully understand there is an opportunity cost with a…

>> then you would already have CS anyway Would you? Because I would argue that CC processing is the point where you NEED near real time CS. Before that handling customer issues can be done better through forums, and you're going to get a lot of self service support from those. >> (OP is talking about word doc apps, so we’re obviously not talking about indie $2 side project apps) Your competing with free, libra office…

5% of my support has to do with payments and it's all about refunds.

Everybody pays for stuff online

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

#130

Post by jokethrowaway »

zer00eyz wrote: post #113
littlestymaar wrote: post #99

Earlier quoted context omitted.

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 cons…

Chargebacks are a pain but are not that frequent. You need to make a way to refund your product easily discoverable because customers go unpunished.

You can use chargeback protection on stripe or use a different payment provider which absorb the 15$ fee for chargebacks

Post reply on HN