COFF'd
> I think general software engineering knowledge and experience cannot be
> 'obsoleted' or made less relevant by better languages. If they help,
> great, but you have to do the other part too. As languages advance and
> get better at catching (certain kinds of) mistakes, I worry that
> engineers are not putting enough time into observation and understanding
> of how their programs actually work (or do not).
I think you nailed it there mentioning engineers in that one of the growing norms these days is making software development more accessible to a diverse set of backgrounds. No longer does a programming language have to just bridge the gap between, say, an expert mathematician and a compute device.
Now there are languages to allow UX designers to declaratively define interfaces, for data scientists to functionally define algorithms, and WYSIWYG editors for all sorts of things that were traditionally handled by hammering out code. The concern of describing a program through a standard language and the concern that language then describing the operations of a specific device have been growing more and more decoupled as time goes on, and that then puts a lot of the responsibility for "correctness" on those creating all these various languages.
Whatever concern an engineer originally had to some matter of memory safety, efficiency, concurrency, etc. is now being decided by some team working on the given language of the week, sometimes to great results, other times to disastrous ones. On the flip side, the person consuming the language or components then doesn't need to think about these things, which could go either way. If they're always going to work in this paradigm where they're offloading the concern of memory safety to their language architect of choice, then perhaps they're not shorting themselves any. However, they're then technically not seeing the big picture of what they're working on, which contributes to the diverse quality of software we have today.
Long story short, most people don't know how their programs work because they aren't really "their" programs so much as their assembly of a number of off-the-shelf or slightly tweaked components following the norms of whatever school of thought they may originate in (marketing, finance, graphic design, etc.). Sadly, this decoupling likely isn't going away, and we're only bound to see the percentage of "bad" software increase over time. That's the sort of change that over time leads to people then changing their opinions of what "bad software" is. Look at how many people gleefully accept the landscape of smart-device "apps"....
- Matt G.
segaloco via COFF <coff@tuhs.org> writes: > COFF'd > [snip] > Long story short, most people don't know how their programs work because they aren't really "their" programs so much as their assembly of a number of off-the-shelf or slightly tweaked components following the norms of whatever school of thought they may originate in (marketing, finance, graphic design, etc.). Sadly, this decoupling likely isn't going away, and we're only bound to see the percentage of "bad" software increase over time. That's the sort of change that over time leads to people then changing their opinions of what "bad software" is. Look at how many people gleefully accept the landscape of smart-device "apps".... > > - Matt G. At my last $DAYJOB the developers were more or less not allowed to alter components that were acquired external to the company. That is to say, no "slightly tweaked" was permitted. If it was in house developed, that was another matter. This led to more then one occasion where a problem that could have been solved with a software fix to the product stack had to be dealt with in infrastructure because they would not fork something they acquired from github. Or they ended up utilizing the infrastructure in a very inefficient manor because they would not alter something or other and then blamed infrastructure for having bad behavior. I am pretty sure that the general understanding of what was being developed was low with most of that group. The development group was intentionally not writing software for the long haul. If something didn't work it was refactored, if possible and if the "it" was important enough, or infrastructure was blamed and made to work around the problem or they just forced the user community to deal with the problems (especially if the user community was in house coworkers). The life cycle of much of the code was less than 3 years and in a lot of cases was reimplemented every year (there were some exceptions, of course...). It may have been "bad software" but as long as it worked for its purpose right now, that really didn't matter. -- Brad Spencer - brad@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
Will Senn wrote in <3808a35c-2ee0-2081-4128-c8196b4732c0@gmail.com>: |Well, I just read this as Rust is dead... here's hoping, but seriously, |if we're gonna go off and have a language vs language discussion, I |personally don't think we've had any real language innovation since |Algol 60, well maybe lisp... sheesh, surely we're in COFF territory. It has evangelists on all fronts. ..Yes it was only that while i was writing the message i reread about Vala of the GNOME project, which seems to be a modern language with many beneficial properties still, growing out of a Swiss University (is that a bad sign to come from Switzerland and more out of research), and it had support of Ubuntu and many other parts of the GNOME project. Still it is said to be dead. I scrubbed that part of my message. But maybe thus a "dead" relation in between the lines remained. Smalltalk is also such a thing, though not from Switzerland. An Ach! on the mystery of human behaviour. Or, like the wonderful Marcel Reich-Ranicki said, "Wir sehen es betroffen, den Vorhang zu, und alle Fragen offen" ("Concerned we see, the curtain closed, and all the Questions open"). --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Steffen Nurpmeso wrote in <20230201192938.ozV2d%steffen@sdaoden.eu>: |Will Senn wrote in | <3808a35c-2ee0-2081-4128-c8196b4732c0@gmail.com>: ||Well, I just read this as Rust is dead... here's hoping, but seriously, ... Talking about dead, i suddenly had the braindead desire to reformat all my actively maintained things (sh,perl,python,C) in the Christian Christmas time. Quite sudden i was looking at the about 30 percent of my laptop screen that i actually use (COLUMNS=191 LINES=55, but that only after libxft-2.3.7 introduced a bug that is still not fixed, it was more more before (i was using Xft.embolden with LiberationMono which i had forgotten, but otherwise with Xft.antialias it looks terrible still .. with that many lines)), and was thinking "widescreen will never disappear again". Thus i dropped my yet always used attitude of 79 columns no matter what, went back to tabulator indentation, and now use 120 columns, without being strict (but max of about 140, as rarely as possible). (Some old legacy sources still use the old style, but anything planned to remain was converted.) If that is not stupid and brain dead, i do not know. Welcome back tabulators (it saved a lot of bytes!), and welcome new widescreen world. I do not regret it. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)