Did we lose our way in making efficient software?
71–80 of 515 posts
Re: Did we lose our way in making efficient software?
#72Re: Did we lose our way in making efficient software?
#73Re: Did we lose our way in making efficient software?
#74Re: Did we lose our way in making efficient software?
#75I 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.
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…
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 any service and where those costs get realized, but your examples don’t seem like a slam dunk in apple’s favor.
Re: Did we lose our way in making efficient software?
#76Earlier quoted context omitted.
I dont agree, there is way more help in terms of writing efficient code today than there was back in time, ive seen horrible code from that time which would not have been produced today.
What we don't teach or reward today is the behaviors and engineering process to write high quality code. A surprising number of inexperienced developers do the following: "once I get any working solution I should immediately open a PR" and let the senior engineers tell them what's wrong with it. When the big money leaves this field I hope there will be more pressure for people to adopt good engineering practices. I l…
Re: Did we lose our way in making efficient software?
#77I 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.
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…
Re: Did we lose our way in making efficient software?
#78Earlier 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…
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 a LOT of memory. Every window is present in RAM even if not being looked at so that when you switch to it you never see it paint.
* Stability. Windows 9x tried to be frugal by keeping a copy of everything in system32. That was called "DLL hell". So the current standard is that the app just packages every framework, so you may have a half dozen copies of Qt easily.
> Do we need GBs instead of MBs for that? Why?
Well, let me look at my AppImage:
3.8 GB total.
2.3 GB of dependencies. 2.1 GB is libnode, 128 MB is Qt Webengine.
1.4 GB application. 126 MB of JavaScript and UI images. The rest is mostly code.
Re: Did we lose our way in making efficient software?
#79Where 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?
Also, in the past you had to care explicitly about how much memory you allocate etc. which stopped you to think. Now you can pretend you have infinite resources because everything happens implicitly.
Compounded with this [0]:
> O(n^2) is the sweet spot of badly scaling algorithms: fast enough to make it into production, but slow enough to make things fall down once it gets there
you get what you get. Ever opened a GitHub pull request with 2000+ files changed? It hangs the M1 MBP. The solution is probably not rocket science, if someone really prioritized the fix.
[0] https://twitter.com/BruceDawson0xB/status/112038140670042931...
Re: Did we lose our way in making efficient software?
#80Earlier quoted context omitted.
Related point, do google android engineers dogfood android phones to themselves? I guess most of them would be Apple users.
Android encompasses $80 burner phones to what... like $2K flagships? It's a big target.