Computer Old Farts Forum
 help / color / mirror / Atom feed
From: segaloco via COFF <>
Cc: COFF <>
Subject: [COFF] Re: [COFF from TUHS] Re: yet another C discussion (YACD) and: Rust is not C++
Date: Wed, 01 Feb 2023 01:50:05 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>


> 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.

       reply	other threads:[~2023-02-01  1:50 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
     [not found] ` <>
     [not found]   ` <>
     [not found]     ` <>
     [not found]       ` <>
     [not found]         ` <>
     [not found]           ` <>
     [not found]             ` <>
     [not found]               ` <>
     [not found]                 ` <>
2023-02-01  1:50                   ` segaloco via COFF [this message]
2023-02-01 13:41                     ` Brad Spencer
     [not found]               ` <>
2023-02-01 19:29                 ` [COFF] Re: [TUHS] Algol rules: was something about " Steffen Nurpmeso
2023-02-01 20:00                   ` Steffen Nurpmeso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).