On 10/08/2022 09:24, Luke A. Guest wrote:
>On 10/08/2022 02:19, John Perry wrote:
>> On Monday, August 8, 2022 at 11:12:48 PM UTC-5, Randy Brukardt wrote:
>>> "Dmitry A. Kazakov" wrote in message
>>> ...
>>>> P.S. Nobody writes Ada books these days because they do not sell.
>>> Do *any* programming books really sell? If so, why? :-)
>>
>> Having recently left a university, I can attest that schoolbooks are still a thing, and that includes textbooks on computer programming. I recently inherited from a member of this forum a nice textbook on Data Structures in Ada, but it was based on Ada 95, and I'm not sure it's in print anymore. In fact, and alas, only three of the Ada-based textbooks I find "easily" on Amazon date from the early- to mid-90s, and of the three recent ones I find, only the Barnes book is of good quality.
>>
>> I'd be delighted if someone would prove me wrong.
>
>The only Ada95 DS book I know of is the one I have by Mark Weiss.

There are at least 2 others; "Data Structures and Algorithms: An
Object-Oriented Approach Using Ada 95",by Jack Beidler, and "Software
Construction and Data Structures with Ada 95",by Michael Feldman, both of
which I own, and both decent books IMO, although based on a 27yr old
language :-)

--
Best Regards

On 27/8/22 09:21, Jeffrey R.Carter wrote:
> On 2022-08-26 20:59, Olivier Henley wrote:
>>
>> If there is no intentional wordplay between "Rust" and "Carbon", I
>> will be damned.
>
> Carbon's symbol is C, so I presumed that was where the name came from.
> Of course, that means Carbon and C are the same thing ...
>

So the next incarnation of Ada might be Adamantium ? ... :)

On Saturday, August 27, 2022 at 6:27:35 AM UTC-5, roda... @gmail.com wrote:
> On 27/8/22 09:21, Jeffrey R.Carter wrote:
> > On 2022-08-26 20:59, Olivier Henley wrote:
> >>
> >> If there is no intentional wordplay between "Rust" and "Carbon", I
> >> will be damned.
> >
> > Carbon's symbol is C, so I presumed that was where the name came from.
> > Of course, that means Carbon and C are the same thing ...
> >
> So the next incarnation of Ada might be Adamantium ? ... :)

+1 Imagine the benefits to marketing and web search! :-D

Regarding the earlier question of why people don't use Ada, when I used to ask others why C++ and not Ada, the usual answer I heard was, "Isn't Ada dead?" People might have cited others as well, but they typically led with that one-- unless it was, "Never heard of it!"

On 25/08/2022 10:14, Fabien Chouteau wrote:
>On Wednesday, July 27, 2022 at 7:24:58 PM UTC+2, John McCabe wrote:
>> The result is that someone who appears to have
>> very little software development experience misinterpreted the comments
>> about half-baked features and locked the thread.
>
>I think they did the right thing. And provided explanations:

The issue with this is that, as I mentioned, they misinterpreted what I'd
said. I specifically mentioned that new, half-baked, features were being
added to the language, which they are. I don't know if you've used
C++11/14/17/20 in anger Fabien, but anyone who doesn't think the partial,
but awkward to use, addition of coroutines in C++20, with the promise of
'improvements' in C++23 is anything but 'half-baked' is deluded. There are
numerous other, specific features I was able to itemise in a discussion
with another person involved in that thread.

In particular, the person who made that misinterpretation and comment, and
closed the thread, is someone who has been involved with C++ standards
development so 1) clearly did not have an objective view on the comments,
and 2) makes me believe the Carbon 'team' don't actually care about what's
'right' for the industry.

>I don't know if the people working on Carbon had a bad opinion about Ada before, but sure do now.

The people working on Carbon clearly don't give a sh1t about Ada; if they
did, they would not be proposing to 'supersede' C++ by creating a language
that includes many of the fault-ridden features of that language, a lot of
which had been solved in Ada before C++ was a twinkle in Stroustrop's eyes.

>In the end I think that you did a lot of damage to Ada, its reputation and its community...

That's your opinion, and you're entitled to it.

-

On 25/08/2022 18:55, John Perry wrote:
>On Thursday, August 25, 2022 at 4:14:02 AM UTC-5, Fabien Chouteau wrote:
>> On Wednesday, July 27, 2022 at 7:24:58 PM UTC+2, John McCabe wrote:
>> > The result is that someone who appears to have
>> > very little software development experience misinterpreted the comments
>> > about half-baked features and locked the thread.
>>
>> I think they did the right thing. And provided explanations:
>>
>> > There are obviously changes that we'd like to make to C++, but calling C++ "half-baked" is demeaning to those who have invested years of work into that project.
>>
>> >> TBH, this whole project just appears to be Google trying to detract from Rust
>> > This is disrespectful to everyone working on the Carbon Language project.
>>
>> I agree with both.
>
>I can agree with the statements you've quoted, and I can agree with their closing the thread (they didn't delete it!) but he also called them "aggressive" statements, and that's simply untrue. Assertive and strongly-worded? sure, but aggressive?

They claimed the use of:

- 'nonsense', in relation to features such as the confusion between "=" and
"==", where an assignment has a result that can be used as a condition etc,
and the multiple uses of "&&",
- 'half-baked', in relation to features that have been partially added in
earlier, and current revisions of the language, and have changed, or will
change, or have been deprecated in subsequent revisions, as well as
features that have been compromised in the standard because "clang
implements an existing way which makes it hard for them to change"

was aggressive. I disagree, of course.

On 26/08/2022 21:23, Paul Rubin wrote:
>Olivier Henley <olivier.henley@gmail.com> writes:
>> This is not aggression. We need to stop relativizing definitions.
>
>I would call the first post somewhat aggressive, though not intensely
>so. It dinged on the C++ community ("I find it shocking...")

Did it ding on the C++ community any more than an announcement of Google
trying to design a language that will supersede C++?

> and
>suggested by apophasis ( https://en.wikipedia.org/wiki/Apophasis ) that
>the Carbon devs should abandon their project and using Ada instead
>("that might not be a bad idea").

That was never the intention; the point was to highlight the fact that there
is at least one, high-performance, safe, language in existence that
addresses a number of the annoyances and inadequacies of C++, and that
anyone trying to 'replace' C++ should consider how they can take advantage
of work that's already been done in that area.

>It also treated some debateable
>points as self-evident, such as that enumeration types should always
>support 'Image.

I don't think I said that. Java doesn't support 'Image, but they made it
easy for you to provide your own' equivalent'; my point was that C++'s enum
class could've gone further than it did (std::array, too), and provided
some additional support for commonly needed features that many people have
created complicated pre-processor macros to implement.

>It seems reasonable to me for the Carbon forum moderators to disallow
>and shut down language debates of any kind, even if they are not
>aggressive per se. We've all seen enough of those to know how they go.
>That particular language debate was especially off-topic since it was an
>Ada vs C++ comparison on a Carbon forum. Ada vs Carbon would have been
>better.

I disagree; the forum is supposed to be about the language design, as the
claimed aim is to use the community to help drive it. IMO, this is exactly
the place to discuss features of other languages that could be considered
useful in a 'new' language, unless the 'community' aspect is fake and the
'design' is mostly a done deal.

>The second post came across to me as even more aggressive ("Can you
>please specify..."). It was full of what is sometimes called
>"sea-lioning", a classic passive-aggressive debating technique:
>
> https://en.wikipedia.org/wiki/Sealioning

The second post, I presume you mean the response to mine, was _very_
aggressive.

>I didn't read the later posts that were flagged as off-topic, since you
>have to be logged in to view them.

One rational response arguing against the 'aggressive' claim, and a couple
of other defensive 'team' members getting the wrong end of the stick, from
what I remember.

>> Hordes of people wrote that (along those lines --> "Ada typing is
>> nonsense, crazy, mad, stupid, etc") and nobody in this community ever
>> canceled them by weaponizing, eg.: "it is demeaning to people working
>> on the ARG" ... therefore this is aggression.
>
>This is a general, open discussion forum, not the equivalent of an
>internal forum of the ARG itself. I could understand if an internal ARG
>forum locked threads calling Ada typing nonsense, crazy, mad, stupid, etc.

The Carbon Forum has nothing to do with C++; it's a forum aimed at getting a
'community' involved in the design and development of a new language that
was, essentially, claiming to be a replacement for C++.

>> If C++ is "fully baked" and still needs Carbon, I will be damned.
>
>I haven't looked into Carbon much, but C++ is hampered by having to
>support 40 years of legacy code.

That wasn't the point; the point is, as I mentioned, that _new_ features are
being added that are not fully designed/defined/implemented; look at, for
example, the excuse for the missing operator+() on std::filesystem::path.

>Carbon doesn't have to be backwards
>compatible at the language level, as long as it can interoperate.

Exactly, and its syntax does not have to continue to follow C++'s where
doing so means inheriting syntactic features (like "="/"==") that have been
error-prone for 50+ years!

On 26/08/2022 22:40, Paul Rubin wrote:
>Olivier Henley <olivier.henley@gmail.com> writes:
>> I guess my real point was, the guy is willing to take the heat,
>> bluntly asking questions I definitely share.
>
>It was possible to make the exact same points more neutrally. Beyond
>that though, I didn't see evidence that the guy had looked at Carbon in
>any detail.

Who? Me? I had taken enough of a look to see that they appeared to be
retaining various aspects of C++ 'because that's what people are familiar
with', without accepting that some of those, at least, were flawed.

>The criticisms were purely of C++, so I would consider that
>a low-effort post.

Given the claims of Carbon being aimed at superseding C++, which is what I'd
read at the time, the points were "this flawed feature in C++ is addressed
in Ada by this...". I'm not really sure how you can aim to design a new
language without discussing or highlighting the flaws in other languages,
in this case, C++, as that was the target.

However I've now come to believe the aim of the Carbon team is to re-create
C++ but in a way that doesn't require new features and changes to go
through the standardisation hoops that C++ goes through, i.e. so they can
basically change it at will (makes me think of early Java, where
depreciation was very, very common).

>And the part about abandoning Carbon was dismissive
>toward the whole Carbon project. The Carbon github site is surely the
>wrong place for that.

I don't disagree that it was probably the wrong place to say that.

John McCabe <john@nospam.mccabe.org.uk> writes:
> However I've now come to believe the aim of the Carbon team is to re-create
> C++ but in a way that doesn't require new features and changes to go
> through the standardisation hoops that C++ goes through, i.e. so they can
> basically change it at will (makes me think of early Java, where
> depreciation was very, very common).

Have they been changing Go at will? I don't have that impression.

I do think they want to shed a lot of assumptions that were valid or
sensible at the time C++ was first designed, and also to not have their
design choices constrained by C++ legacy support.

Go is sort of a recreation of C, with garbage collection and cooperative
multitasking baked into the language. It otherwise has a fairly similar
execution model and type system. It's not a C++ replacement both
because of its GC dependence and its weaker type system.

I haven't used Rust, but from what I can understand, its type system is
Haskell-inspired and more modern than either C++'s or Ada's. Compared
with C++, it gives its user better hope of code correctness through its
use of safe defaults like immutable values and unique pointer ownership.
You can override the defaults and get similar non-safety to C++, if you
need that for some reason.

What then is Carbon? I don't know, and I'm not convinced that you do
either.

On 28/08/2022 02:32, Paul Rubin wrote:
>John McCabe <john@nospam.mccabe.org.uk> writes:
>> However I've now come to believe the aim of the Carbon team is to re-create
>> C++ but in a way that doesn't require new features and changes to go
>> through the standardisation hoops that C++ goes through, i.e. so they can
>> basically change it at will (makes me think of early Java, where
>> depreciation was very, very common).

>Have they been changing Go at will? I don't have that impression.

I have no clue, as I've never used Go, hence why I never mentioned it
anywhere.

>I do think they want to shed a lot of assumptions that were valid or
>sensible at the time C++ was first designed, and also to not have their
>design choices constrained by C++ legacy support.

Yet they're happy to adopt many of C++'s legacy syntactic/semantic issues,
e.g. assignment produces a result that can be implicitly converted to a
boolean and used in a conditional which, when considered at the same time
as the use of "=" for assignment, and "==" for comparison, has caused
numerous issues and head-scratching over the years.

>Go is sort of a recreation of C, with garbage collection and cooperative
>multitasking baked into the language. It otherwise has a fairly similar
>execution model and type system. It's not a C++ replacement both
>because of its GC dependence and its weaker type system.
>
>I haven't used Rust, but from what I can understand, its type system is
>Haskell-inspired and more modern than either C++'s or Ada's. Compared
>with C++, it gives its user better hope of code correctness through its
>use of safe defaults like immutable values and unique pointer ownership.
>You can override the defaults and get similar non-safety to C++, if you
>need that for some reason.
>
>What then is Carbon? I don't know, and I'm not convinced that you do
>either.

You are quite right; I have little clue what Carbon is, despite having read
the "What is Carbon?" FAQ at their github page.

On 28.08.22 10:57, John McCabe wrote:

> Yet they're happy to adopt many of C++'s legacy syntactic/semantic issues,
> e.g. assignment produces a result that can be implicitly converted to a
> boolean and used in a conditional which, when considered at the same time
> as the use of "=" for assignment, and "==" for comparison, has caused
> numerous issues and head-scratching over the years.

Claims about "=" and "==" without substantial statistical and economical
evidence are just not going to cut it, I think. On the contrary, they
might reflect on the speaker and his favorite language. Also, what is the
general impact of "=" when comparing effects of other features that
supposedly have caused or prevented issues, like run-time bounds checking?

Has discussing these issues ever helped choosing languages, influencing
the choice in the direction that a programming engineer would?
If not, what is a good way of discussing language design?

I think there is a story by Hofstadter about the magic that symbols
can work on young people.

I submit the common length of "==" and "!=", and some languages' choice
of "=/=", perhaps all but APL lacking "≠". The latter also officially
uses "←" for assignment, not sequences of punctuation available through
iterated pressing of single buttons on the ASCII keyboard. ;-)

Also the convenience of being able to compare two objects for
being the same object, using "===" in some languages---out of the box!

procedure same_object (A : T; B in out T) is
begin
what_do_i_put_here; -- ?
end same_object;

On 28.08.22 02:14, John McCabe wrote:

> That wasn't the point; the point is, as I mentioned, that _new_ features are
> being added that are not fully designed/defined/implemented; look at, for
> example, the excuse for the missing operator+() on std::filesystem::path.

Stepanov reminds us that "+" is commutative...
Is operator/ lacking?

"G.B." <bauhaus@notmyhomepage.invalid> writes:
> Stepanov reminds us that "+" is commutative...

String concatenation is not commutative, and std::string implements
operator+ for it.

John McCabe <john@nospam.mccabe.org.uk> writes:
> as the use of "=" for assignment, and "==" for comparison, has caused
> numerous issues and head-scratching over the years.

If that is your only concrete objection to Carbon, you could have
written a diplomatic suggestion to use := instead of = as an assignment
operator, as Go does.

> You are quite right; I have little clue what Carbon is

That acknowledgment might help you understand why your thread got closed.

Unrelated: I made an error when I wrote about Go earlier. I wrote that
it has built-in cooperative multitasking. But the multitasking is
preemptive rather than cooperative.

On Sunday, 28 August 2022 at 21:43:47 UTC+1, Paul Rubin wrote:
> John McCabe <jo...@nospam.mccabe.org.uk> writes:
> > as the use of "=" for assignment, and "==" for comparison, has caused
> > numerous issues and head-scratching over the years.
> If that is your only concrete objection to Carbon,

FFS Paul, no you is not my only concrete objection to carbon, carbon is one, brief, easy to remember one that entered my head at the time.

Le 28/08/2022 à 19:34, G.B. a écrit :
> Also the convenience of being able to compare two objects for
> being the same object, using "===" in some languages---out of the box!
>
> procedure same_object (A : T; B in out T) is
> begin
>   what_do_i_put_here; --  ?
A'Has_Same_Storage (B);
> end same_object;

Of course, this procedure should be a function...
--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52
https://www.adalog.fr

On 01.09.22 08:46, J-P. Rosen wrote:
> Le 28/08/2022 à 19:34, G.B. a écrit :
>> Also the convenience of being able to compare two objects for
>> being the same object, using "===" in some languages---out of the box!
>>
>> procedure same_object (A : T; B in out T) is
>> begin
>>    what_do_i_put_here; --  ?
>      A'Has_Same_Storage (B);
>> end same_object;
>
> Of course, this procedure should be a function...

Cool, new attributes.

Is the expectation that A and B occupy the same
bits if I pass the same X as an actual for both?

procedure Same is

type T is range 1 .. 10;

function Same_Objects (A : T; B : in out T) return Boolean is
begin
return A'Has_Same_Storage (B);
end Same_Objects;

X : T := 5 with volatile; -- Make GNAT make X an object

What : exception;
begin
if not X'Has_Same_Storage(X) then
raise What;
end if;
if not Same_Objects (X, X) then
raise Program_Error; -- does raise
end if;
end Same;

Le 02/09/2022 à 16:18, G.B. a écrit :
> On 01.09.22 08:46, J-P. Rosen wrote:
>> Le 28/08/2022 à 19:34, G.B. a écrit :
>>> Also the convenience of being able to compare two objects for
>>> being the same object, using "===" in some languages---out of the box!
>>>
>>> procedure same_object (A : T; B in out T) is
>>> begin
>>>    what_do_i_put_here; --  ?
>>       A'Has_Same_Storage (B);
>>> end same_object;
>>
>> Of course, this procedure should be a function...
>
> Cool, new attributes.
>
> Is the expectation that A and B occupy the same
> bits if I pass the same X as an actual for both?
Yes. There is also A'Overlaps_Storage (B) which is True if A and B have
at least one bit in common (notably, if B is part of A).

--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52
https://www.adalog.fr

On 2022-09-02 17:59, J-P. Rosen wrote:
> Le 02/09/2022 à 16:18, G.B. a écrit :
>> On 01.09.22 08:46, J-P. Rosen wrote:
>>> Le 28/08/2022 à 19:34, G.B. a écrit :
>>>> Also the convenience of being able to compare two objects for
>>>> being the same object, using "===" in some languages---out of the box!
>>>>
>>>> procedure same_object (A : T; B in out T) is
>>>> begin
>>>>    what_do_i_put_here; --  ?
>>>       A'Has_Same_Storage (B);
>>>> end same_object;
>>>
>>> Of course, this procedure should be a function...
>>
>> Cool, new attributes.
>>
>> Is the expectation that A and B occupy the same
>> bits if I pass the same X as an actual for both?
> Yes.

Surely only if their type (T, above) is passed by-reference?

G.B.'s post had a later example where T is "range 1 .. 10", which is a
by-copy type, so there A and B would be separate copies of X.

Le 02/09/2022 à 19:55, Niklas Holsti a écrit :
> On 2022-09-02 17:59, J-P. Rosen wrote:
>> Le 02/09/2022 à 16:18, G.B. a écrit :
>>> On 01.09.22 08:46, J-P. Rosen wrote:
>>>> Le 28/08/2022 à 19:34, G.B. a écrit :
>>>>> Also the convenience of being able to compare two objects for
>>>>> being the same object, using "===" in some languages---out of the box!
>>>>>
>>>>> procedure same_object (A : T; B in out T) is
>>>>> begin
>>>>>    what_do_i_put_here; --  ?
>>>>       A'Has_Same_Storage (B);
>>>>> end same_object;
>>>>
>>>> Of course, this procedure should be a function...
>>>
>>> Cool, new attributes.
>>>
>>> Is the expectation that A and B occupy the same
>>> bits if I pass the same X as an actual for both?
>> Yes.
>
>
> Surely only if their type (T, above) is passed by-reference?
>
> G.B.'s post had a later example where T is "range 1 .. 10", which is a
> by-copy type, so there A and B would be separate copies of X.
>
>
Sure, but in this case you are passing values, not objects, so "same
object" is irrelevant.
--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52
https://www.adalog.fr

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
news:jneucmFn478U1@mid.individual.net...
> On 2022-09-02 17:59, J-P. Rosen wrote:
>> Le 02/09/2022 � 16:18, G.B. a �crit :
>>> On 01.09.22 08:46, J-P. Rosen wrote:
>>>> Le 28/08/2022 � 19:34, G.B. a �crit :
>>>>> Also the convenience of being able to compare two objects for
>>>>> being the same object, using "===" in some languages---out of the box!
>>>>>
>>>>> procedure same_object (A : T; B in out T) is
>>>>> begin
>>>>> what_do_i_put_here; -- ?
>>>> A'Has_Same_Storage (B);
>>>>> end same_object;
>>>>
>>>> Of course, this procedure should be a function...
>>>
>>> Cool, new attributes.

Not very new, these were added in Ada 2012. They were considered inportant
for some preconditions.

>>>
>>> Is the expectation that A and B occupy the same
>>> bits if I pass the same X as an actual for both?
>> Yes.
>
>
> Surely only if their type (T, above) is passed by-reference?
>
> G.B.'s post had a later example where T is "range 1 .. 10", which is a
> by-copy type, so there A and B would be separate copies of X.

Agreed. Parameters of a by-copy type are separate objects from the actual
objects. Parameters of a by-reference type (like tagged types) are the same
objects. Parameters of types which are not specified as either may or may
not be new objects. And of course, Has_Same_Storage only if true when an
object is not copied. So the technique shown only certainly works for
by-reference types. The compiler can copy other types when it wants, so it
isn't meaningful to compare objects (only values).

Randy.