[COFF] Re: [COFF from TUHS] Re: yet another C discussion (YACD) and: Rust is not C++

[COFF] Re: [COFF from TUHS] Re: yet another C discussion (YACD) and: Rust is not C++

[segaloco via COFF]

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.

[COFF] Re: [COFF from TUHS] Re: yet another C discussion (YACD) and: Rust is not C++

[Brad Spencer]

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

[COFF] Re: [TUHS] Algol rules: was something about Rust is not C++

[Steffen Nurpmeso]

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)

[COFF] Re: [TUHS] Algol rules: was something about Rust is not C++

[Steffen Nurpmeso]

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)