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

[Steffen Nurpmeso]

ron minnich wrote in
 <CAP6exY+Qz2Oe4gC4D1Fqy22JKKDaanTOYpc0gxugBv485JUknQ at mail.gmail.com>:
 |That example was a simplified bit of code from a widely used code base. All
 |I need to do is change the function g go a pointer to function, or have it
 |be provided by a .so, and all bets are off.
 |
 |In any event, the important thing here is not that y should be initialized,
 |or should not; it's that it is not possible to get a consistent answer on
 |the question, from people who have been writing in C for decades.

I find the syntax just terrible.  (I have not programmed with it.)
I mean annotations are for the better, ok, (but i luckily get away
with only "const" and "volatile" (and "mutable"), and leave things
like "restrict" be a good man).  Johannes Lundberg i think it was
who then left FreeBSD (?) but pointing to a Rust program
he had written (i cannot find the reference), that was a few years
ago (i looked once i composed this message first, it might even
had been as early as 2017!), and i was lucky i do not have to deal
with it.

Even nim-lang.org that at least converted its code to plain C back
in the day when it was still called Nimrod is too heavy for me now,
but claims to be hard realtime aware etc.  It at least tries to
give programmers some syntactic sugar that makes people happy when
they look at the screen for 7 hours (underpaid) or 16 hours
(over-ambitioned).  Like the only python thing i like, the
syntax sugar.  But as languages grow they get more and more
"refined", and now i read things like

  type
    BinaryTree*[T] = ref object # BinaryTree is a generic type with
                                # generic param `T`
      le, ri: BinaryTree[T]     # left and right subtrees; may be nil
      data: T                   # the data stored in a node

  proc newNode*[T](data: T): BinaryTree[T] =
    # constructor for a node
    new(result)
    result.data = data

which gets me off a bit and makes me think that "hey, maybe
Objective-C is not really the worst thing" (despite the syntax).

I do not know.  Everything beyond a small monolithic
self-contained thing is a problem per se.  You can then unit test
atomically, and if thousands of modules do that, you plug them to
a better whole.  But that also not a good answer, all those flakes
that live their own life, many maybe even in remote locations out
of any control.

You could have a language which hard fixates all the call chain,
or you could have tools which bring this to a small and simple
language which does not offer it.  A compiler can figure out which
variables are assigned etc and could create in-object-file
annotations which the linker automatically verifies.
Of course there are many code paths through functions.

Back in 2009 when i bought the one Apple i wanted to have i tried
out their Development software, which i think required internet
access.  All the pop-ups and titles, i think it (later?) could
compile on-the-fly and inject the new object in the running tested
application, etc.

And then there are semantic description languages like interface
builders, where robots create the actual code.  So then you could
have Corba interface descriptions / DBUS and plug it all via it.

Then Rob Pike says "make it a string" (more or less), and luckily
i do not have dyslexia.

Maybe Qt has a good answer by not only not banishing the
C preprocessor, but introducing another one on top.
So then the compiler can analyze the code and generate a correct
variable-state-at-function-call-time state that a dynamic linker
could then verify against the consumer or producer (whatever is
needed) of linked modules, that link modules, that link modules,
all of which are subject to replacements due to development
iterations, bug patches etc, ie, new releases.

As in, the library versioning that is used for ELF object files,
today often even linker scripts which furtherly diversify this,
offer are not enough, they do not do this.  They only bundle
a name to a library version, or multiple (as in

   1966 FUNC    GLOBAL DEFAULT   13 realpath@@GLIBC_2.3
     33 FUNC    GLOBAL DEFAULT   13 realpath at GLIBC_2.2.5)

I do not know how Rust deals with this.  Is it at all possible to
fixate all the call chain over all possibly involved dynamics?
What do i gain from initializing an object with a default value if
that default value is not not not not one of the values that
i expect after some external function is called?

Sure i not rarely see patches fly by where one more memset(,0,) is
used to fully initialize a struct / prevent memory address
disclosures (i only track BSDs).
And there are still patches that fix bugs on old code that
sometimes is twenty years or more, say zlib or tzcode.
And then there are compiler bugs that bring in bugs -- that is not
avoidable, even if the documentation is clear and obvious like

/* The application can compare zlibVersion and ZLIB_VERSION for consistency.
   If the first character differs, the library code actually used is not
   compatible with the zlib.h header file used by the application.  This check
   is automatically made by deflateInit and inflateInit.
 */

That is only graspable by a human programmer that reads it.  Rapid
application development that surely is not.
(And actually i am not sure this is really true.  But i personally
would hope for it.  It is more earthy, and has more blood, sweat
and tears.)

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