• 23 Posts
  • 1.91K Comments
Joined 5 years ago
cake
Cake day: May 31st, 2020

help-circle




  • In my experience, it’s often the other way around. They’ll say that because everyone else is going to replace certain jobs with AI, they’ll have to do it, too, to stay competitive. If they don’t stay competitive, they might need to fire workers anyways.

    In theory, I could imagine someone employing AI, while from a moral viewpoint supporting a ban of it. One problem is that such a ban would need to be universal for it to not put anyone at a competitive disadvantage, which we can’t achieve with national laws.
    Well, and the other problem is that most people who argument this way then get massive bonuses and also pay bonuses out to investors, so that completely undermines any potential for morals.






  • On KDE, there’s actually a separate feature which provides essentially virtual desktops with changing wallpapers (and widgets and a few other things), which is called “Activities”. You can also then use multiple virtual desktops per Activity.

    I think, that’s kind of the main reason: Many people use virtual desktops differently.
    For some folks, they represent different larger topics, where the Activities feature would match very well.
    For others, virtual desktops are more like a second monitor, so they just want to see different windows, nothing more. In fact, some desktop environments like GNOME, create and destroy virtual desktops per demand. They couldn’t really remember the wallpaper for those workspaces.


  • Well, they’re similar in the widest sense, that they’re both strategy games, you have to produce resources and fight battles to capture land.

    But within the strategy genre, they’re actually pretty different. Civilization is turn-based, Widelands/Settlers is real-time strategy. I guess, the latter is at least still relatively slow-paced.
    Widelands/Settlers puts a lot more focus on managing supply chains. To produce bread, you’ll need a baker, which needs flour and water, and possibly coal, so you need a mill and a farm and a well and a coal mine, and then you need people to actually carry the resources between the buildings, and yeah, it starts to become pretty busy pretty quickly.
    If you ask fans of these games, that’s kind of what they love the most, that your settlement starts to look like an anthill buzzing with activity in no time.



  • I mean, yeah, I wrote it kind of humorously up there, but I do actually think state diagrams are a good idea and modelling the known error paths is part of real software engineering.

    However, I’ve never been in a project where anyone knew nearly enough about what we’re supposed to build, to be able to draw a state diagram before we got started. We would rather do a refactoring halfway through and then we would design a state machine to fit the requirements…


  • Ephera@lemmy.mltoich_iel@feddit.orgIch🐮🖥️iel
    link
    fedilink
    Deutsch
    arrow-up
    2
    ·
    4 days ago

    Ja, ist leider schon speziell, was mit Prolog wirklich gut funktioniert. Wenn du etwas machen willst, wo Schritt A vor Schritt B ausgeführt werden sollte, dann wird es bereits anstrengend.

    Ich finde, am besten betrachtet man Prolog als eine Datenbank, wo man Regeln abspeichert und dann Abfragen stellen kann. Und dann nimmt man eine (andere) Programmiersprache, um mit den abgefragten Informationen etwas umzusetzen. Also tatsächlich gibt es auch für viele Programmiersprachen Bibliotheken, mit denen man Prolog für sowas einbetten kann.


  • One time, we were drawing a state diagram of how the core loop in our application should behave. So, you know, first you have the preparation state, then when that succeeds, you go to the getting-things-ready state, then into the actual doing-things state, then the result-reporting state and so on. So, there was exactly one happy path.

    Then we figured, we should also diagram all the error scenarios. If an error occurs in the preparation state, we should transition to the result-reporting state. But if an error occurs in the getting-things-ready state, we’ll need to go to an intermediate cleanup state before we go to the result-reporting state, and so on.
    As we added more and more error paths, the arrows had to curve more and more, until the whole diagram eventually looked like an onion. That’s when I knew, we were doing real software engineering. 🙃