• rational_lib@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    2 months ago

    Because the app stores keep adding new requirements that you have to add code to deal with and it gets worse every year and seemingly every day.

    • TBi@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      2 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
        link
        fedilink
        arrow-up
        0
        ·
        2 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.

    • August27th@lemmy.ca
      link
      fedilink
      arrow-up
      0
      ·
      2 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.xyz
        link
        fedilink
        English
        arrow-up
        0
        ·
        2 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@fedia.io
        link
        fedilink
        arrow-up
        0
        ·
        2 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
          link
          fedilink
          arrow-up
          0
          ·
          edit-2
          2 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.)

        • JordanZ@lemmy.world
          link
          fedilink
          arrow-up
          0
          ·
          2 months ago

          If it runs slow on my laptop then there isn’t a chance it will run at all pushed to the cloud. Our cloud servers are…not great. Single core 1.75gb boxes compared to my 16 core, 32gb laptop. We can do a lot with them though. Just takes a decent amount of tinkering. In some ways the cloud was the best thing for performant code.

  • AppleTea@lemmy.zip
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    2 months ago

    isn’t it a combination of younger developers not learning to programme under the restrictions of limited memory and cpu speed, on top of employers demanding code as soon as possible rather than code that is elegant or resource efficient or even slightly planned out

    • Lifter@discuss.tchncs.de
      link
      fedilink
      arrow-up
      0
      ·
      2 months ago

      Much the latter.

      Plus everything better work perfecly out of the box on any hardware, and there is a lot of different hardware. Compatibility layers are often built into the package.

      Java, for instance, recommenda that you package the whole (albeit slimmed down) JVM inside the package for the target platform, rather than relying on the java runtime installed already.

      The users arent expected to know any of that anymore.

      • PrettyFlyForAFatGuy@feddit.uk
        link
        fedilink
        arrow-up
        0
        ·
        2 months ago

        yep, a lot of apps are just repackaged chrome running a web page.

        which begs the question to companies that require use of the app instead of just having a working website i can use on my copy of chrome/firefox that’s already on my phone…

        why do you need hardware access to my device?

        • drawerair@lemmy.world
          link
          fedilink
          arrow-up
          0
          ·
          edit-2
          2 months ago

          1 reason is that they want as much data as possible. They sell the user data. Or they use the user data to improve their targeted advertising. They want more ad clicks.

          Re app versus site, many know how to block ads on browsers. With an app, the firm is hoping they can show you ads. There’s a way to remove ads from certain apps but the layperson doesn’t know.

    • herrvogel@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      2 months ago

      Mostly the latter. We don’t do any optimizations on our product whatsoever. Most important thing is to say yes to all the customers and add every single feature they want. Every sprint is spent adding and adding and adding to the code as much as we can and as quickly as we can. Not a single second is allotted to any discussion about performance or efficiency. Maybe when something breaks, but otherwise we keep piling on more crap at full speed non-stop. I have repeatedly been told “the fast way is the right way” followed by laughter. I was told to “merge this now” on multiple occasions even when I knew that the code was shit, and told the team as much. I am expected to write code now and think about it later.

      As you can expect, the codebase is a bloated nightmare. Slow as shit, bugs galore, ugly inconsistent UI, ENORMOUS memory use, waaaaaay too frequent DB access with a shit ton of duplicate requests that are each rather inefficient themselves. It is a rather complex piece of lab management software, but not so complex that it should be struggling to run on dedicated servers with 8 gigs of RAM. Yet it does.

    • MonkderVierte@lemmy.ml
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      2 months ago

      Generally maybe but apps specifically, it’s the default choice of IDE, Android Studio, bundling tons of libraries for added functionality bound to Play Services by default.

      Which would probably be illegal in EU now, if any judge had the tech see-through for it.

  • KillingTimeItself@lemmy.dbzer0.comBanned
    link
    fedilink
    English
    arrow-up
    0
    ·
    2 months ago

    uh, please do ask, why does opening a fucking glorified text and image processing app require 1 gigabyte of ram.

    Who wrote this software? The guy from the bible who was the model for greed and gluttony? Jesus christ.

  • the_wiz@feddit.org
    link
    fedilink
    Deutsch
    arrow-up
    0
    ·
    2 months ago

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

  • I Cast Fist@programming.dev
    link
    fedilink
    arrow-up
    0
    ·
    2 months ago

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

    Fuck you and anyone that thinks like that

  • devilish666@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    2 months ago

    That topics always made me curious tho…take a sample AAA games back then has smaller size compared to shitty Unity 2D games nowadays and i wonder why ?

    • hungrybread@lemmygrad.ml
      link
      fedilink
      arrow-up
      0
      ·
      2 months ago

      Presumably less compression and fewer ways to install only necessary assets (such as only downloading audio for used languages)

    • Cratermaker@discuss.tchncs.de
      link
      fedilink
      arrow-up
      0
      ·
      2 months ago

      Yeah but like, what new features do apps have which weren’t available in those times? Embedded videos maybe? Doesn’t justify the bloat.

    • Oniononon@sopuli.xyz
      link
      fedilink
      English
      arrow-up
      0
      ·
      edit-2
      2 months ago

      Smaller textures, more assets, and worse audio mainly. Textures used to be like 512 for hero props. Now even random objects you see a few times get a texture 16 times larger. And they get up to 4 of those for each object/group of objects. Thanks to pbr and normals and whatever other masks and lightmaps may be required.

      Im sure there are more reasons for size bloat but this is from us artists at least.

    • gens@programming.dev
      link
      fedilink
      arrow-up
      0
      ·
      2 months ago

      Less triangles and smaller textures. Crt monitors had less resolution and practically built-in anti-aliasing so they could get away with (and had to) “worse” assets.

      Also since ssd-s have become mainstream unity uses less compression so it would load relatively faster.

      Basically because monitors got better, standards got higher, competition got fiercer, storage got bigger and faster, etc.

      And it’s not like there weren’t shitty games before, just everybody forgot about them.

      I like how the game Banished is made. From a requirenments/looks ratio it is IMO great. One guy made it. Ghosts of Tsushima also looks amazing and is great from a techical perspective, but it is heavy.

      • Oniononon@sopuli.xyz
        link
        fedilink
        English
        arrow-up
        0
        ·
        2 months ago

        Polygons aren’t that costly, they’re just a set of coordinates and pack up well and ultra expensive highpoly stuff is avoided wherever possible by proffessionals. It’s mostly textures and maybe audio that bloats size.

        • gens@programming.dev
          link
          fedilink
          arrow-up
          0
          ·
          2 months ago

          Yea, textures are the biggest thing (unless there’s video). But don’t underestimate vertices, even when using strips. Unity, i think, just ships textures as BCn, meaning 1MB per 1k texture (would be 3-4MB raw). It’s even better for the gpu then raw. Then there’s normal maps, etc.

          Another thing is lighting data, be it some textures, probes, or whatever. That can also take up plenty of space.

          • Oniononon@sopuli.xyz
            link
            fedilink
            English
            arrow-up
            0
            ·
            2 months ago

            I’ve mostly been told to use one 512 map max for lighting maps while textures I ship have a casual working file size of 5 gigs and above for substance painter. Idunno how well they get packaged up as since I haven’t played any of the games I’ve worked on for a while. I can see vertice data taking up a lot but other than some AAA games I don’t see why anyone would need to make super poly dense models.

      • SpaceCowboy@lemmy.ca
        link
        fedilink
        arrow-up
        0
        ·
        2 months ago

        If the goal is to not have apps be too large, you probably don’t want to send the full variable and function names and all of the comments over the wire every time someone loads a webpage. That would be a very inefficient use of bandwidth, wouldn’t it?

        • NoSpotOfGround@lemmy.world
          link
          fedilink
          arrow-up
          0
          ·
          2 months ago

          Except… the compilation step doesn’t add type safety to JS.

          As an aside, type safety hasn’t been something I truly miss in JS, despite how often it’s mentioned.

  • cylon@programming.dev
    link
    fedilink
    arrow-up
    0
    ·
    2 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.

  • Aux@feddit.uk
    link
    fedilink
    English
    arrow-up
    0
    ·
    2 months ago

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

      • Aux@feddit.uk
        link
        fedilink
        English
        arrow-up
        0
        ·
        2 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.