• @blind3rdeye@lemm.ee
    35•6 months ago

    It’s like Moore’s law. The number of bytes for a basic app doubles every 2.5 years.

    When I was young, we’d get a few different games games on a single 1.4 Mb floppy disk. The games were simpler, sure, but exactly the same games now would be far bigger in bytes.

    • @Huschke@lemmy.world
      12•6 months ago

      Games is the one example that actually makes sense though. The game code size hasn’t really increased tremendously, but the uncompressed assets have only gotten more detailed and more numerous.

    • 🇰 🔵 🇱 🇦 🇳 🇦 🇰 ℹ️English
      35•6 months ago

      At least games make sense, as the graphics get better. Though in some cases, the compression is also better. Like PS5 games are smaller on average than their PS4 versions, even though they have higher resolution textures in most cases, just because the PS5 has better compression/decompression tech.

            • KillingTimeItselfEnglish
              1•6 months ago

              this entire thread is about software being dogshit? (this specific comment thread is about compression being moderately improved on one console, but that’s not really significant)

      • BeeegScaaawyCrippleEnglish
        1•6 months ago

        Like PS5 games are smaller on average than their PS4 versions

        My favorite example of this is Subnautica. The system didn’t call on the assets as quickly, or a different way I can’t remember all of the details but essentially they had to put like five copies of every asset on the ps4 version to get it to run properly. The ps5 accesses the assets fast enough it only needs one copy. At least that’s how it was explained to me.

      • @Flatfire@lemmy.ca
        17•6 months ago

        Better than that, the lack of reliance on spinning disks means that asset duplication and data read order is less of a requirement to reduce load times. It can still be argued that there’s just too many polygons, since simply scaling things back would be plenty effective in reducing storage usage and load times.

  • I Cast Fist
    7•6 months ago

    “Program is slow? Just get better hardware, brah!!! It’s cheap, bruh!!!”

    Fuck you and anyone that thinks like that

  • @the_wiz@feddit.orgDeutsch
    5•6 months ago

    Is this the appropriate point to reference the suckless community? I mean, that’s THE point of the movement…

  • @x4740N@lemm.ee
    1•6 months ago

    Lazy devs not removing old non functional commented code and background code additions ?

    Though I do get it if they don’t want to remove the old code if their employer is an asshole

    • @SketchySeaBeast@lemmy.caEnglish
      4•6 months ago

      That’s not why. It’s the dependency trees that run a dozen layers deep and end up importing “isEven”. If you’re building a react app odds are good you’ll import way more code than you ever write yourself.

      And no one should be leaving commented-out code in their app, that’s what source control is for.

  • @cylon@programming.dev
    30•6 months ago

    Memory is cheap and data sells enough to many parties. Most apps are just store front for Ads and data collection.

    No wonder why open source apps are quite light.

    • @August27th@lemmy.ca
      22•6 months ago

      Nailed it. Things have changed to allow cheaper (interpretable in several ways) developers to create “good enough” software as quickly as possible. If that involves inefficient frameworks, technology, and practices that unlock this, then so be it; if the “best” code is the code that makes money, and money is what corporations prioritize above all else, and there is a way to do that quicker and cheaper, the outcome is obvious and now ubiquitous. Furthermore, if nobody at the top cares, why should anyone on the ground care? The problem compounds.

      Priorities are fucked.

      • @bleistift2@sopuli.xyzEnglish
        3•6 months ago

        inefficient frameworks

        I’d like to object to that. Frameworks are often built by dedicated and paid developers, so they tend to be above average in terms of efficiency. But being frameworks, they have to facilitate lots of use cases, so they also tend to be bigger than what you would write if you had 6 months to roll your own. And 36 more months to kill all the worms that got out of the can, to mangle a proverb.

      • bizarroland
        12•6 months ago

        If it runs “fast enough” on a completely clean system that would cost the average user $1500, then companies assume that that means that it is a good product.

        If you want better software, you have to give developers worse hardware to develop on, and more time to develop.

        • @MajorHavoc@programming.dev
          4•6 months ago

          If you want better software, you have to give developers worse hardware to develop on, and more time to develop.

          Shhh. There could be application development managers listening… (I’m joking… Mostly.)

    • @TBi@lemmy.world
      7•6 months ago

      I wouldn’t say skill issue, more of time issue. You only get a week to implement something. Quicker to use existing libraries than try to optimise yourself.

      • @Hawke@lemmy.world
        10•6 months ago

        It’s both, and they are in a sense the same.

        Cheaper less skilled or less experienced programmers take longer to get similar results. One week with a a skilled programmer is a lot more value than one week with an unskilled programmer.

        Even more if you want to invest some of that experienced programmer time to get the new guy up to speed.

  • @buddascrayon@lemmy.world
    22•6 months ago

    Oh, they have new functionality. It’s all in the back end, detailing everything you do and sending it to the parent company so they can monetize your life.

  • @count_dongulus@lemmy.world
    140•6 months ago

    Cheaper & faster development by leveraging large libraries/frameworks, but inability to automatically drop most unused parts of those libraries/frameworks. You could in theory shrink Electron way down by yoinking out tons of browser features you’re not using, but there’s not much incentive to do it and it’d potentially require a lot of engineering work.

    • @zenpocalypse@lemm.eeEnglish
      55•6 months ago

      Yeah, though the joke is funny, this is the real answer.

      Storage is cheap compared to creating custom libraries.

      • @Tanoh@lemmy.world
        9•6 months ago

        Also the storage is the cost for the user, and google in the case of play store. So the developers have no incentive to reduce the size.

      • UnityDeviceEnglish
        4•6 months ago

        Storage is cheap on a PC, it’s not cheap on mobile where it’s fixed and used as a model differentiator. They overcharge you so much. Oh, and they removed SD card slots from nearly all phones.

    • @Bytemeister@lemmy.worldEnglish
      14•6 months ago

      Yep. Apps are 20x bigger with no new features…that you are using.

      Let’s not forget that the graphics for applications has scaled with display resolution, and people generally demand a smooth modern look for their apps.

  • @Aux@feddit.ukEnglish
    -2•6 months ago

    Most resources are not consumed by wonky code or dependencies. Most resources are consumed by images and sounds.

      • @Aux@feddit.ukEnglish
        0•6 months ago

        Every decent piece of software has crap loads of resources: icons, texts, translations, manuals, sounds, fonts, etc. Even hello world app contains at least one resource - “hello world” string and what’s funny is that executable meta data required by operating systems and the string take more space than the actual code to print this string.