From: Will Senn <will.senn@gmail.com>
To: tuhs@tuhs.org
Subject: [TUHS] Algol rules: was something about Rust is not C++
Date: Tue, 31 Jan 2023 18:50:31 -0600 [thread overview]
Message-ID: <3808a35c-2ee0-2081-4128-c8196b4732c0@gmail.com> (raw)
In-Reply-To: <20230201004023.rHE9j%steffen@sdaoden.eu>
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@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@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)
next prev parent reply other threads:[~2023-02-01 0:52 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-30 17:24 [TUHS] yet another C discussion (YACD) and: " ron minnich
2023-01-30 18:47 ` [TUHS] " Andy Kosela
2023-01-30 18:59 ` segaloco via TUHS
2023-01-30 19:35 ` ron minnich
2023-01-30 21:37 ` Stuff Received
2023-01-31 1:47 ` Alejandro Colomar
2023-01-31 2:55 ` Dan Cross
2023-01-31 3:59 ` ron minnich
2023-01-31 12:26 ` Dan Cross
2023-02-01 0:40 ` Steffen Nurpmeso
2023-02-01 0:49 ` Larry McVoy
2023-02-01 1:03 ` Luther Johnson
[not found] ` <EjVurdhKm6O8BZ9n0FesPIsZH6sArmVbEN_ikfso8aNlawWIe8ElCGwgaT4ydoWHMNvRty9jDPxFxhLXVXGMjwsTfmfgLgKXcfjpLmqENT8=@protonmail.com>
2023-02-01 2:22 ` [TUHS] Re: yet another C discussion (YACD) Warren Toomey via TUHS
2023-02-01 0:50 ` Will Senn [this message]
2023-02-01 1:18 ` [TUHS] Re: Algol rules: was something about Rust is not C++ Chet Ramey
2023-02-01 1:24 ` Luther Johnson
2023-02-01 0:53 ` [TUHS] Re: yet another C discussion (YACD) and: " Steffen Nurpmeso
2023-02-01 16:34 ` Luther Johnson
2023-01-31 14:15 ` Blake McBride
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3808a35c-2ee0-2081-4128-c8196b4732c0@gmail.com \
--to=will.senn@gmail.com \
--cc=tuhs@tuhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).