Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)S
Posts
4
Comments
1452
Joined
1 yr. ago

  • Removed Deleted

    Permanently Deleted

    Jump
  • The article is very much off point.

    • Software quality wasn't great in 2018 and then suddenly declined. Software quality has been as shit as legally possible since the dawn of (programming) time.
    • The software crisis has never ended. It has only been increasing in severity.
    • Ever since we have been trying to squeeze more programming performance out of software developers at the cost of performance.

    The main issue is the software crisis: Hardware performance follows moore's law, developer performance is mostly constant.

    If the memory of your computer is counted in bytes without a SI-prefix and your CPU has maybe a dozen or two instructions, then it's possible for a single human being to comprehend everything the computer is doing and to program it very close to optimally.

    The same is not possible if your computer has subsystems upon subsystems and even the keyboard controller has more power and complexity than the whole apollo programs combined.

    So to program exponentially more complex systems we would need exponentially more software developer budget. But since it's really hard to scale software developers exponentially, we've been trying to use abstraction layers to hide complexity, to share and re-use work (no need for everyone to re-invent the templating engine) and to have clear boundries that allow for better cooperation.

    That was the case way before electron already. Compiled languages started the trend, languages like Java or C# deepened it, and using modern middleware and frameworks just increased it.

    OOP complains about the chain "React → Electron → Chromium → Docker → Kubernetes → VM → managed DB → API gateways". But he doesn't even consider that even if you run "straight on bare metal" there's a whole stack of abstractions in between your code and the execution. Every major component inside a PC nowadays runs its own separate dedicated OS that neither the end user nor the developer of ordinary software ever sees.

    But the main issue always reverts back to the software crisis. If we had infinite developer resources we could write optimal software. But we don't so we can't and thus we put in abstraction layers to improve ease of use for the developers, because otherwise we would never ship anything.

    If you want to complain, complain to the mangers who don't allocate enough resources and to the investors who don't want to dump millions into the development of simple programs. And to the customers who aren't ok with simple things but who want modern cutting edge everything in their programs.

    In the end it's sadly really the case: Memory and performance gets cheaper in an exponential fashion, while developers are still mere humans and their performance stays largely constant.

    So which of these two values SHOULD we optimize for?


    The real problem in regards to software quality is not abstraction layers but "business agile" (as in "business doesn't need to make any long term plans but can cancel or change anything at any time") and lack of QA budget.

  • Totally! If I got cancer free and then a simple and quick cure for cancer came out, I'd obviously wish that that came out earlier, but one would have to be a royal asshole to with that others suffered and died because one had to suffer as well.

  • If this is a one-time event it's hardly the solution to the problem. Education should be free or close to free in general.

    If that's the case, things suddenly look different. Even only if e.g. state schools are free.

    In my country the tuition fee for a state university is around €30 per semester, and that doesn't even go to the university but to fund the student governing body (not sure what's the right translation for the term).

    This means, that everyone can get a quality education even if they are poor. In fact, most people I went to university with funded their flat/student accomodation and food with a part-time job while going to university. No debts or financial assistance needed.

    This doesn't cover private universities, but (a) the difference in quality and reputation isn't relevant and (b) free public universities means that private universities are also somewhat price capped if they want to stay competitive.

  • I could imagine something like Sidequest happening on Android.

  • Not really. There are quite a few of structures you can make with gotos that can't directly be translated into functions. Sure, you can implement any functionality in any programming paradigm, but it might require much more work than to just replace goto with a function call.

  • So now 3rd party app stores need an ADB loopback to work around that.

    Not hard to do, but uselessly annoying.

  • git re-flog is what you do with those idiots who mess up the repo so that someone else has to come in and fix it again.

  • When I bought my last laptop I specifically looked for alternatives to Nvidia. If you want a dGPU on a laptop, there's almost nothing else than Nvidia.

    There were like 4 laptops with AMD dGPU. All of them were priced about 2x what a comparable Nvidia laptop was priced and pretty much all of them have terrible ratings due to being made by Acer.

    The only other option is Framework, and they want 3x what the Nvidia 4070 laptop cost that I ended up getting.

  • The ways exist, but a lot of people are using FOSS for the first letter in the acronym.

  • Does anyone else have the issue that after 6.10 the laptop can't wake after sleep?

  • I say "Not again" on Linux too if it's a kernel update because anything newer than 6.10 means that sleep is broken again and I have to roll back to 6.10.

  • LLMs are confirmation bias machines. They really pigeon-hole you into some solution no matter if it makes sense.

  • I think Poland is just in the crappy position of not being on developers/publishers radars and being lumped in with other nearby countries when it comes to pricing.

    I've heard similar complaints of polish people for all sorts of platforms, not only steam.

    And I think them not having the euro probably adds to the situation since the value of the polish zloty has been going up compared to the euro.

    So if publishers set the price to the euro equivalent in 2022, and the Zloty rose by 20% compared to the Euro in the mean time, you end up with the prices that are there now.

    The difference to the USD over the same time is even more stark at 36%.

  • A year or so before I started my current job, the team working on the project got split. Someone then decided that both teams should use different jira prefixes for tickets processed by each team. So they took all issues and automatically split them into two prefixes based on the people who implemented the ticket and renumbered everything. But they didn't do the same in Gitlab merge requests, and they didn't do it in git commit messages either.

    So now git and gitlab reference all old tickets by their old numbering system, but there's no trace of these old numbers in Jira. It's close to impossible to find the Jira ticket mentioned in a git commit message.

    Oh, and of course, nobody ever managed to properly link Jira and Gitlab (so that jira tickets contain the gitlab MRs, branches and commits) because for that you need a free Jira plugin and procurement wants a multi-page long description why this is needed, and it needs to be signed off by 5 people including the department lead and has to go through the whole procurement process before we can install that plugin.

  • Does Valve set the prices? I thought it was the publishers/developers/who ever manages the steam product listing.

  • You are obviously right about the things you are saying. I was specifically talking about code documentation on a class/method level. User documentation, architecture documentation or other high-level documentation doesn't make sense in the code, of course.

    I have seen similar levels of documentation as you talk about (every line, every call documentated), but in flow charts in Confluence. That has the same issues as documenting every line of code in comments but worse.

    Just because a tool has some issues and limitations doesn't mean it gets banned from our toolbox.

    This is very much it. Every tool can be abused and no tool is perfect. Code can have bugs and can be bad (and often both things happen). Should we now ban writing code?

    If the comment and the code doesn't match with each other, which one is true?

    This can be true even with code alone. A while ago I found a bug in an old piece of code written by someone who left the company years ago.

    The method causing the bug was named something like isNotX(). In the function it returned isX. About half the places where the function was called, the returned value was assigned to a variable named isX and in the other half of the places the variable was named isNotX. So which is true?

    A javadoc-style comment could have acted as parity. Since comments are simpler to write than code, it's easier to correctly explain the purpose of a function in there than in code.

    While in the example I referenced it was quite clear that something was wrong, this might not always be the case. Often the code looks consistent while actually being wrong. A comment can help to discern what's going on there.

    Another example of that that we had at the same project:

    In the project there were bookings and prebookings. We had a customer-facing REST endpoint called "getSomeSpecialBookings" (it wasn't called that, but the important thing was that this function would return a special subset of bookings). Other "get...Bookings" endpoints would return only return bookings and not prebookings, but this special endpoint would return both bookings and prebookings. A customer complained about that, so we fixed the "bug" and now this endpoint only returned bookings.

    (There was no comment anywhere and we couldn't find anything relevant in Confluence.)

    Directly after the release some other customer creates a highest priority escalation because this change broke their workflow.

    Turns out, that endpoint only existed because that customer asked for it and the dev who implemented that endpoint just implemented it as the customer requested without documenting it anywhere.

    A comment would have been enough to explain that what this endpoint was doing was on purpose.

    We all know that code tends to be bad, especially after the project has been running for a few years and has been through a few hands.

    Why would anyone think that code is good enough to be the documentation?

    Luckily these days we have good tools in regards to source control, with things like feature branches, pull requests with tools that allow for discussion and annotation. That way at least usually the origin of a change is traceable.

    Sadly, we also have non-technical people running procurement and thus we keep switching tools because one is maginally cheaper or because cloud is cool right now (or not cool anymore right now) and migrations suck and then we end up with lost history.

  • It really depends on what your goal is. Usability, keeping a familiar interface, performance, all of that are things that make it reasonable to stay on an outdated OS, and none of these reasons are bad.

    Security (which is the only thing we are really talking about here) does require updates.

    If security is your most important concern, you need to update. If security is not your biggest concern and other topics are more important for you, it might be reasonable to stay on older versions.

    But in the context of this post, which was purely about security, having long term security updates is important.

  • I'm totally with Ousterhout here! Thanks for posting this great discussion!

    The problem with the "Clean code" approach of overdecomposition is that it doesn't abstract the code away in meaningful ways. The code is still there and to debug/avoid bugs you still need to know all of it, if the methods are entangeld. So I still need to keep 500 lines of code in mind, but now they aren't all in one file where I can easily follow them, but instead spread over 40 files, each just containing 1-2 line methods.

    I'm also very much against "Clean code"'s recommendations on comments. In the end it either leads to no documentation or documentation lost somewhere in confluence that nobody ever reads or updates because it's not where it's needed.

    Getting developers to read and update documentation is not an easy task, so the easier it is to find and update the documentation the more likely it is that the documentation is actually used. And there is no easier-to-access place for documentation than in comments right in the code. I really like Javadoc-style documentation since it easily explains the interface right where it's needed and neatly integrates with IDEs.

  • You don't seem to get my point and seem to think that I'm some apple fanboy that you need to convince or win against.

    I use android, I've never used iOS. I enjoy the freedom of sideloading. Still it is a fact that the overwhelming majority of malware infections on Android happen due to side loading. The percentage of devices running corporate MDM is tiny, making this a moot point.

    The vast majority of Android phones do not come with root access. For both, you generally have to elevate access yourself

    And yet quite a few devices in the wild run rooted or custom ROMs.

    If you're running an out-of-date OS, clearly security is not a priority

    You seem to forget what this thread is about. It's not about personal security and whether one can run a safe android device, but about an app developer not providing an Android version, because the platform as a whole (meaning the average user) is less secure.

    Personal preferences like paying for a new, non-outdated phone don't really matter for that big picture view.

    Supply chain attacks absolutely can happen to iPhones as well. There are plenty of re-sellers

    That's a strange argument. Getting malware that survives a factory reset onto an iPhone without apple's approval is close to impossible. Making an Android phone from scratch that contains malware right in the system image has been done over and over again. You are argueing a hypothetical versus something that happens every day.