On 04/03/2024 3:10, dxf wrote:
> On 3/03/2024 4:54 pm, Ron AARON wrote:
>> One of the criteria for 8th was security -- among other things, making it very difficult to do unsafe memory operations.
>
> Has it paid off - by which I mean completed apps that out of the blue access
> invalid memory? I'm curious as to what exactly is behind the high rate of
> 'memory errors' that govt et al is reporting because in my limited experience
> programming in Forth, I'm just not seeing any. I wonder if it has something
> to do with the practices employed in those other languages - such as the use
> of third-party libraries which programmers use essentially on faith.

That's a good question, for which I don't have an answer nor even any
metrics on which to base one.

While I, personally, rarely write code that has those sorts of issues
(at least, not in 30 years), I have worked in places where they were
fairly common. It depends a lot on the expertise and attention to detail
of the programmers, I think.

Since 8th is intended for "application programmers" who may have little
experience, and since one of its primary goals is "security", I've made
it difficult to smash memory -- whether on purpose or accidentally. Of
course, that makes it stray considerably from standard Forths.

TL;DR: I don't really know.

Ron AARON wrote:
> While I, personally, rarely write code that has those sorts of issues
> (at least, not in 30 years), I have worked in places where they were
> fairly common. It depends a lot on the expertise and attention to detail
> of the programmers, I think.

I think it's also a question of the scale of the software. Forth programs
are usually microscopically small and manageable. Typical modern software
can reach gigabytes and must be created by a team of developers who sometimes
don't even work in the same place. The attack surface for errors is therefore
orders of magnitude larger. Then there is a need for many more a-priori
security functions already in the programming language and development tools,
followed by software engineering test procedures.

Krishna Myneni wrote:

> On 3/3/24 10:08, minforth wrote:
>> OTOH I doubt that there is any demand for a paranoia Forth
>> with safety belts and suspenders and alarm whistles.

> Perhaps not, but I wrote my Forth system to provide some hand-holding,
> primarily for my own needs. My expectation is that the demand for Forth
> systems which don't address safety concerns will rapidly drop to zero.

IIRC there have been a few Forth applications at NASA and for astronomy
(e.g. see Forth Inc. web site). I've already wondered how much convincing
had to be done for NASA not to disqualify Forth.

On 04/03/2024 9:39, minforth wrote:
> Ron AARON wrote:
>> While I, personally, rarely write code that has those sorts of issues
>> (at least, not in 30 years), I have worked in places where they were
>> fairly common. It depends a lot on the expertise and attention to
>> detail of the programmers, I think.
>
> I think it's also a question of the scale of the software. Forth programs
> are usually microscopically small and manageable. Typical modern software
> can reach gigabytes and must be created by a team of developers who
> sometimes
> don't even work in the same place. The attack surface for errors is
> therefore
> orders of magnitude larger. Then there is a need for many more a-priori
> security functions already in the programming language and development
> tools,
> followed by software engineering test procedures.

Yes, this too. Even when people are all in the same location, getting
everyone to work in the same direction and same style and follow the
rules can be challenging.

dxf <dxforth@gmail.com> writes:
>Has it paid off - by which I mean completed apps that out of the blue access
>invalid memory?

Out of the blue? That's not how it happens.

>I'm curious as to what exactly is behind the high rate of
>'memory errors' that govt et al is reporting because in my limited experience
>programming in Forth, I'm just not seeing any.

If you don't look, or if you look in the wrong place, you don't see.
The fact that a primitive technique like throwing random input at a
program caused many supposedly-debugged programs to misbehave shows
that programmers have blind spots, especially when it comes to their
own programs. And this has nothing to do with "gigabytes of
software", this was already found at times when machines were so small
that sizes of large programs were on the order of kilowords
<https://en.wikipedia.org/wiki/Fuzzing#Early_random_testing>.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

dxf wrote:

> What do I use while developing a recursive function: ?STACK.

Yes and no:

Gforth 0.7.9_20200709
Authors: Anton Ertl, Bernd Paysan, Jens Wilke et al., for more type `authors'
Copyright © 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `help' for basic help
drop depth
*the terminal*:1:1: error: Stack underflow
>>>drop<<< depth
: TEST drop depth ; ok
test <<<--- CRASH!!

On 3/4/24 01:52, minforth wrote:
> Krishna Myneni wrote:
>
>> On 3/3/24 10:08, minforth wrote:
>>> OTOH I doubt that there is any demand for a paranoia Forth
>>> with safety belts and suspenders and alarm whistles.
>
>> Perhaps not, but I wrote my Forth system to provide some hand-holding,
>> primarily for my own needs. My expectation is that the demand for
>> Forth systems which don't address safety concerns will rapidly drop to
>> zero.
>
> IIRC there have been a few Forth applications at NASA and for astronomy
> (e.g. see Forth Inc. web site). I've already wondered how much convincing
> had to be done for NASA not to disqualify Forth.

The trend has been to go to "memory-safe" languages. There are many
instances in which simple run-time type checking for addresses have
resulted in saving me considerable debugging time -- usually just stack
order is incorrect, but the error can manifest in more complex ways as well.

I don't have any particular insight into the trends other than following
the news. I think there will be even greater pressure going forward to
use memory-safe languages for internet facing applications. The shift in
academia towards those languages appears to have already happened. My
daughter's first year CS class uses python.

--
Krishna

Krishna Myneni wrote:

> On 3/4/24 01:52, minforth wrote:
>> Krishna Myneni wrote:
>>
>>> On 3/3/24 10:08, minforth wrote:
>>>> OTOH I doubt that there is any demand for a paranoia Forth
>>>> with safety belts and suspenders and alarm whistles.
>>
>>> Perhaps not, but I wrote my Forth system to provide some hand-holding,
>>> primarily for my own needs. My expectation is that the demand for
>>> Forth systems which don't address safety concerns will rapidly drop to
>>> zero.
>>
>> IIRC there have been a few Forth applications at NASA and for astronomy
>> (e.g. see Forth Inc. web site). I've already wondered how much convincing
>> had to be done for NASA not to disqualify Forth.

> The trend has been to go to "memory-safe" languages. There are many
> instances in which simple run-time type checking for addresses have
> resulted in saving me considerable debugging time -- usually just stack
> order is incorrect, but the error can manifest in more complex ways as well.

> I don't have any particular insight into the trends other than following
> the news. I think there will be even greater pressure going forward to
> use memory-safe languages for internet facing applications. The shift in
> academia towards those languages appears to have already happened.

This is why web assembly is on the rise. Many languages can already be
compiled to wasm. See
https://webassembly.org/docs/security/

However, I found only a few wasm-based Forths on the net.

minforth@gmx.net (minforth) writes:
> IIRC there have been a few Forth applications at NASA and for astronomy
> (e.g. see Forth Inc. web site).

I wonder if any of those applications were written in the current
century.

dxf <dxforth@gmail.com> writes:
> Has it paid off - by which I mean completed apps that out of the blue
> access invalid memory?

It could be that catching more of those errors during development means
fewer make it out to deployment.

> I'm curious as to what exactly is behind the high rate of 'memory
> errors' that govt et al is reporting because in my limited experience
> programming in Forth, I'm just not seeing any.

The programs with the memory errors are likely more complicated than
typical Forth programs, deal with more maliciously crafted inputs, and
make heavier use of dynamic memory allocation than small embedded
programs are likely to. My own Forth experience is even more limited,
but in it, I haven't even used arrays very much, especially for
user-supplied data.

On 01/03/2024 18:02, Anton Ertl wrote:
> mhx@iae.nl (mhx) writes:
>> What if the program writes a float to a byte location?
>
> That's not a safety problem (as long as the location is big enough for
> the float), so one can design a Safe Forth variant that allows that.

I'm not very familiar with forth yet, does this refer to writing to a
machine addressed location? If so, plenty of computers have alignment
requirements, a DoS can be introduced by the above action.

Also, if you write a byte to a float location, a variety of problems can
be introduced including running trap callbacks that were insufficiently
tested for the new program state, etc, killing the process and running
restart sequences where less volatile state can now be in an unusual
condition and new side-effects induced, and so on.

memory safety means maintaining invariant relations wrt. each memory
location.

On 4/03/2024 6:57 pm, Anton Ertl wrote:
> dxf <dxforth@gmail.com> writes:
>> Has it paid off - by which I mean completed apps that out of the blue access
>> invalid memory?
>
> Out of the blue? That's not how it happens.
>
>> I'm curious as to what exactly is behind the high rate of
>> 'memory errors' that govt et al is reporting because in my limited experience
>> programming in Forth, I'm just not seeing any.
>
> If you don't look, or if you look in the wrong place, you don't see.
> The fact that a primitive technique like throwing random input at a
> program caused many supposedly-debugged programs to misbehave shows
> that programmers have blind spots, especially when it comes to their
> own programs.
> ...

Yes but asking the system to find errors isn't looking - it's covering
one's butt.

dxf <dxforth@gmail.com> writes:
> Yes but asking the system to find errors isn't looking - it's covering
> one's butt.

If the implementer doesn't find them and the system doesn't find them,
that leaves them for the attackers to find. Wasn't that what you were
asking about? We are learning that the best way to prevent attackers
from finding such errors is to use tools (e.g. languages) that prevent
those errors from occurring in the first place.

Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> writes:
>On 01/03/2024 18:02, Anton Ertl wrote:
>> mhx@iae.nl (mhx) writes:
>>> What if the program writes a float to a byte location?
>>
>> That's not a safety problem (as long as the location is big enough for
>> the float), so one can design a Safe Forth variant that allows that.
>
>I'm not very familiar with forth yet, does this refer to writing to a
>machine addressed location?

Yes.

>If so, plenty of computers have alignment
>requirements,

In general-purpose computers, that used to be the case in the 1990s,
but nowadays it is no longer the case. We have to use really old
hardware to test against alignment errors, and even on hardware that
has alignment requirements (like our 21264B machine from 2000), the OS
(Linux) emulates the behaviour of computers without these requirements
when the program performs an unaligned access, and I had to write a
special program to get signals for unaligned accesses
<https://www.complang.tuwien.ac.at/anton/uace.c>. And while the Linux
command setarch can turn on various compatibility features for old
programs, such as turning off ASLR, it does not include a feature for
making unaligned accesses trap on the appropriate hardware.

In any case, if we want to avoid unaligned FP accesses, one can design
a memory-safe Forth dialect such that it prevents unaligned FP
accesses, but not accessing the same memory as bytes and as FP values.

However, despite all that, my plan is to design Safe Forth in a way
where the commonly-used words do not support such kinds of accesses,
because the result will make most programming tasks easier. For
specialized uses there may be words that just treat the memory as
bytes, though.

>a DoS can be introduced by the above action.

DoS and more serious vulnerabilities can be introduced in lots of ways
in memory-safe programming languages, whether some mechanism prevents
writing floats to a byte location or not.

However, I should refine my sentence above to: "That's not a
memory-safety problem ...".

>Also, if you write a byte to a float location, a variety of problems can
>be introduced including running trap callbacks that were insufficiently
>tested for the new program state, etc, killing the process and running
>restart sequences where less volatile state can now be in an unusual
>condition and new side-effects induced, and so on.

Memory safety does not guarantee bug-freedom.

However, what you write appears to be a case of "Bedenkentraeger",
imagining all kinds of possible or impossible problems in order to
argue against something. In the present case, impossible problems:

In Gforth no floating-point operation traps, and I intend to keep that
behaviour for Safe Forth.

There is also no way to write "trap callbacks". If there was, and a
programmer used it, and it was insufficiently tested, the problem
would be that the code was insufficiently tested, not in writing the
byte to an address where later an FP value is read from.

Because there is no trap and no trap callback, the process is not
killed, and no restart sequence is run. If it was, the condition of
process-surviving state would be something that would have to be made
safe whether the system prevents accessing bytes and FP values at the
same addresses or not.

>memory safety means maintaining invariant relations wrt. each memory
>location.

So?

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

On 05/03/2024 06:35, Anton Ertl wrote:
> Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> writes:

....

>> If so, plenty of computers have alignment
>> requirements,
>
> In general-purpose computers, that used to be the case in the 1990s,
> but nowadays it is no longer the case. We have to use really old
> hardware to test against alignment errors. ...

Or special purpose computers that are not mass marketed, but I wasn't
aware they'd fixed all the public market computers. Thanks for the info.

On 05-03-2024 00:03, Tristan Wibberley wrote:
> On 01/03/2024 18:02, Anton Ertl wrote:
>> mhx@iae.nl (mhx) writes:
>>> What if the program writes a float to a byte location?
>>
>> That's not a safety problem (as long as the location is big enough for
>> the float), so one can design a Safe Forth variant that allows that.
>
> I'm not very familiar with forth yet, does this refer to writing to a
> machine addressed location? If so, plenty of computers have alignment
> requirements, a DoS can be introduced by the above action.
>
> Also, if you write a byte to a float location, a variety of problems can
> be introduced including running trap callbacks that were insufficiently
> tested for the new program state, etc, killing the process and running
> restart sequences where less volatile state can now be in an unusual
> condition and new side-effects induced, and so on.
>
> memory safety means maintaining invariant relations wrt. each memory
> location.

This entire discussion really made me laugh. How sentiments change..
I can remember when I wrote 4tH people were dismissing it, because of
its safety features: "This is not Forth".

But 4tH addresses most of the issues at hand. You cannot write a float
on a character, because those reside in different segments. You cannot
overwrite execution code - because that not only resides in a different
segment, but it's also "read only".

If your execution pointer goes outside the code segment, the program
simply stops. If you do a MOVE - any MOVE - it will check the bounds
before going at it at C speed.

Now - I won't say you can't do any damage. It doesn't do any array
bounds checking, so a string can spill into another string. But it will
not spill outside its segment. If you use a random integer value as a
pointer, it will be okay to corrupt anything inside that segment, but
not *OUTSIDE* that segment. And frankly, that's all the safety I need.

If you think you will revive Forth by jumping on that Rust bandwagon, I
think you're wrong. You won't attract a new audience and you won't get
the acceptance you crave for. First and foremost, because I think Rust
is the wrong idea. It's been tried before - Ada, Pascal, Java - in some
sense: BASIC.

Good programmers exist because they are good programmers. Bad programs
exist because of bad programmers. Let me quote one of the foremost CS
scientists who ever lived:

"Ada will not meet its major objective, viz. that of reducing software
costs by standardization, and it will not be the vehicle for programs we
can rely upon, for it is so complicated that it defies the unambiguous
definition that is essential for these purposes. Long before the design
was frozen, computing scientists from all over the world have given
plenty of warning but the political body in question preferred to ignore
these warnings and to decide on a design that cannot be salvaged. From a
scientific point of view all further attention paid to Ada is a waste of
effort. But the sheer buying-power of the DoD makes Ada an undeniable
reality, which in combination with DARPA's policies for the funding of
software research can only increase the pressure to spend research
effort on the wrong problems.

Another series of stones in the form of "programming tools" is produced
under the banner of "software engineering", which, as time went by, has
sought to replace intellectual discipline by management discipline to
the extent that it has now accepted as its charter "How to program if
you cannot."

Let that sink in: "It will not be the vehicle for programs we can rely
upon, for it is so complicated that it defies the unambiguous definition
that is essential for these purposes". That is the very definition of Rust.

All the time you're spending getting your code to compile, you're not
creating programs. I'd say that's the reverse of productivity. The
higher the abstraction, the more difficult it is to understand - let
alone to teach.

Compare "pointer" to "a variable containing an address", the beauty of
"an object" to "a structure with a few function pointer fields" and a
bunch of syntactic sugar (i.e. object.method vs. method(object)).

Lifetimes? Borrowing? Are you kidding me? After programming in Forth for
over 30 years now, I'm slowly getting why I get things done in Forth
that I would never have imagined to tackle in C. Forth has some
remarkable principles. The stack is one of them. The principle "execute,
throw on the stack or throw an error" is another one. The dictionary,
consisting of a function pointer and a string is another one.

Simple principles, simple to grasp, but very powerful - especially when
combined. ColorForth added a few more, BTW.

I tend to trust my Forth programs a lot more than my C ones, for the
simple reason that there were a million (stack) errors I could have made
along the way - every single one of them capable of turning my beautiful
program into a steaming pile of dung.

So, safety, yes. I like that very much. I ventured into that very early
and I never regretted it. But apart from some basic checks it should
stop at the point where I have to convince a compiler that I know what
I'm doing.

Hans Bezemer

On 05-03-2024 00:03, Tristan Wibberley wrote:
> On 01/03/2024 18:02, Anton Ertl wrote:
>> mhx@iae.nl (mhx) writes:
>>> What if the program writes a float to a byte location?
>>
>> That's not a safety problem (as long as the location is big enough for
>> the float), so one can design a Safe Forth variant that allows that.
>
> I'm not very familiar with forth yet, does this refer to writing to a
> machine addressed location? If so, plenty of computers have alignment
> requirements, a DoS can be introduced by the above action.
>
> Also, if you write a byte to a float location, a variety of problems can
> be introduced including running trap callbacks that were insufficiently
> tested for the new program state, etc, killing the process and running
> restart sequences where less volatile state can now be in an unusual
> condition and new side-effects induced, and so on.
>
> memory safety means maintaining invariant relations wrt. each memory
> location.
This entire discussion really made me laugh. How sentiments change..
I can remember when I wrote 4tH people were dismissing it, because of
its safety features: "This is not Forth".

But 4tH addresses most of the issues at hand. You cannot write a float
on a character, because those reside in different segments. You cannot
overwrite execution code - because that not only resides in a different
segment, but it's also "read only".

If your execution pointer goes outside the code segment, the program
simply stops. If you do a MOVE - any MOVE - it will check the bounds
before going at it at C speed.

Now - I won't say you can't do any damage. It doesn't do any array
bounds checking, so a string can spill into another string. But it will
not spill outside its segment. If you use a random integer value as a
pointer, it will be okay to corrupt anything inside that segment, but
not *OUTSIDE* that segment. And frankly, that's all the safety I need.

If you think you will revive Forth by jumping on that Rust bandwagon, I
think you're wrong. You won't attract a new audience and you won't get
the acceptance you crave for. First and foremost, because I think Rust
is the wrong idea. It's been tried before - Ada, Pascal, Java - in some
sense: BASIC.

Good programmers exist because they are good programmers. Bad programs
exist because of bad programmers. Let me quote one of the foremost CS
scientists who ever lived:

"Ada will not meet its major objective, viz. that of reducing software
costs by standardization, and it will not be the vehicle for programs we
can rely upon, for it is so complicated that it defies the unambiguous
definition that is essential for these purposes. Long before the design
was frozen, computing scientists from all over the world have given
plenty of warning but the political body in question preferred to ignore
these warnings and to decide on a design that cannot be salvaged. From a
scientific point of view all further attention paid to Ada is a waste of
effort. But the sheer buying-power of the DoD makes Ada an undeniable
reality, which in combination with DARPA's policies for the funding of
software research can only increase the pressure to spend research
effort on the wrong problems.

Another series of stones in the form of "programming tools" is produced
under the banner of "software engineering", which, as time went by, has
sought to replace intellectual discipline by management discipline to
the extent that it has now accepted as its charter "How to program if
you cannot."

Let that sink in: "It will not be the vehicle for programs we can rely
upon, for it is so complicated that it defies the unambiguous definition
that is essential for these purposes". That is the very definition of Rust.

All the time you're spending getting your code to compile, you're not
creating programs. I'd say that's the reverse of productivity. The
higher the abstraction, the more difficult it is to understand - let
alone to teach.

Compare "pointer" to "a variable containing an address", the beauty of
"an object" to "a structure with a few function pointer fields" and a
bunch of syntactic sugar (i.e. object.method vs. method(object)).

Lifetimes? Borrowing? Are you kidding me? After programming in Forth for
over 30 years now, I'm slowly getting why I get things done in Forth
that I would never have imagined to tackle in C. Forth has some
remarkable principles. The stack is one of them. The principle "execute,
throw on the stack or throw an error" is another one. The dictionary,
consisting of a function pointer and a string is another one.

Simple principles, simple to grasp, but very powerful - especially when
combined. ColorForth added a few more, BTW.

I tend to trust my Forth programs a lot more than my C ones, for the
simple reason that there were a million (stack) errors I could have made
along the way - every single one of them capable of turning my beautiful
program into a steaming pile of dung.

So, safety, yes. I like that very much. I ventured into that very early
and I never regretted it. But apart from some basic checks it should
stop at the point where I have to convince a compiler that I know what
I'm doing.

Hans Bezemer

Tristan Wibberley wrote:

> On 05/03/2024 06:35, Anton Ertl wrote:
>> Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> writes:

> ....

>>> If so, plenty of computers have alignment
>>> requirements,
>>
>> In general-purpose computers, that used to be the case in the 1990s,
>> but nowadays it is no longer the case. We have to use really old
>> hardware to test against alignment errors. ...

> Or special purpose computers that are not mass marketed, but I wasn't
> aware they'd fixed all the public market computers. Thanks for the info.

You are still in for some nasty surprises with "public market" ARM CPUs.
f.ex.
https://developer.arm.com/documentation/den0013/d/Porting/Alignment

On 5/03/2024 4:17 pm, Paul Rubin wrote:
> dxf <dxforth@gmail.com> writes:
>> Yes but asking the system to find errors isn't looking - it's covering
>> one's butt.
>
> If the implementer doesn't find them and the system doesn't find them,
> that leaves them for the attackers to find. Wasn't that what you were
> asking about? We are learning that the best way to prevent attackers
> from finding such errors is to use tools (e.g. languages) that prevent
> those errors from occurring in the first place.

AFAIK hacks are opportunistic i.e. could not reasonably be foreseen.
Such "errors" are forgivable. Not so, programmers who either don't
know where something might overflow, or knowing, fail to address it.

dxf <dxforth@gmail.com> writes:
> AFAIK hacks are opportunistic i.e. could not reasonably be foreseen.
> Such "errors" are forgivable. Not so, programmers who either don't
> know where something might overflow, or knowing, fail to address it.

Humans make errors. The world's smartest mathematicians have published
proofs with mistakes. Today, there is a community that likes to
machine-check math proofs to make sure they are sound. It's the same
thing with memory-safe languages. We don't have practical ways to make
sure programs are free of all errors, but we can make sure they are free
of some common and significant types of them.

Hans Bezemer wrote:
> I tend to trust my Forth programs a lot more than my C ones

Maybe you're a lousy, careless C programmer? (pun intended ;-))

But I agree with you that the world doesn't need a Safe Forth.

Still, everyone has their favourite baby (like you have your 4th)
and you can still learn a few things while exploring additional
security features and enjoy it for the intellectual exercise, as
Anton seems to be doing with gforth.

By the way, I don't want to go off on a tangent here. I use
security features myself (not in MinForth though), because the
cost of repairing faulty devices in remote locations are too high
to be careless.

The solution is a separate DSL (on top of a Forth nucleus) that
does not allow any direct memory access. Very simple sandboxing.

Hans Bezemer <the.beez.speaks@gmail.com> writes:
> If you think you will revive Forth by jumping on that Rust bandwagon,
> I think you're wrong.

Probably true, Forth users want something different than what Rust aims
to supply.

> First and foremost, because I think Rust is the wrong idea. It's been
> tried before - Ada, Pascal, Java - in some sense: BASIC.

BASIC's heyday was before my time, but it was very popular in a certain
crowd. Java was extremely successful in industry and I think it was at
the top of TIOBE for a while (it is #4 now). #1 is currently Python
which can be seen as a successor to BASIC. Pascal was intentionally
limited (it was intended as an instructional language) and yet it had
its own era of popularity because of Turbo Pascal and the P-system.

Ada was overcomplicated, but I think it also didn't gain traction
because the early Ada compilers were slow and expensive. If GNAT had
been available from the beginning, Ada would have gotten more use, imho.

> Good programmers exist because they are good programmers. Bad programs
> exist because of bad programmers.

The best programmers I know have released code with memory errors, so at
a certain point you have to stop blaming the human for being less
accurate than a machine.

> "Ada will not meet its major objective... for it is so complicated
> that it defies the unambiguous definition that is essential for these
> purposes.

It's not particularly more complicated than C++ as far as I can tell,
and C++ is currently #3 on TIOBE.

> "...for it is so complicated...". That is the very definition of Rust.

> All the time you're spending getting your code to compile, you're not
> creating programs.

Would you say the same of time you spend fixing bugs that you find
during testing?

> I'd say that's the reverse of productivity. The higher the
> abstraction, the more difficult it is to understand - let alone to
> teach.

Picking the right level of abstraction to handle a problem is an
important skill in programming just like it is in math. We spend a lot
of time studying abstractions in math because they are useful. That
turns out to be true in programming as well.

> Lifetimes? Borrowing? Are you kidding me?

This is just the language handling and checking an abstraction that
people have been doing manually long before Rust. If you look at the
CPython implementation, it does memory management by reference counting,
and it constantly uses the ideas of borrowed references internally.

I would say today though, most application programmers don't need Rust.
They will be more productive with garbage collected languages, at the
expense of some machine resources. Rust is for when those resources
can't be spared.

> So, safety, yes. I like that very much. I ventured into that very
> early and I never regretted it. But apart from some basic checks it
> should stop at the point where I have to convince a compiler that I
> know what I'm doing.

I see it the other way. If the compiler can find every error in my
program of type X, then simply fixing the program until the compiler
accepts it means I get a program that is free of that type of error.
That increases my confidence in the program. The trade-off is that such
features can make the language and the compiler harder to use. A big
part of research in languages is widening the classes of errors that the
compiler can check without the language becoming too difficult.

On 6/03/2024 5:03 am, Paul Rubin wrote:
> dxf <dxforth@gmail.com> writes:
>> AFAIK hacks are opportunistic i.e. could not reasonably be foreseen.
>> Such "errors" are forgivable. Not so, programmers who either don't
>> know where something might overflow, or knowing, fail to address it.
>
> Humans make errors. The world's smartest mathematicians have published
> proofs with mistakes.

They don't make basic ones. By nature programming is defensive and
overflow would be high - if not at the top - of things a programmer
is continually evaluating. Here's a CLI app from several years ago:

https://pastebin.com/0B6kaYFJ

At no time during its writing did I consider hackers or inept users.
Responsible programming was all.

What does worry me is how programmers are being encouraged to fear
unknown terrors and to doubt their capacity to think or manage the
situation. It borders on the religious.

dxf <dxforth@gmail.com> writes:
> At no time during its writing did I consider hackers or inept users.
> Responsible programming was all.

Very nice. Back in the 1980s all of us did that. Then something called
the internet came along, as did computerized banking and other systems
which attracted highly competent malicious and/or financially motivated
attackers. At that point, writing bulletproof code became not only much
harder, but also vitally important. You now must ensure not only that
your program can do what you intended, but that it can't do what you
didn't intend. Bruce Schneier[1] wrote about security engineering:

In many ways this is similar to safety engineering. ... But safety
engineering involves making sure things do not fail in the presence
of random faults: it’s about programming Murphy’s computer, if you
will. Security engineering involves making sure things do not fail
in the presence of an intelligent and malicious adversary who forces
faults at precisely the worst time and in precisely the worst
way. Security engineering involves programming Satan’s computer.
And Satan’s computer is hard to test.

[1] https://www.schneier.com/essays/archives/1999/11/why_computers_are_in.html

So sure, if you're claiming that 1980s programming didn't benefit from
memory safe languages, maybe you're right. Those of us who have to
program in the 21st century, though, need all the help we can get.

On 6/03/2024 11:54 am, Paul Rubin wrote:
> ...
> Those of us who have to
> program in the 21st century, though, need all the help we can get.

"There is no hardware protection. Memory protection can be provided by
the access computer. But I prefer software that is correct by design." - C.M.