[HN Gopher] Did we lose our way in making efficient software?
___________________________________________________________________
Did we lose our way in making efficient software?
Author : rumad
Score : 99 points
Date : 2024-04-28 16:22 UTC (6 hours ago)
(HTM) web link (rufatmammadli.medium.com)
(TXT) w3m dump (rufatmammadli.medium.com)
| BobbyTables2 wrote:
| 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.
| teaearlgraycold wrote:
| 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?
| baobabKoodaa wrote:
| *Docker image, not Dockerfile
| sgarland wrote:
| Spoiler, they're inlining weights with a heredoc.
| stackskipton wrote:
| If you look at the build, yea, it includes everything and
| kitchen sink. No one cares to parse it down because in most
| cases, the big GPU servers running this have plenty of hard
| disk space and since it's a long running container image in
| most cases, the pull time isn't considered big enough problem
| for most people to fix.
|
| Prime example of "Hardware is cheap and inefficiencies be
| damned"
| DrFalkyn wrote:
| If using C++, clang and boost are going to take up a
| substantial portion of that 6 GB
| rumad wrote:
| I completely agree. I believe it is still not too late to set a
| destination for the future. But, because of the hardware
| breakthroughs which are good, no one thinks about software
| efficiency anymore. They will add another GB/TB to the specs to
| avoid any bottlenecks.
| dale_glass wrote:
| > 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.
| MonkeyClub wrote:
| >> Now we measure things in GB units. 1000X bigger, but what
| was gained?
|
| > Functionality and graphics.
|
| And massive amounts of telemetry.
|
| But now functionality is moving to the cloud, we'll just be
| stuck with gigabytes for graphics and telemetry.
| berkes wrote:
| 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, because I highly doubt that there's a technical
| reason that requires an improved piece of software or a
| solved problem,to require magnitudes more resources.
|
| Sure, slack is far superior in UX to IRC. But could we really
| not get that UX without bloatware hogging my CPU, taking
| hundreds of MBs installation size and often biting off
| significant chunks of my memory? Is that truly, technically
| impossible?
| dale_glass wrote:
| > 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 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.
| berkes wrote:
| 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 client 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.
| dale_glass wrote:
| > Therefore my conclusion is that the reason e.g. slack
| usage x1000 what my old IRC or Jabber client 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.
| goalieca wrote:
| 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.
| Rury wrote:
| 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.
| giantrobot wrote:
| While plenty of software is overly fat, you hit the nail on
| the head.
|
| A Word document isn't just text and some formatting sigils.
| Editing isn't just appending bytes to the end of a file
| descriptor.
|
| It's a huge memory structure that has to hold an edit history
| so undo and track changes works, the spelling and grammar
| checker needs to live entirely in RAM since it runs in
| realtime as you edit, and the application itself has
| thousands of not millions of allocated objects for everything
| from UI elements to WordArt. The rendering engine needs to
| potentially hold a dozen fonts in memory for not just the
| system but any specified but not immediately used fonts from
| the base document template.
|
| It's not like Google Docs is any lighter on RAM than Word.
| Features require memory. Fast features are usually going to
| require more memory.
|
| People can use AbiWord if they want a much slimmer word
| processor. They could also just use nano and Markdown if they
| wanted even slimmer. But a lot of people want document
| sharing over the Internet with track changes, grammar
| checking, and the ability to drag in and edit an Excel
| spreadsheet.
|
| The features used in native software follow a bathtub curve.
| But not just one but several. No two groups necessarily use
| the same sets of advanced/uncommon features.
| ptx wrote:
| > _the application itself has thousands of not millions of
| allocated objects for everything from UI elements to
| WordArt_
|
| There are ways to optimize those things, though, which
| developers might not be bothering with anymore. The Design
| Patterns book used a word processor as the example when
| explaining the flyweight pattern for efficiently
| representing lots of objects. OLE objects like WordArt
| support different states[0] and don't necessarily have to
| be active at all times.
|
| [0] https://learn.microsoft.com/en-
| us/windows/win32/com/object-s...
| arprocter wrote:
| A while ago someone dropped off an old PowerBook Duo for
| disposal - I had to fire up Word 5.1 just for nostalgia reasons
|
| I saw it described once that software is like a gas - it
| expanded to take up the space we now have
|
| You see it with live distros too. They used to be 700MB to fit
| on a CD-R, but now it's getting rare to find one that'll fit on
| a 2GB USB; although yay for 'minimal' gaining ground
| ale42 wrote:
| A few years ago, as a 1st April joke, I set up a DOS/Windows
| 3.11 disk image on our PXE network boot server. It included a
| functional Word 6 for Windows, and the gzipped image was
| fitting in 12 MB... PCs back then could still boot without UEFI
| (and run Windows 3.11 if it was properly configured). It booted
| almost instantly. Same for opening Word.
|
| Having used that version of Word when it was the latest one, I
| can say the current ones have quite some added functionality
| (lots of very tiny things, and a few bigger ones), but I'm
| totally sure the same could be done with 10x less memory usage
| if MS would care about it. But there's no incentive to do it.
| Computers are faster and have lots of memory, and we don't
| depend on floppy disks any more. It would just cost them more
| money. Not saying that this is a good thing (I think the
| opposite, especially that I start thinking that software bloat
| might have a non-neglectable environmental impact), but as long
| as nobody complains strong enough (or as long as the EU doesn't
| come out with an anti-softare-bloat law... seems just a dream
| but who knows), that wont change. And I can clearly remember I
| had the same bloat-software feeling when I tried Office 2000 or
| XP, compared to Office 97, so there's nothing so new here.
|
| As a final note, I've recently seen the source code of MS Word
| for Windows 1.0 on a GitHub repo (MS released it, see original
| release on Computer History Museum:
| https://computerhistory.org/blog/microsoft-word-for-
| windows-...). It was pure C, with even very large parts of code
| written in assembly! But the code is really ugly... totally
| incomparable to current C or C++ coding standards, patterns and
| language capabilities.
| jesse__ wrote:
| > We not only lost the way, we don't even know the destination
| any more.
|
| Hah! Good one. It's unfortunate, but true.
| mihaaly wrote:
| Basically what we had in Word 6 is what I use today in the
| newest Words.
|
| It only takes longer to use while finding what I want among the
| bloated set of other things added.
| jedisct1 wrote:
| Remember the QNX demo floppy?
| seanparsons wrote:
| Yup, that felt incredible even at the time, let alone now.
| nappy-doo wrote:
| I recreated that in grad school, also using QNX. We set it up
| to run a paging (POCSAG) system that you could put the floppy
| into any computer, hook up a DSP board and modulator, reboot
| the machine and you'd have a paging system. My advisor showed
| it to Andrew Viterbi, and got us grant.
|
| When I went to recreate it, I contacted QNX and asked if I
| could speak to the guy who did the work, and he had died the
| year before. So, I just took apart his floppy, and figured out
| how he did it.
|
| The things you can do when you invest your time 100% in
| something.
| tonymet wrote:
| Yes because we promote blog posts on "idiomatic ruby" and
| "premature optimization is the root of all evil". "Performance is
| less important than dev time".
|
| We used to have developers who took less time and wrote better
| code.
| dustymcp wrote:
| 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.
| throwaway35777 wrote:
| 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 love to work with folks who put good effort into trying to
| make high quality changes. Personal initiative and ethics are
| how high quality software gets written.
| giantrobot wrote:
| The process you're describing is the exact thing you want
| to happen: junior developers are trying to learn to write
| better code. Why should they waste their time researching
| not their code base when they can instead learn off their
| code base from people experienced with it?
| Zpalmtree wrote:
| These are all true
| s1k3s wrote:
| 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.
| rini17 wrote:
| You can't use Qt?
| a1o wrote:
| You will still be in binary sign hell and Windows Defender
| may wake up one day and decide your app is a virus "when it
| does X", which is exactly it's business case. Complaining to
| MS will do nothing since their online thing will check and
| not find anything. Boom, entire software business gone for
| reason out of control. Doesn't care about your signed
| certificate too.
| hsbauauvhabzb wrote:
| I've always been curious if this counts as decimation,
| espionage or antitrust?
| injuly wrote:
| 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 that fact.
| Also, the newer additions to Qt do not fall in this category
| - for those, you _have_ to pay.
| pjmlp wrote:
| Imagine that, having to pay for the tools one has to use
| for their work, what an abuse.
| turrini wrote:
| 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).
| Veserv wrote:
| That is 4,200-6,000 $/yr. In the US, a junior developer in
| a software company costs (all-inclusive, not just salary)
| around 150,000-200,000 $/yr. That is 2-4% of yearly cost on
| tooling. That is not very much.
|
| It might not be worth the price, but that is hardly
| ridiculous. It is quite believable to get a 4% productivity
| improvement from appropriate tooling. You need to do a
| cost-benefit analysis to determine the answer to that
| question.
| jcelerier wrote:
| 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
| 01HNNWZ0MV43FF wrote:
| But then you have to use c++ or Python, and figure out a good
| way to ship 10 dlls
| BearOso wrote:
| 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.
| delduca wrote:
| I do not think it is possible to have a commercial
| application, you have to pay Qt's license.
| Arnt wrote:
| 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.)
| ale42 wrote:
| > There's someone on HN who lives on a single-line
| modification of an open source program
|
| Now I want to know more about this :-)
| Arnt wrote:
| He's a nice guy. If you want your company to buy his
| product, you send your boss a link to the product's home
| page (which doesn't say "open source") and tell your boss
| that this product is great. Your boss looks at the
| pricing and description, and says ok.
| Maxatar wrote:
| You can statically link Qt in compliance with the LGPL.
| The LGPL only requires that users are able to substitute
| the LGPL'd portion of an application with an alternative
| and compatible implementation.
|
| Using a shared object/DLL is the traditional way of doing
| so, but you can also accomplish this by providing the
| object files for your application to allow users to link
| their own substitutions statically.
|
| The FSF explicitly permits this as documented here:
|
| https://www.gnu.org/licenses/gpl-
| faq.en.html#LGPLStaticVsDyn...
| jcelerier wrote:
| I ship apps that statically link against Qt, but even if I
| didn't it's not like "shipping DLLs" wasn't a solved
| problem two decades ago
| turrini wrote:
| 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.
| bobajeff wrote:
| What about code signing. Won't people that run your programs
| want to do so without the OS claiming it will harm their
| computer?
| greenthrow wrote:
| "Barely any reason"... except they created and maintain the
| entire plarform and tooling that you're building on. And in
| Apple's case they give it away for free with any mac.
|
| I'm old enough to remember when buying development tooling for
| DOS or Windows was $$$$$$
| cma wrote:
| They had a $100 yearly dev fee for ios.
| mattl wrote:
| 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.
| cma wrote:
| Sounds much less generous than OP.
| internetter wrote:
| 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
| Nextgrid wrote:
| Even signing for your _own_ device (if you manage to get
| your users to do this) requires an Apple ID in good
| standing.
| glass-z13 wrote:
| Can i borrow your compiler for a few days?
| cmiles74 wrote:
| Apple started giving away the development environment because
| they had such an anemic software ecosystem. They had a
| handful of OpenSTEP developers and a larger crowd of die-hard
| Mac people, the successful ones mostly moving away from the
| platform.
|
| Today Apple is taking percentage of every dollar made from
| application developers who participate in their App store and
| they are making it increasingly difficult to avoid this with
| every release. IMHO, they are making far more dollars today
| than they ever did selling development hardware and SDK
| licenses.
| mattl wrote:
| You don't have to do any of that for a native Mac app. Signing
| it is a good idea but not required and you can distribute it
| from your own website or even from GitHub/Lab where you can
| tell people it's not notarized and they'll need to command
| click and open it the first time.
| EGreg wrote:
| The reason that Apple and Microsoft require all this is also
| that native apps have a lot more access to the system.
| Nextgrid wrote:
| 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 is also trivial to nullify. At
| least in the UK, the company registration authority charges
| a nominal fee (payable by credit card - stolen if
| necessary) and puts you on the company register. Dun &
| Bradstreet scrapes that and that's how you get the DUNS
| number necessary to register for an Apple dev account. All
| of this is trivial to get through if you don't mind
| breaking the law and making up a few fake documents and
| providing a stolen CC (and assuming you're already planning
| to break the law by distributing malware, this is not a
| problem).
|
| Finally, even if the "legal entity" bit was bulletproof,
| law enforcement just doesn't give a shit about the vast
| majority of online crime anyway.
|
| All of these requirements are just a way to lock down
| access to the walled garden and put as many roadblocks to
| laymen trying to make their own software (in favor of big
| corps) masquerading as security theatre.
| mike_hearn wrote:
| 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!
| cmiles74 wrote:
| In my opinion, this will become harder and harder to do with
| every release of Windows and MacOS. I wouldn't count on the
| average customer of these vendors being willing to shop
| outside of their plaatform's app stores forever.
| silverquiet wrote:
| I work at a place that ships an app to both Apple and Microsoft
| Desktops (we could even do Linux is there was ever any demand
| for it). We use this old thing called Java which still seems to
| work. I don't develop it though so I guess I don't have to
| worry about too much of my resume getting caught up with
| unfashionable languages (let's face the facts about what most
| tech these days is trying to advance - promotions - not the
| state of the art).
| colecut wrote:
| OP is obviously talking about mobile apps.
| Sardtok wrote:
| Yeah, that Microsoft App Store on mobile is a b**h.
| zer00eyz wrote:
| Ok
|
| Set up CC processing on the web:
|
| How much are you going to pay stripe? 2.9% + 30C/ ... 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
| a refund? Most of the time you loose money (processing fees
| etc)
|
| If your under a million bucks a year apple is 15%. If you're
| building a low price app or a value add app, odds are that
| apple is going to be a far better deal for you than doing it on
| your own.
| tomhallett wrote:
| $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 any service and where those costs get realized, but
| your examples don't seem like a slam dunk in apple's favor.
| zer00eyz wrote:
| >> 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.
| jokethrowaway wrote:
| 5% of my support has to do with payments and it's all
| about refunds.
|
| Everybody pays for stuff online
| exe34 wrote:
| Do any of these problems go away when you sell in the walled
| garden?
| paulddraper wrote:
| > apple is going to be a far better deal
|
| ?
|
| Your math seems to show the exact opposite.
| littlestymaar wrote:
| 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
| difference between what'd get with a bank: you're losing the
| money anyway.
| zer00eyz wrote:
| 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.
| jokethrowaway wrote:
| 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
| api wrote:
| The native world also refuses to create a standard UI API,
| making everyone use either Qt or Electron because sorry writing
| it over again for each platform is a hard "no." Not even big
| companies do that anymore.
| jwells89 wrote:
| Why would platform maintainers want to encourage the lowest
| common denominator apps that such an API would undoubtedly
| result in (as a standardized UI API by definition cannot
| leverage platform strengths)?
|
| Apps like that get made anyway but as it stands at least
| there's a healthy crop of smaller/indie native alternatives
| which often best the behemoths in UI/UX. That would likely
| disappear with the addition of a standardized UI API, as it
| would probably also come with the abandonment of the old
| specialized APIs.
| Rochus wrote:
| Apparently, people prefer to buy expensive devices that
| eavesdrop and patronize them. As long as this continues and
| people don't run away from these manufacturers, they will
| continue with the trend and patronize people even more.
| KittenInABox wrote:
| Unfortunately, yes, having one's personal information
| accessible to large, private companies really doesn't matter
| to most people. The only people I know who really care about
| this stuff are tech people, stalking victims, and victims of
| domestic abuse. [Admittedly this is becoming more aware for
| women trying to get abortions, but they're also a minority
| shamed to silence most of the time.] This isn't going to
| change until there are real, public, personal stakes for the
| majority of people.
| hn_version_0023 wrote:
| The alternative that exists today that I can buy and all the
| apps I need for work will actually exist and function
| correctly is called...
| bojan wrote:
| Fairphone 4.
| antiframe wrote:
| GrapheneOS for mobile. Any Linux distro on desktop.
| Rochus wrote:
| > _all the apps I need for work_
|
| The whole thing is like an intentional vicious circle.
| People buy the systems because certain applications are
| available on them (or rather because that's what everyone
| does), and the application manufacturers support the
| systems where the most customers are expected. But if one
| takes an impartial look at which applications or functions
| are really needed for a company, there are certainly
| alternatives.
|
| Unfortunately, the open source community sabotages itself,
| e.g. by constantly changing the ABI of essential functions
| and thus undermining the portability of non-open source
| applications (see e.g.
| https://news.ycombinator.com/item?id=32471624).
| LAC-Tech wrote:
| I run desktop linux and I've had no issue with joining zoom
| or teams calls.
| Aaron2222 wrote:
| > I have to buy developer accounts
|
| The Apple Developer Program is only needed for macOS if you
| want to do sign your binaries or distribute through the Mac App
| Store. And you only have to pay Microsoft if you want to
| publish to the Microsoft Store (or use Visual Studio if you're
| a company that has more than 5 Visual Studio users, more than
| 250 computers, or more than $1 Million USD in annual revenue).
|
| > buy certificates for signing binaries
|
| Fair (though both Windows and macOS will run apps that haven't
| been signed, with more warnings of course).
|
| > share 30% of my revenue with them for barely any reason
|
| Only if you use their stores (Mac App Store or Microsoft
| Store), and it looks like the Microsoft Store won't take any
| cut if you do your own payments and it's not a game.
| lr4444lr wrote:
| I think about this a lot, and the conclusion I've come to is that
| the market (simply meaning the popularity) rewards features and
| intuitive UI above everything else. I think we've been on this
| trajectory for some time: getting users with less and less actual
| computer literacy to do more and more with computers.
| rrr_oh_man wrote:
| While eroding that same literacy for the future generation
| ip26 wrote:
| I do wish fast and responsive UI was included in what's
| rewarded
| mihaaly wrote:
| I wonder if market rules of satisfying user needs and demands
| is operational here still instead of shoving down things of
| user's throats ... actually no need to shove, they swallow
| anything shiny or coming with loud fanfare. It is spectacular
| what users are willing to work with, wrapping their world
| around the needs of the poorly made and sometimes even
| offensive software ...
| asvitkine wrote:
| This just sounds like an inefficiency in Google Docs. Native
| software can also be inefficient, even if it's written in C or
| asm, if the data structures or algorithms used can't handle
| certain types of data well. Just in this case, the native
| software seems to be able to handle that file better.
| fireflash38 wrote:
| 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?
| brabel wrote:
| I think it's just the way web apps are architectured. If you
| use vanilla JS you can make the browser render stuff really
| fast even if you change the DOM, as long as you do it
| efficiently (don't update ALL the DOM on every change!). But I
| bet Google uses some reactive framework that keeps a bloody
| copy of the whole DOM in memory, so when you throw 30MB of
| content into the DOM, that copy that was meant to make things
| faster starts being the bottleneck.
| jakub_g wrote:
| IMO the biggest problem is simply that nothing is tested
| anymore on big inputs, and that frameworks and the modern way
| of writing code hide the complexity.
|
| 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...
| mike_hearn wrote:
| 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(tm) 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).
| constantcrying wrote:
| >Where in that stack is the biggest loss of performance
|
| Exclusively the minds of developers and the stance of
| management.
|
| It is of course possible to built responsive, high quality and
| performance websites. But that is hard, much, much harder than
| to make something work, which maybe takes a few seconds to
| load, sometimes doesn't work quite right and can be a bit
| tedious to use.
| oellegaard wrote:
| 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 we just fixed the shitty react code and it
| rendered instantly.
| compacct27 wrote:
| Yup. Common. With all the performance blogs focused on time to
| first paint and the like, React introduced a whole new category
| that looks a lot like this
| drewcoo wrote:
| 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.
| Klonoar wrote:
| 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.
| YurgenJurgensen wrote:
| There's another condition for that: That you can predict
| the first few characters of what you want to select. This
| is rarely true of thousand-item dropdowns; you generally
| find yourself having to iterate through a bunch of
| hypothetical naming schemes. Sure, this could be averted
| with rigorous enforcement of some naming convention, but if
| you have the discipline to do that, you're probably not
| making thousand-item dropdowns.
| werdnapk wrote:
| So use a server side rending framework such as Turbo. I've
| tried so many client side frameworks (what the kids tend to
| demand these days) and they're all slow with lots of data...
| except for Turbo.
| a2128 wrote:
| 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 are broken or unusable
| passion__desire wrote:
| Related point, do google android engineers dogfood android
| phones to themselves? I guess most of them would be Apple
| users.
| silverquiet wrote:
| Android encompasses $80 burner phones to what... like $2K
| flagships? It's a big target.
| passion__desire wrote:
| Isn't that the point? Make a system usable on low-spec
| devices.
| jwells89 wrote:
| Not a Google engineer, but I do keep around a device that
| represents "potato" specs that I test against when doing
| Android development. Not a perfect solution since there's a
| bevy of old/low end SoCs with varying performance
| characteristics, but I figure it's better than what many are
| undoubtedly doing which is testing against their newish
| flagship and calling it a day.
|
| I used to do the same on iOS, but came to find that
| performance differences on older devices there generally
| weren't nearly as severe and that iOS users as a whole tend
| to use newer devices. When combined with reasonably well
| written Swift, performance on old devices generally isn't a
| problem.
| mattl wrote:
| So this is part of my current job: testing things on older
| hardware or less powerful hardware plus older but still used
| browsers, especially on mobile.
| drewcoo wrote:
| You're not off base. The article was about imagined problems.
| graboid wrote:
| The same techniques that native apps use to process large
| documents should be possible in JS/WASM land, no? Given, you
| probably won't reach native performance, but it seems to me a
| snappy text editing experience even for large documents should be
| perfectly doable using web tech.
| high_na_euv wrote:
| People shit on web devs, but lower lvl things arent better either
| - try compiling llvm
| vinyl7 wrote:
| LLVM is overly complex for what it does
| logrot wrote:
| We aren't making software. Where making features (and bugs) for
| the next Friday deadline.
| stephc_int13 wrote:
| 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 fully ongoing.
| EGreg wrote:
| Now imagine same but with AI killer bot swarms. Slaughterbots.
| Because we could !
|
| As long as we have COMPETITION as the main principle for all
| tech development -- between countries or corporations etc. --
| we will not be able to rein in global crises such as climate
| change, destruction of ecosystems, or killer AI.
|
| We need "collaboration" and "cooperation" at the highest levels
| as an organizing principle, instead. Competition causes many
| huge negative externalities to the rest of the planet.
| HappMacDonald wrote:
| What we really need is some way to force competition to be
| sportsmanlike. EG: cooperating _to_ compete, just like well
| adjusted competitors in a friendly tournament who actually
| care about refining their own skills and facing a challenge
| from others who feel the same way instead of cutting corners
| and throats to get ahead.
|
| Cooperation with no competition subtracts all urgency because
| one must prioritize not rocking the boat and one never knows
| what negative consequences any decision one makes might prove
| to have. You need both forces to be present, but cooperation
| must also be the background/default touchstone with
| adversarial competition employed as a tool within that
| framework.
| EGreg wrote:
| I don't see any urgency in depleting ecosystems or building
| AI quickly or any other innovations besides ones to
| safeguard the environment, including animals.
|
| Human society has developed far slower throughout all
| history and prehistory, and that was OK. We've solved child
| mortality and we are doing just fine. But 1/3 of arable
| farmland is now desertified, insect populations are
| plummeting etc.
|
| Urgency is needed the other way -- in increasing
| cooperation. As we did ONE TIME with the Montreal Protocol
| and almost eliminated CFCs worldwide to repair the hole in
| the ozone layer
| alerighi wrote:
| 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 unusable. A computer with 8Gb of RAM is barely usable. Each
| new software uses Electron and consumes roughly 1Gb of RAM
| minimum! Browsers consume a ton of RAM, basically everything
| consumes an absurd amount of memory.
|
| Not talking about Windows, I don't even know how people can use
| it. Every time I help my mother with the computer is so slow,
| and we talk about a recent PC with an i5 and 8Gb of RAM. It
| takes ages to startup, software takes ages to launch, it takes
| 1 hour if you need to do updates. How can people use these
| system and not complain? I would throw my computer out of the
| window if it takes more than a minute to boot up, even Windows
| 98 was faster!
| tomsmeding wrote:
| Not discounting your lament about memory use, this caught my
| eye:
|
| > I would throw my computer out of the window if it takes
| more than a minute to boot up, even Windows 98 was faster!
|
| Sure, Windows has grown a lot in size (as have other OSes).
| But startup is typically bounded by disk random access, not
| compute power or memory (granted, I don't use Windows, if 8GB
| is not enough to boot the OS then things are _much_ worse
| than I thought). Have you tried putting an SSD in that thing?
|
| (And yes, I realise the irony of saying "just buy more
| expensive hardware". But SSDs are actually really cheap these
| days.)
| ponector wrote:
| But that is true. My laptop with windows, i7, nvme, 32gb
| ram now feels the same as my old laptop with i7, SSD and
| 16gb ram did 7 years ago.
|
| Bloat ware everywhere, especially browsers.
| paulryanrogers wrote:
| 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.
| wvenable wrote:
| > The thing that makes me crazy is that the thing that we do
| on computers are basically the same each year
|
| I think that is some kind of fallacy. We are doing the same
| things but the quality of those things is vastly different. I
| collect vintage computers and I think you'd be surprised how
| limited we were while doing the same things. I wouldn't want
| to go back.
|
| Although I will say your experience with Windows is different
| than mine. On all my machines, regardless of specs, start up
| is fast so the point where I don't even think about it.
| vnuge wrote:
| > 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 be
| tested well, so containers it is. Redbean and Cosmopolitan libc
| are the closest I have seen to "solving" this issue
|
| It's also a matter of competition, if I want users to deploy my
| apps easily and reliably, container it is. Then boom there goes
| 100mb+ of disk space plus the container engine.
| mike_hearn wrote:
| 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.
| titzer wrote:
| > A lot of that is due to coordination problems.
|
| The dumpster fire at the bottom of that is libc and the C
| ABI. Practically everything is built around the assumption
| that software will be distributed as source code and
| configured and recompiled on the target machine because ABI
| compatibility and laying out the filesystem so that .so's
| could even be found in the right spot was _too hard_.
| eternityforest wrote:
| Moore's law is still going, but we stopped making software
| slower.
|
| We use JITs and GPU acceleration and stuff in our mega
| frameworks, and maybe more importantly, we kind of maxed out
| the amount of crazy JS powered animations and features people
| actually want.
|
| Well, except backdrop filter. That still slows everything down
| insanely whenever it feels like it.
| pylua wrote:
| There are a lot of nuanced features that explode in complexity
| when joined with other features. The number of permutations is
| massive, and handling those combinations of requirements is what
| modern day software is about.
|
| Today's software systems are more generalized, though they are
| solving the same business problems, just with more details /
| functionality than before.
| tracer4201 wrote:
| I'm in leadership ic role at a big tec company. We pride
| ourselves in engineering.
|
| hiring bar was dropped. expecting a mid level engineer to work
| with a byte buffer is considered "too complex" and non
| differentiated work.
|
| the literal goal is to pump out features written up by
| mba/product team. none of these mbas use the product mind you.
| theyre chasing stupid features they think vice presidents want,
| because the thinking is it will drive promotions.
|
| this is a cynical post and i will stop here. my org has problem
| of incentives. nothing else. you incentivize wrong things then
| this happens
| claytonwramsey wrote:
| 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.
| zer00eyz wrote:
| 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...
| vnuge wrote:
| 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.
| apantel wrote:
| The ads are the real content from Medium's perspective. The
| article is actually the medium by which the real content is
| delivered, like a train carrying dark passengers. The article
| is not what Medium cares about delivering to your browser, but
| the ads. And delivering the ads requires a lot of complexity.
| anthk wrote:
| A modernized Inferno for the web (with unicode) would have been
| much better than... this.
|
| It looks like a joke seeing an i5 choking on files opened by PC's
| from 2003.
| robinhood wrote:
| Interesting fact that this article has been posted on Medium,
| resulting in a 7.32 Mb page.
| canucker2016 wrote:
| I got 8.3MB on page load.
|
| Then I got uBlock Origin to turn off JavaScript, remote fonts,
| and large media items.
|
| Result: 116KB
|
| So 98.61% of the page is extraneous...
| nwah1 wrote:
| 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.
| nottorp wrote:
| 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...
| empiko wrote:
| Substack is a good example as well. Literally cannot render
| simple text and image articles without visible and annoying lags.
| If there are several hundred comments it can take tens of seconds
| to finish rendering. With functionality that was figured out in
| early 90s...
| Ekaros wrote:
| I remember using Youtube with Opera GX and two adblockers not
| that long ago. When you scrolled deep enough in to comments
| writing replies to them had significant lag on input. And I
| mean like what felt like seconds before all presses got
| processed.
|
| This is flagship product of one of the largest companies, and
| even they cannot get UI performance right...
| ultra_nick wrote:
| We learned that efficiency is just one feature of many.
| AdrianB1 wrote:
| 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 optimization
| is too expensive in terms of time invested. Some don't know how
| to do it, some are not proficient enough to do it in the
| constraints of the projects given to them by bean-counting
| managers. "good enough" quality is software management is much
| safer than "good enough" Boeing planes, so when Boeing is cutting
| corners then managers of developers cut even more.
| RetroTechie wrote:
| > 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.
| contextfree wrote:
| 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."
| Johnny555 wrote:
| 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 I'm not using MS Word, the fonts and formatting
| aren't as expected.
| cmiles74 wrote:
| I wonder if it's the big software vendors who have lost their
| way, rather than the average software developer. We have
| companies like Microsoft and Adobe moving to Web based
| applications not because they are better but because it's easier
| for them to enforce licensing restrictions and push people into
| subscriptions. As the various App stores erode the profits of
| software developers any tool that will make it faster to add
| features, even if they are buggy, becomes compelling.
| lispisok wrote:
| The real problem this guy is encountering is making interactive
| applications for a web browser is hammering a square peg through
| a round hole at its core. That's why performance is bad, that's
| why there is a new framework every other week trying to find a
| better workflow with better abstractions. There is so much
| inertia, such a huge ecosystem, many billions of dollars invested
| in it trying to make it less bad so it's not going away.
| jeffbee wrote:
| No, but apparently the arts of rhetoric and reason are completely
| dead. There is a big gap in this blog post somewhere between "a
| given program is not optimized for a specific use-case" and "we
| lost our way of developing optimized, efficient, and performance-
| wise applications".
| geor9e wrote:
| Google Docs might be able to directly edit .docx files now, but
| that is pretty new feature, and it doesn't surprise me that it's
| slow. It's a proprietary format owned by Microsoft. The argument
| that software ought to be efficient is valid, but the example of
| editing a non-native format seems unfair. Any time you add
| emulation layers you should expect things to slow down.
|
| Did you consider trying Microsoft's own browser-based Word
| editor? It's free too. And .docx is it's native format.
|
| Or, consider doing a conversion to Google Docs native format
| first (you'll lose some formatting though, possibly a lot of it).
| gnabgib wrote:
| .docx (office open xml) is an open published ECMA standard[0],
| and lots of other apps include support[1], including google
| which added editing without conversion in 2019[2]
|
| [0]: https://ecma-international.org/publications-and-
| standards/st... [1]:
| https://en.wikipedia.org/wiki/Office_Open_XML#Application_su...
| [2]: https://www.theverge.com/2019/4/10/18304978/google-docs-
| shee...
| michelb wrote:
| In my MacOS Passwords I have +-3400 entries. A roughly 341KB CSV.
| Searching in that list in the preference panel or Keychain app is
| dog-slow on my M1 Pro Studio or on my M3 MacBook Air. How??
| constantcrying wrote:
| It seems obvious how you could make it slow. Just naively
| iterate over the entire series of objects looking up the name
| for each.
|
| This is the obvious low effort, low complexity solution. Of
| course you _could_ make it fast, but that would take time and
| effort for a feature most people won 't notice.
| slyu wrote:
| Similar observations from the history of video game making.
| Historical archives like the making of Prince of Persia
| illustrates the art of constraint
|
| https://github.com/jmechner/Prince-of-Persia-Apple-II
| https://www.jordanmechner.com/en/books/journals/
| vnuge wrote:
| 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.
| fnordpiglet wrote:
| 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.
| drewcoo wrote:
| Did we lose our way in arriving at the file size non-goal?
|
| No.
| contextfree wrote:
| 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)
| KayL wrote:
| 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...)
| constantcrying wrote:
| Who knows how exactly that word looks. Might be Features from
| word which it is badly emulating.
| rumad wrote:
| The doc file has images, and some simple tables but mostly
| texts.
| emorning3 wrote:
| If AI was a real thing, instead of phony baloney probabilistic
| bullsh!t, then we'd already have AI-driven tools that take
| crappy, bloated, slow, but correctly working systems built by
| humans and turn them into smaller, faster, correctly working AI-
| enhanced systems.
|
| Right?
| clircle wrote:
| Dad wants to work on a doc file, so why tf didn't OP install MS
| Word?
| Zpalmtree wrote:
| Dude just increase your development costs 10x because apps
| sometimes run slow
| mihaaly wrote:
| Perhap we should compare the cost of development - and
| maintenance - for an efficient classic software and a bloated
| and modern one once ... ; ))
|
| (probably the cost of making an ancient Word and the newest
| one... : )) but there could be lots of other examples of
| 'modern' ones made along current trends vs. similar feature set
| classic ones, I wonder how this cost characteristic would play
| out .... : ) )
| eternityforest wrote:
| We did lose the way, and then we found it again. Not everything
| has caught up yet but a lot has.
|
| Moore's law kept going, and software started getting a little bit
| faster, which was enough to stop undoing the gains made by
| hardware, and now things are back to mostly snappy.
|
| Occasionally you'll get a 30mb file that's slow... but
| subjectively things sure seem better than 10 years ago when you
| couldn't even think about optimization without someone beating
| you over the head with a "premature optimization is the root of
| all evil" quote.
| nocman wrote:
| > and now things are back to mostly snappy.
|
| This is the inverse of my experience. There are few
| applications that have a UI that I would refer to as 'snappy'.
| In fact, I am trying to come up with a single example, and atm
| I can't even think of _one_.
| constantcrying wrote:
| 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 really annoy
| the user too much. Management doesn't care either, certainly
| creating good software isn't important when good enough software
| has already been developed.
|
| Sure, I would like things to be different, but until one group
| decides that a drastic departure is necessary, nothing will
| change. There are also no real incentives for change, from any
| perspective.
| impossiblefork wrote:
| Do we really though?
|
| Web developers do of course, but I've hardly touched web
| development myself. Web interfaces etc., are a choice, but I
| think it's driven by commercial needs-- a desire for
| subscription revenue instead of one-time sales, etc.
|
| Much of the modern cloud-based or half-online world is quite
| unnatural from a user perspective, and where there is no need
| for monetisation-- for example with OpenOffice, the software
| can expected to remain a desktop application.
| constantcrying wrote:
| Certainly there has been almost no pushback. I don't think
| most users really care for native applications, what they
| like to see is clicking on something and having it work
| instantly, web apps deliver that.
| jwells89 wrote:
| I think an overwhelming majority of users aren't technical
| enough or well enough versed in UI/UX to be able to put a
| finger on the frustrations they experience with software,
| and this is something that's important to remember when
| considering complaints coming from a more technically-
| inclined minority -- even if only a small number of techy
| folks are unhappy, these frustrations likely exist in the
| larger userbase too even if most users are unable to
| articulate them. In addition, some percentage undoubtedly
| perceive these issues but are just too busy to bother with
| sending in feedback.
|
| With all that considered, I believe the extent of pushback
| that is possible is quite limited as long as the app
| technically works, but this is far from an accurate
| indicator of user happiness.
| SkyPuncher wrote:
| 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 extremely valuable problem for them. A job that took
| literally a week could now be done in minutes.
|
| As the space heated up, we needed to improve some things, but
| most people literally did not care. It would always be stack
| ranked last in the list.
| eezing wrote:
| Google Docs is pretty efficient. It loads incredibly fast and you
| never have to manually update it. But, it clear has limits...
| 30MB Word files.
| egypturnash wrote:
| "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
| problems down the line when Dad wants to work with someone else's
| Word docs?
|
| Maybe there was a perfectly good reason for this choice. I can
| think of a few. Maybe you helped Dad enter The Year Of Linux On
| The Desktop recently. Maybe Dad didn't want to pay for Office.
| Who knows. Whatever the reason, you didn't put it in this post.
| And you ended it with a plug for your completely unrelated SAAS,
| too.
| rumad wrote:
| My dad didn't want to pay for the Office. I might ended my
| story badly. Sorry about that. But, I don't agree with that the
| SaaS is not related. It is. API optimization is also important
| and it can directly affect the performance of web apps and even
| native apps.
|
| Update: I updated the article.
| YurgenJurgensen wrote:
| Aren't Microsoft trying their best to turn Word (and the rest
| of Office) into a shitty web app?
| can16358p wrote:
| I think convenience is the keyword. Users (not us HN crowd, the
| rest of the world) don't want to struggle with installing
| software, most of them don't know the difference between
| Internet, Browser, or "app".
|
| They just open up "internet" and work on docs, and for 99% of the
| cases Google Docs works fine despite running in a browser that is
| much less efficient than a native "app". For most cases it's more
| than enough for the regular user who is used to "computers being
| slow" anyway.
| rumad wrote:
| I also love to use and prefer native apps. But, in my case, I
| had to offer Google Docs to my dad. Because he wanted to
| transfer his doc file to his work computer to continue to work
| on it when he is at the office. So, I thought a web app might
| be good for him.
| xg15 wrote:
| Yes.
___________________________________________________________________
(page generated 2024-04-28 23:01 UTC)