Live data from Hacker News

Did we lose our way in making efficient software?

rufatmammadli.medium.com

101–110 of 515 posts

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

#101
post #44

Earlier quoted context omitted.

Only if you want to distribute via the App Store. There’s also TestFlight and distribution of source code I believe if you want to avoid that.

Both of these are completely false. Testflight distribution without a developer license is impossible. Asking users to compile the app themself is infeasible, as the XCode toolchain is upwards of 18gb and they will be required to compile it once every week to keep it on their device. The developer fee is unavoidable — even with EU intervention

Even signing for your own device (if you manage to get your users to do this) requires an Apple ID in good standing.

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

#102

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…

The thing that makes me crazy is that the thing that we do on computers are basically the same each year, yet software are more and more heavy. For example just in 2010 a Linux distribution with a DE just started did consume 100Mb of RAM, an optimized version 60Mb of RAM. I remember it perfectly. I had 2Gb of RAM and did not have even a swap partition. Now just a decade later, a computer with less than 8Gb of RAM is…

Windows 98 was often running on fragmented disks. I recall it taking minutes before I could do useful work. And having multiple apps open at once was more rare. While possible it often ended in crashes or unusable slowness.

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

#103
I hope to keep seeing posts like these. I believe software "bloat" is a serious issue that should be handled, however if you look at SWE job listings it's not even remotely a concern for employers IMO. Your encouraged to understand complex and heavy frameworks and performance/optimization is not even a consideration.

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

#104

There is perhaps some irony in the fact that this blog was posted to Medium, which serves 10.88 MB for a 265-word article.

And browsers are larger that some operating systems. And talk about a closed off ecosystem ... WASM is still crippled and JS/HTML/CSS is your only real viable option for web development. The web feels like 2005 again. Only thing is, this time the popups are embedded in the page...

I think I would prefer 2005 web again. I'd probably be able to see more of the internet. I use heavy DNS filtering, no javascript on untrusted sites, no cookies, no fonts, VPN and so on. With cloudflare blocking me I basically can't see the majority of websites.

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

#105

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…

$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, Zoho writer (shockingly popular)... I would not know how to price the product to compete... 2 bucks a month as a trial? Would I pay 10 bucks a year if you were great? IF you got said productivity app past 100k users, getting to a million isnt a stretch (you have velocity and popularity).

Unless your doing something really slimy, your going to be able to get a better rate out of apple if you ask your rep.

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

#106
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 enough to accommodate history, concurrent editing, various layouts and embedding, etc, all this comes with abstractions that add inefficiency. The trade off is ease in adding and changing to the format and the software that consumes and produces the format. If the consequence in the real world is effective unobservable in any material way, who cares?

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.

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.

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

#107
post #27

Office 365 probably would have worked. Microsoft's proprietary format is handled best by Microsoft. Also, cloud-based synchronization using CRDTs is a complex problem that is significantly more complex than just loading the document. Can't claim we are going backwards when comparing apples and oranges.

That's clutching at straws tbh. I have a "native" google docs spreadsheet that has atm 4 sheets, all at 50 lines or less. No fancy formulas except sums. It just tracks hours for billing.

It uses 500 Mb of ram fresh, and in a couple weeks it goes up to 1.5 to 2 Gb and I have to kill the tab and reopen it.

This is the modern javascript world...

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

#108
post #47

Earlier quoted context omitted.

The reason that Apple and Microsoft require all this is also that native apps have a lot more access to the system.

This doesn't matter. Notarization doesn't do anything against a dedicated attacker willing to commit illegal acts. Notarization is supposed to deter malware by a combination of static/dynamic analysis and attaching some real-world legal entity to any signed binary so law enforcement can follow up on if malicious activity is happening. Analysis is not bulletproof and can be worked around. The legal entity requirement…

Notarization does do things against attackers, yes.

Firstly, stolen CCs tend to get reported especially if you make a big purchase. If you use a stolen CC to buy a developer certificate then it's going to get revoked the moment the real owner notices, and then your apps will be killed remotely by Apple before they've even been detected as malicious.

Still, the big win of notarization is that Apple can track down variants of your malware once it's identified and take them all out simultaneously. They keep copies of every program running on a Mac, so they can do clustering analysis server side. On Windows there's no equivalent of notarization, but the same task is necessary because otherwise malware authors can just spin endless minor variants that escape hash based detection, so virus scanners have to try and heuristically identify variants client side. This is not only a horrific resource burn but also requires the signatures to be pushed out to the clients where malware authors can observe them and immediately figure out how they're being spotted. Notarization is a far more effective approach. It's like the shift from Thunderbird doing spam filtering all on its own using hard-coded rules, to Gmail style server side spam filtering.

> All of these requirements are just a way to lock down access to the walled garden

I've been hearing this for over a decade now. In the beginning I believed it, but it's been a long time and Apple have never made macOS a walled garden like iOS is. There's no sign they're going to do it either. After all, at least some people have to be able to write new apps!

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

#109

Where in that stack is the biggest loss of performance? DOM? Javascript? Browser? Or is it because everything needs to sync to the cloud as you edit it?

It's going to be a mix of:

1. JS doesn't support multithreading, nor many other features that are useful for performance (e.g. mmap). This severely limits what you can do and makes it hard to scale up by parallelizing.

2. JS is a very pointer heavy language that was never designed for performance, so the CPU finds it harder to execute than old-school C++ of the type you'd find in Word. It's hard to design tight data structures of the kind you'd find at the core of Word.

3. The browser's one-size-fits-all security model sacrifices a lot of performance for what is essentially a mix of moral, legal and philosophical reasons. The sandbox is high overhead, but Docs is made by the same company as Chrome so they know it isn't malicious. They could just run the whole thing outside of the sandbox and win some perf back. But they never will, because giving themselves that kind of leg up would be an antitrust violation, and they don't want to get into the game of paying big review teams to hand out special Officially Legit™ cards in the same way that desktop vendors are willing to do.

4. The DOM is a highly generic, page oriented structure, that isn't well suited for app-like UIs. As a concrete example Chrome's rendering pipeline contains an absolute ton of complexity to try and handle very long static pages, like tiled rendering, but if the page takes over rendering itself like Docs does then all this just gets in the way and slows things down. But you can't opt out (see point 3).

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

#110
post #51

Earlier quoted context omitted.

But then you have to use c++ or Python, and figure out a good way to ship 10 dlls

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.
Post reply on HN