[TUHS] Algol rules: was something about Rust is not C++
Will Senn
will.senn at gmail.com
Wed Feb 1 10:50:31 AEST 2023
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)
More information about the TUHS
mailing list