2

A philosophical question about maintenance/updating.

There is no need to repeat the reasons we need to update our dependencies and our code. We know them/ especially regarding the security issues.
The real question is , "is that indicates a failure of automation"?

When i started thinking about code, and when also was a kid and saw all these sci fi universes with robots etc, the obvious thing was that you build an automation to do the job without having to work with it anymore. There is no meaning on automate something that need constant work above it.

When you have a car, you usually do not upgrade it all the time, you do some things of maintance (oil, tires) but it keeps your work on it in a logical amount.
A better example is the abacus, a calculating device which you know it works as it works.

A promise of functional programming is that because you are based on algebraic principles you do not have to worry so much about your code, you know it will doing the logical thing it supposed to do.
Unix philosophy made software that has been "updated" so little compared to all these modern apps.
Coding, because of its changeable nature is the first victim of the humans nature unsatisfying.

Modern software industry has so much of techniques and principles (solid, liquid, patterns, testing that that the air is air) and still needs so many developers to work on a project.
I know that you will blame the market needs (you cannot understand the need from the start, you have to do it agile) but i think that this is also a part of a problem .
Old devices evolved at much more slow pace. Radio was radio, and still a radio do its basic functionality the same war (the upgrades were only some memory functionalities like save your beloved frequencies and screen messages).

Although all answers are valid, i still feel, that we have failed. We have failed so much. The dream of being a programmer is to build something, bring you money or satisfaction, and you are bored so you build something completely new.

Comments
  • 0
    "If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization."

    Thats the problem right there.
  • 0
    @magicMirror If requirements for bridges and other buildings were changing on weekly basis, nothing would get built.

    That is the problem too, and the problem you brought up has some of its roots in it.
  • 0
    @magicMirror this quote is yours ?
  • 0
    @impune-pl i agree. but materials are evolving too. just not so fast. and also even if they could, we have no gain from it.

    With the same mindset, we could stuck at cobol like many banks, but on the same time, C remains the king of OS system programming. So, some "materials" on programming are still better than others, and it would be nice if we could lead them to perfection than changing them all the time.

    I wish i could be that smart to give work on it . I am just a passenger.
  • 1
    @atheist i think the demand of the world seduced us. We could be more like priests in ancient time, giving the direction as we are holding the craft. But we are thirsty of approval weak mind nerds.
  • 1
    Software is fractally hard to reason about. And that is, what almost nobody gets.

    And still, a lot of developers just refuse to automate one of the two easiest things to automate:
    Either the don't use a language ensuring at compile time that there are no memory-access-related bugs.
    Or they use a language with a crippled type system, so they have to sprinkle value checks all over their code.

    Even a web frontend dev can make his life so much easier by configuring Typescript to not make anything nullable by default (also avoid "any")...
  • 0
    @Oktokolo i did not understand your first example (compile time)
  • 0
    @gatoMalicioso OFC not.
    Can't attribute it correctly, so just google the origins of it.
  • 0
    @gatoMalicioso
    Compile time as when the code is compiled. Everything checked by the compiler is known for sure at runtime. So chosing a compiled language (and/or using a static analyzer as they have gotten pretty good too) catches some bugs that would otherwise might or might not be found later (maybe by someone exploiting them for their profit and/or your loss).

    For the term itself:
    https://stackoverflow.com/questions...
  • 0
    @Oktokolo are you talking about Rust? lol
Add Comment