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

[Will Senn]

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.

On 1/31/23 6:40 PM, Steffen Nurpmeso wrote:
> 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)