Carbon

564 views
Skip to first unread message

Gautier write-only address

unread,
Jul 22, 2022, 5:13:10 PMJul 22
to

John McCabe

unread,
Jul 23, 2022, 5:09:59 AMJul 23
to
On 22/07/2022 22:13, Gautier write-only address wrote:
>Next attempt to replace C/C++ without really replacing it: Carbon!
>
>You will notice, as usual, a few aspects borrowed from Ada - and one point inspired by Ada 83 (which was relaxed in a later Ada version) :-)
>

I read that stuff yesterday and, yet again, shook my head in disbelief :-(

The bit where I laughed was where it was claimed that C++ is building
technical debt because it's not changing quickly enough; C++ is currently a
mess because it's changing too quickly! Half-baked, and half-implemented
ideas are going into 'standards' in the full knowledge that they'll change
again in the next one. Even g++ doesn't provide 100% support for C++17
(https://gcc.gnu.org/projects/cxx-status.html#cxx17)!

Carbon is likely to be even worse; every 'new' language that promises the
earth, without being designed in a rigorous way, ends up with the same
problems. Java - I started playing with that in the 90s and got frustrated
that every update brought more and more depreciation warnings in. Python -
2.x -> 3.0 was a massive jump (and took years to gain traction) because the
'designers' just hadn't done a very good job to start with! Rust? Mmm

As for the 'reuse C++ syntax'; why the obsession with that? C++ syntax is
really bad! (Semantics, in some cases, are another level - how many
languages need a book like "C++ Gotchas"?!).

Aaaaarrrrgghhh!

Dmitry A. Kazakov

unread,
Jul 23, 2022, 9:14:18 AMJul 23
to
On 2022-07-22 23:13, Gautier write-only address wrote:
> Next attempt to replace C/C++ without really replacing it: Carbon!

We have just learned how dangerous is carbon for our climate. Yet these
few privileged keep on pumping it up! (:-))

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Stéphane Rivière

unread,
Jul 23, 2022, 9:49:08 AMJul 23
to

> We have just learned how dangerous is carbon for our climate. Yet these
> few privileged keep on pumping it up! (:-))

Carbon language bad, green language good

Jeffrey R.Carter

unread,
Jul 24, 2022, 5:09:19 AMJul 24
to
On 2022-07-22 23:13, Gautier write-only address wrote:
> Next attempt to replace C/C++ without really replacing it: Carbon!

Wouldn't this be an attempted replacement for Google's previous attempt to
replace C-family languages, Go?

--
Jeff Carter
"Blessed is just about anyone with a vested interest in the status quo."
Monty Python's Life of Brian
73

Dmitry A. Kazakov

unread,
Jul 24, 2022, 5:22:18 AMJul 24
to
On 2022-07-24 11:09, Jeffrey R.Carter wrote:
> On 2022-07-22 23:13, Gautier write-only address wrote:
>> Next attempt to replace C/C++ without really replacing it: Carbon!
>
> Wouldn't this be an attempted replacement for Google's previous attempt
> to replace C-family languages, Go?

Golang appeared too much goolang ... (:-))

Luke A. Guest

unread,
Jul 24, 2022, 5:41:00 AMJul 24
to
On 22/07/2022 22:13, Gautier write-only address wrote:
> Next attempt to replace C/C++ without really replacing it: Carbon!

Saw this last week and immediately thought they'd failed on one of their
"design goals," i.e. to be "readable.

> You will notice, as usual, a few aspects borrowed from Ada - and one point inspired by Ada 83 (which was relaxed in a later Ada version) :-)

What did they take from Ada?

John McCabe

unread,
Jul 26, 2022, 1:31:44 PMJul 26
to
Certainly not the approach to making life easier and less error-prone for developers.

I've got involved in a couple of discussions on their forum, and I'm inclined to think they just want C++ but taken out of the control of ISO/IEC WGs steering committees.

They're pretty much not considering changing any of the aspects of C++ that make it such a heap of junk (IMO, of course), including, but not limited to:

1. arrays
2. enums
3. (both of the above when used together :-))
4. symbols - overuse, duplication, inconsistency
5. implicit stuff
6. pretend strong typing
7. forcing developers to deal manually with numeric values that don't fit into an n-byte range, where n is a whole number

It really is shockingly soul-destroying watching all that. What's worse is that, from what I've seen over the years, the new languages that have been developed in a more 'relaxed' way than Ada (well, evolved, really, like Java, Python etc) and have become relatively successful have taken a good 10 years or so to get to that point, yet the discussions on the Carbon forum are all about how to appeal to _current_ developers who're used to C++; not _future_ developers who, ideally, would _never_ be used to C++!

Luke A. Guest

unread,
Jul 27, 2022, 4:12:16 AMJul 27
to

On 26/07/2022 18:31, John McCabe wrote:

> Certainly not the approach to making life easier and less error-prone for developers.

Quel surprise!

> I've got involved in a couple of discussions on their forum, and I'm inclined to think they just want C++ but taken out of the control of ISO/IEC WGs steering committees.
>
> They're pretty much not considering changing any of the aspects of C++ that make it such a heap of junk (IMO, of course), including, but not limited to:

Doesn't surprise me, they never do. Every "I've built a new language to
replace C or C++ and it's better" implement things the exact same way
every time.

> 1. arrays
> 2. enums
> 3. (both of the above when used together :-))
> 4. symbols - overuse, duplication, inconsistency
> 5. implicit stuff
> 6. pretend strong typing
> 7. forcing developers to deal manually with numeric values that don't fit into an n-byte range, where n is a whole number
>
> It really is shockingly soul-destroying watching all that. What's worse is that, from what I've seen over the years, the new languages that have been developed in a more 'relaxed' way than Ada (well, evolved, really, like Java, Python etc) and have become relatively successful have taken a good 10 years or so to get to that point, yet the discussions on the Carbon forum are all about how to appeal to _current_ developers who're used to C++; not _future_ developers who, ideally, would _never_ be used to C++!
>

It's depressing dealing with cretin's who all think they're geniuses and
think that their new idea is so radically different, but is just the
same old crap wrapped up in a functional style.

Luke A. Guest

unread,
Jul 27, 2022, 4:47:46 AMJul 27
to
On 26/07/2022 18:31, John McCabe wrote:

> 1. arrays
> 2. enums
> 3. (both of the above when used together :-))
> 4. symbols - overuse, duplication, inconsistency
> 5. implicit stuff
> 6. pretend strong typing
> 7. forcing developers to deal manually with numeric values that don't fit into an n-byte range, where n is a whole number

Oh and, no surprise to me at all...

8. They included pointers with . and ->

Patrick Georgi

unread,
Jul 27, 2022, 9:16:41 AMJul 27
to
Am 26.07.2022 um 19:31 schrieb John McCabe:
> It really is shockingly soul-destroying watching all that. What's worse is that, from what I've seen over the years, the new languages that have been developed in a more 'relaxed' way than Ada (well, evolved, really, like Java, Python etc) and have become relatively successful have taken a good 10 years or so to get to that point, yet the discussions on the Carbon forum are all about how to appeal to _current_ developers who're used to C++; not _future_ developers who, ideally, would _never_ be used to C++!

"if you can use Rust or any other established programming language, you
should" is what the Carbon developers say about their own language in
their FAQ at
https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/faq.md#if-you-can-use-rust-ignore-carbon

That language seems to have a pretty specific scope that may best be
summed up as "make C++ into the next Cobol" - that is, probably still
used in 60 years in ever more specialized niches while everybody else
moved to greener pastures a long time ago.

As such, future developers who never used C++ aren't the target audience.


Patrick

John McCabe

unread,
Jul 27, 2022, 1:24:58 PMJul 27
to
On Wed, 27 Jul 2022 09:10:10 +0100, Luke A. Guest wrote:

> On 26/07/2022 18:31, John McCabe wrote:
>
<..snip..>

>> It really is shockingly soul-destroying watching all that. What's worse
>> is that, from what I've seen over the years, the new languages that
>> have been developed in a more 'relaxed' way than Ada (well, evolved,
>> really, like Java, Python etc) and have become relatively successful
>> have taken a good 10 years or so to get to that point, yet the
>> discussions on the Carbon forum are all about how to appeal to
>> _current_ developers who're used to C++; not _future_ developers who,
>> ideally, would _never_ be used to C++!
>>
>>
> It's depressing dealing with cretin's who all think they're geniuses and
> think that their new idea is so radically different, but is just the
> same old crap wrapped up in a functional style.

LOL - yeah, tell me about it. In this thread that I mentioned (https://
github.com/carbon-language/carbon-lang/discussions/1720), I pointed out a
few things that I'm unhappy with in C++ that, in Ada, are "solved" and
have been for decades. 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.

Peter Njeim, however, gave me a bit of support and had a moan about it
which, via email, allowed me to respond. Now, I'm not one for a quick
email when I can write an epic, so my response was suitably measured and
thorough in its justification of the "half-baked" comment, and related to
a comment that was in the email from Kate Gregory who appears to have
issues understanding usage of terms within specific contexts. It took me
ages to write and, basically, the recipient was the upholders of the
"Carbon Language Code of Conduct" (in particular, the fore-mentioned Ms.
Gregory).

Now, personally, if I were in a position where I was tasked to uphold a
code of conduct whose aims were to provide a welcoming forum, and not
being nasty to people, my response to this would NOT be:

> "Please stop. Our moderators are empowered to decide if conduct is
> within our norms our not. The conduct team acts as a check to ensure
> they are correct. We have thoroughly reviewed and agree all the
> moderators involved in this are correct."

While the hypocrisy left me almost speechless, I did have to laugh :-)

Luke A. Guest

unread,
Jul 27, 2022, 4:02:51 PMJul 27
to
On 27/07/2022 18:24, John McCabe wrote:
> On Wed, 27 Jul 2022 09:10:10 +0100, Luke A. Guest wrote:
>> It's depressing dealing with cretin's who all think they're geniuses and
>> think that their new idea is so radically different, but is just the
>> same old crap wrapped up in a functional style.
>
> LOL - yeah, tell me about it. In this thread that I mentioned (https://
> github.com/carbon-language/carbon-lang/discussions/1720), I pointed out a

Jesus! "Aggressive" my arse and don't "insult C++" otherwise they may cry.

You made valid points. Points I've made before only to be ganged up on.
These "people" just aren't worth dealing with imo. I wish more company's
would dump c++, but they won't. I've even started reading, a while back
and not finished yet, a java book, *spit*, at least there's no pointer crap.

> few things that I'm unhappy with in C++ that, in Ada, are "solved" and
> have been for decades. The result is that someone who appears to have

Yup.

> very little software development experience misinterpreted the comments
> about half-baked features and locked the thread.

The only language I've seen which is a replacement for C, but is really
Pascal underneath is Odin ("Pascal in a C dress," Ginger Bill). But even
that doesn't really add much in the way of syntax sugar, it's quite
basic like Go.

> Now, personally, if I were in a position where I was tasked to uphold a
> code of conduct whose aims were to provide a welcoming forum, and not
> being nasty to people, my response to this would NOT be:
>
>> "Please stop. Our moderators are empowered to decide if conduct is
>> within our norms our not. The conduct team acts as a check to ensure
>> they are correct. We have thoroughly reviewed and agree all the
>> moderators involved in this are correct."

Exactly.

> While the hypocrisy left me almost speechless, I did have to laugh :-)

Sounds like an echo chamber where they all agree that c++ has had it's
day, but they still want c++ so are remaking it their way and their way
is the only way. Can't say I'll be using it.

Simon Wright

unread,
Jul 27, 2022, 4:39:43 PMJul 27
to
John McCabe <jo...@nospam.mccabe.org.uk> writes:

> In this thread that I mentioned (https://
> github.com/carbon-language/carbon-lang/discussions/1720), I pointed
> out a few things that I'm unhappy with in C++ that, in Ada, are
> "solved" and have been for decades.

"Avoid keyword duplication"?? e.g. multiple uses of 'with'?

John McCabe

unread,
Jul 27, 2022, 7:30:26 PMJul 27
to
Come on Simon, give me a break; you know exceptions are allowed :-)

I'm obviously referring to virtual, static, & and * (sure I mentioned
symbols somewhere too :-)

Nasser M. Abbasi

unread,
Jul 28, 2022, 7:48:58 PMJul 28
to
On 7/27/2022 3:00 PM, Luke A. Guest wrote:
> On 27/07/2022 18:24, John McCabe wrote:

>> few things that I'm unhappy with in C++ that, in Ada, are "solved" and
>> have been for decades. The result is that someone who appears to have
>
> Yup.
>

Since Ada has solved these problems long time ago, then
why are people still re-inenting the wheel? Why are they not just
using Ada? Ada is free software.

May be there is something in Ada that preventing it from being
widely adopted and used?

May be people just like { } instead of Begin, End?

I personally like begin/end much more that { } as it is more
clear.

Or may be there is something else going on.

--Nasser

Devin Rozsas

unread,
Jul 29, 2022, 12:34:05 AMJul 29
to
> May be there is something in Ada that preventing it from being
> widely adopted and used?

Probably the fact that there's only one decent free and open-source implementation of Ada 2012 (GNAT)?

John McCabe

unread,
Jul 29, 2022, 7:03:39 AMJul 29
to
On Thu, 28 Jul 2022 18:48:49 -0500, Nasser M. Abbasi wrote:

> On 7/27/2022 3:00 PM, Luke A. Guest wrote:
>> On 27/07/2022 18:24, John McCabe wrote:
>
>>> few things that I'm unhappy with in C++ that, in Ada, are "solved" and
>>> have been for decades. The result is that someone who appears to have
>>
>> Yup.
>>
>>
> Since Ada has solved these problems long time ago, then why are people
> still re-inenting the wheel? Why are they not just using Ada? Ada is
> free software.

Possibly for the same reason that I was so anti-Ada in my early years; it
takes getting used to and people are lazy.

Looking at some of the languages that have come out in recent years, it's
obvious that people can't be bothered to type much; "fn"/"def" (or, even,
nothing!) instead of "function"/"procedure", "{"/"}" instead of
"begin"/"end", "&&" instead of "and", "||" instead of "or" (!!!) etc.

From what I can see, some of the "moderators" on that Carbon group don't
have much real professional software development experience, so I suspect
they really have no clue about what they could achieve with Ada, and have
little understanding of some of the contraints that embedded, especially
bare-metal, systems impose on what you can and can't include in a
program. I'm thinking here of things like heap-unfriendly container
classes, such as (in Swift) arrays that are automatically expandable when
you append a new item, rather than being fixed size etc.

There also seems to be a bit of an obsession with the time between "empty
editor window" and "executable available", rather than "empty editor
window" and "executable that actually does what you want"!

Also, as Devin says, compiler availability is an issue, from the point of
view of actually _using_ Ada.

However, from the point of view of creating a new language, the fact that
so many people clearly think it _has_ to be the C/C++ way is quite
disturbing, especially since, as I think I mentioned, it's going to be a
number of years until any new language really makes its mark, so new
languages should be taking future developers into account, not just
pandering to the laziness of existing ones!

At this point I think I should make it clear that, although I think Ada
has some great features (and I regularly espouse them amongst my
colleagues), I don't use Ada in the software I'm developing. I'd like to,
but it would take me a lot of time to get back to a level in Ada where
I'd be comfortable creating a relatively substantial codebase from
scratch. The alternative would be to go and join a team that's already
using Ada, but every Ada job I've seen come up locally is to support code
that was written in Ada 95; I'd rather be looking at Ada 2005 -> if I was
to make that jump.

Gautier write-only address

unread,
Jul 29, 2022, 2:59:23 PMJul 29
to
Le vendredi 29 juillet 2022 à 01:48:58 UTC+2, Nasser M. Abbasi a écrit :

> May be people just like { } instead of Begin, End?

It's a misconception: the "begin" keyword in Ada appears only at the beginning of a body, or for a block statement.
You are confusing with Pascal where the "begin .. end" pair is the equivalent of C's {}'s.
And yes, this aspect of Pascal's syntax is cumbersome, especially with the "if" and "case" statements:
"if x then begin s; t end else begin u; v end".
Spread on several lines and indented, it makes overly long and verbose statements.
Nevertheless it didn't prevent Pascal to be very popular at some periods in time.

> Or may be there is something else going on.

The main issue is: out of the dozens of languages around, how can someone guess that language X has solved Y's issues?
It is especially difficult in companies, where people who make language choices often don't program themselves.

IMHO the only way to make Ada more popular is to create popular applications with it.

Gautier write-only address

unread,
Jul 29, 2022, 3:05:04 PMJul 29
to
Le vendredi 29 juillet 2022 à 13:03:39 UTC+2, John McCabe a écrit :

> The alternative would be to go and join a team that's already
> using Ada, but every Ada job I've seen come up locally is to support code
> that was written in Ada 95; I'd rather be looking at Ada 2005 -> if I was
> to make that jump.

It should not be a problem, since each version of Ada is compatible with the previous one.
You can bring in whatever new feature is supported, especially in new packages or projects.
It's only a problem if your boss requires to stick with Ada 95.

Paul Rubin

unread,
Jul 29, 2022, 9:40:19 PMJul 29
to
"Nasser M. Abbasi" <n...@12000.org> writes:
> Or may be there is something else going on.

It seems to me that it simply takes a lot more code (not just
keystrokes) to do anything in Ada, compared to other languages. Having
two files (ADS and ADB) for every module is already a nuisance.

I think there is also a very big gap between beginner-level Ada and
production-level Ada, and it's not very obvious how to bridge the gap.
C++ has tons of online docs and you can learn what you need to
gradually. Plus it is easier to navigate C++'s library ecosystem.
Alire(sp?) may help with that for Ada. I haven't used it yet.

Nasser M. Abbasi

unread,
Jul 30, 2022, 12:23:21 AMJul 30
to
On 7/29/2022 8:40 PM, Paul Rubin wrote:
> "Nasser M. Abbasi" <n...@12000.org> writes:
>> Or may be there is something else going on.
>
> It seems to me that it simply takes a lot more code (not just
> keystrokes) to do anything in Ada, compared to other languages. Having
> two files (ADS and ADB) for every module is already a nuisance.
>

Isn't this similar in a way to C/C++ with their header files all
over the place? Also in modern Fortran, each module Fortran .f file will
have an associated .mod file generated that goes with it (used by
other modules to interface to it).

I think having the implementation in one file and the interface in
separate file is good.

Otherwise, if they are both in same physical file and one changes
say the implementation only, causing the time stamp on the file to
change, then hard to know later if one changed the implementation part
or the interface part in the file by looking at timestamps of
files that changed (make will not know also, so it thinks both changed).

Also having separate file for interface and implementation,
allows others to program against the interface file, while someone at same
time changing the implementation file without each getting in each others way.

> I think there is also a very big gap between beginner-level Ada and
> production-level Ada, and it's not very obvious how to bridge the gap.
> C++ has tons of online docs and you can learn what you need to
> gradually. Plus it is easier to navigate C++'s library ecosystem.
> Alire(sp?) may help with that for Ada. I haven't used it yet.

--Nasser

Nasser M. Abbasi

unread,
Jul 30, 2022, 12:26:35 AMJul 30
to
On 7/29/2022 1:59 PM, Gautier write-only address wrote:

> IMHO the only way to make Ada more popular is to create popular applications with it.

Agree.

But this is big catch 22.

There are no popular apps written in Ada because not too many
programmers use it, and there are not many programmers who use it
because there are no popoluar apps written in it.

--Nasser

G.B.

unread,
Jul 30, 2022, 4:11:50 AMJul 30
to
On 29.07.22 13:03, John McCabe wrote:

> Looking at some of the languages that have come out in recent years, it's
> obvious that people can't be bothered to type much; "fn"/"def" (or, even,
> nothing!) instead of "function"/"procedure", "{"/"}" instead of
> "begin"/"end", "&&" instead of "and", "||" instead of "or" (!!!) etc.

Continued emphasis of syntax differences and then not paying proper
respect to what is empirically attractive to so many prospects
will miss an important point. Not about flies. About customers.
Without customers, there will be no products.

Such as,
> From what I can see, some of the "moderators" on that Carbon group don't
> have much real (...)

What moderators seem to have, though, is quite real. It is a task,
they are heading a group and they need to process input from an Adaist
in this many faceted situation, and consider the implications.
Also the implications of their response.

> I suspect
> they really have no clue about what they could achieve with Ada,

Why would Alphabet Inc. want to achieve an entirely different goal,
viz. use Ada? Maybe reuse Ada.
Given the many years and the many $ it has taken to produce Ada
and Ada products, this fact surely has meant business at some point.
Why would anyone not learn from that past opportunity and start
a language from scratch?

To become an asset in this productive process, by way of expressing
a positive attitude and offering economically useful contributions
might be a way of influencing the programming language.

> However, from the point of view of creating a new language, the fact that
> so many people clearly think it _has_ to be the C/C++ way is quite
> disturbing, especially since, as I think I mentioned, it's going to be a
> number of years until any new language really makes its mark, so new
> languages should be taking future developers into account, not just
> pandering to the laziness of existing ones!

If your job is to help create return on investment, such as investment into
a programming language, then how is it economical to not pander to the
expectations of potential customers? Customers who might otherwise
want to use Rust, say?

(Does someone know a way of making entrepreneurs not just aware of how
each of them is milked by software industry giants, but also a way out
for each of them individually?)

Scala, by way of illustration, now has almost all language features
that Oracle Inc. will be adding to Java in the coming years,
as I'm sure they know. Scala isn't associated with the same marketing
skills, though.

Scala might also be using syntax that is considered boring and
dated, using many keywords, but I'm not entirely sure, in particular
after they changed it for version 3...

John McCabe

unread,
Jul 30, 2022, 5:16:35 AMJul 30
to
It's the latter; it mostly appears to be jobs that have a contractual need
to use the same compiler that was used to develop the original code 20
years ago, as it's known, certified etc.

John McCabe

unread,
Jul 30, 2022, 5:21:30 AMJul 30
to
On 29/07/2022 19:59, Gautier write-only address wrote:

<.. Snip.. >

>The main issue is: out of the dozens of languages around, how can someone
>guess that language X has solved Y's issues?

Well, AIUI, that _was_ the point of my intervention in the Carbon
discussions, but it appears that, as it didn't fit their narrative, it
wasn't welcomed.

dennis knorr

unread,
Aug 6, 2022, 10:18:17 AMAug 6
to
Am 29.07.22 um 01:48 schrieb Nasser M. Abbasi:

> May be there is something in Ada that preventing it from being
> widely adopted and used?

An opinion from bystander who wants to like Ada, this is only after i
looked the resources and the community up a bit two years ago again. you
do not have to agree, it's just my experience and sometimes gut feeling.

* Bad to no marketing
* sometimes elitism by members of the community/Ada fans
* no modern feeling toolchain (Even Lazarus+Pascal or Gambas has a more
modern feeling toolchain, and that says alot)
* not much free software built with it
* not much free software for the toolchain available
* not much libraries which are ready and easy to use as a beginner
* no modern/up2date books and articles (especially in other languages
than in english) seem to be available.
* the free Ada Compiler seems slow and a while back it generates
relatively big binaries and the result was not very fast.

Just a few concrete examples to back that up:
* Is there a web playground or repl shell trying or learning/trying Ada
or some of its prominent modules?
* There's no modern book in german about modern Ada and its libraries
* There's no syntaxhighlighting package in vim for ada
* No exercises like for example Ruby Koans
* It *Looks* like there are no libraries which make it easy use Ada for
programming (think json/document formats, http/mail/mime protocols,
algorithms or cryptography libraries)


I know there are libraries out there, but they are hard to find, not
promoted/marketed and i saw developers (also in other languages, i admit
that) talking like, if you do not understand it, you should go back to
toylanguages like python.

i also know that not all bulletpoints above are really true to the
fullest, but most of them from the outside look like it and also have at
least some grain of truth in there.

If someone would write a book in german, how to write Ada and use
$cryptolibrary, $networklibrary and how to integrate it in ones favorite
development software, this surely would be very interesting too many.

The ONLY thing where i see Ada Marketing in the free software world is
FOSDEM. But it is in its own Room. Ada people would need to go out and
say: hey, look we also can do good stuff, look, an https server with
letsencrypt support with library in 30 lines..

To be honest, i am curious how the community here will react on it. I
mean, i got the Book "Programming in Ada 2005" as a present and i liked
it, but after reading the introduction (first 2-3 chapters i think) back
then (was like over 15 years ago) i saw no libraries which i can use.
and i was not that big a programmer to write them myself.

Jm2c,
Dennis

A.J.

unread,
Aug 6, 2022, 1:48:02 PMAug 6
to
On Saturday, August 6, 2022 at 10:18:17 AM UTC-4, dennis knorr wrote:
<.. snip ..>
I agree with you on some of these points. Ada never seemed to be big on marketing, at least outside of specific niches, and from a learning & resources aspect, it took me reading Barnes' Programming in Ada 2012 cover-to-cover to properly grok the language. With that being said, things have been changing a lot in the last two years.

https://learn.adacore.com is a decent resource in that it gives you little ada interpreter with code snippets you can test out yourself right in the browser. It's not exactly a "web playground or repl shell" but it's pretty good and seems to support the standard library.

From a library and tooling standpoint, I would check out Alire. It takes a matter of minutes to get from not having any ada compilers installed at all to compiling your own hello example and there's a lot of libraries already supported ( https://alire.ada.dev/crates.html ). To bring, for example, Gnatcoll_sqlite, into your project, you would simply just type "alr with gnatcoll_sqlite" while in that directory.

Here's a quick start that I wrote up for my friends:
----
1: Download alire for your OS (e.g. on Windows it's "alr-*-installer-x86_64-windows.exe"): https://github.com/alire-project/alire/releases
2: After installing, run the "Alire" program
3: Once you're in the Alire command prompt, type alr and then hit "enter", and it'll install everything you need (e.g. on Windows, it'll install msys2)
4: To grab an example project that you can install and run, type "alr get hello", and it'll automatically fetch the "hello world" package.
5: Go to that newly added project's folder with command "cd hello" and enter.
6: Build and run the project by typing "alr run"
7: Alire will automatically download and install the ada compiler and everything. You'll get a prompt asking what toolchains to use, just hit the enter key twice to select the defaults.
To create anything new in Alire, just type "alr init --bin myproj" and it'll create a new project that you can start programming in a project named "myproj". (if it asks for your github info, you can just leave it blank).
More info here https://alire.ada.dev/docs/#first-steps
----

Then of course there's the awesome-ada repository that has some nice resources, albeit they seem to mostly be in English: https://github.com/ohenley/awesome-ada

G.B.

unread,
Aug 7, 2022, 5:08:46 AMAug 7
to
On 06.08.22 16:18, dennis knorr wrote:

> * There's no modern book in german about modern Ada and its libraries

What's the competition, considering C#, Swift, Java or C?
I.e., an original work written by a German author, bought
and studied by many?
There used to be a number of books on Ada written in German when
the market had developed ideas of a government mandate, the ideas
producing corresponding opportunities.


> * There's no syntaxhighlighting package in vim for ada

:syntax enable

(Does vim feature in a modern feeling tool chain, though?)

> * No exercises like for example Ruby Koans
> * It *Looks* like there are no libraries which make it easy use Ada for
> programming (think json/document formats, http/mail/mime protocols,

AWS, GNATColl, $ alr with json.

> algorithms or cryptography libraries)

Just use one that you can trust. If you need it to be more Ada-ish,
ChaCha20 cipher and Poly1305 digest have just been mentioned a few
postings ago. If algorithms can address securing the entire computation...

There used to be the PAL, which is the Public Ada Library, easy to find.
A bit dated, and reflecting the hype back then, I guess.

I gather that, currently, and in the past, Ada tools are also focusing
on topics of embedded computers, a fairly large and attractive market.
JSON or MIME, perhaps even interpreters are present, but I think not
central to control stuff near sensors and actuators. How does one compute
deterministic responses before deadline using Node.js?


> If someone would write a book in german, how to write Ada and use
> $cryptolibrary, $networklibrary and how to integrate it in ones favorite
> development software, this surely would be very interesting too many.

Can you say how many? I imagine a publisher asking this question.


dennis knorr

unread,
Aug 8, 2022, 5:39:03 PMAug 8
to
Am 07.08.22 um 11:08 schrieb G.B.:
> On 06.08.22 16:18, dennis knorr wrote:
>
>> * There's no modern book in german about modern Ada and its libraries
>
> What's the competition, considering C#, Swift, Java or C?

from the absolute amount in english, these languages or python or rust
have more books. hell, even Raku has more books.

Python, Kotlin(!), C# have more german books and also more current ones.
I bet in five years from now there will be more german books about
Carbon than about ada, even if you include the old ones.

> I.e., an original work written by a German author, bought
> and studied by many?

and which is preferrably younger than 20 years.

> There used to be a number of books on Ada written in German when
> the market had developed ideas of a government mandate, the ideas
> producing corresponding opportunities.

Well, or people with knowledge could write books if they want to
distribute knowledge :)

>> * There's no syntaxhighlighting package in vim for ada
>
> :syntax enable

okay, that i did not know.

> (Does vim feature in a modern feeling tool chain, though?)

Well, okay, intellij is called more modern of course or VSCode, but you
still can craft modern tooling onto vim and it works well.

>> * No exercises like for example Ruby Koans
>> * It *Looks* like there are no libraries which make it easy use Ada for
>> programming (think json/document formats, http/mail/mime protocols,
>
> AWS, GNATColl, $ alr with json.

Well, yes. If you know them. Is there beginner documentation? and as i
said below my judgement is not entirely true, but for newbies to the
language it's not really visible.

>> algorithms or cryptography libraries)
>
> Just use one that you can trust. If you need it to be more Ada-ish,
> ChaCha20 cipher and Poly1305 digest have just been mentioned a few
> postings ago. If algorithms can address securing the entire computation...

The deeper you dig with crypto the more problems you have. For example,
with TLS terminations, Chacha/salsa/Poly does not help you. Or you want
to interact with other data structures which implement AES with GCM or
you need cryptoprotocol elements for a KeyExchange, even without
implementing TLS?

Well, of course, i can use some C++ library, but first, debugging stuff
like that never worked well over language boundaries and i can "just use
C++" if i already use them.

> There used to be the PAL, which is the Public Ada Library, easy to find.
> A bit dated, and reflecting the hype back then, I guess.
>
> I gather that, currently, and in the past, Ada tools are also focusing
> on topics of embedded computers, a fairly large and attractive market.
> JSON or MIME, perhaps even interpreters are present, but I think not
> central to control stuff near sensors and actuators. How does one compute
> deterministic responses before deadline using Node.js?

JSON or MIME are Dataformats. And it's not necessary throwing around
thinly veiled insults at other software ecosystems. He asked why Ada is
not more used or popular, i gave pointers, why people do not go to Ada,
but perhaps to Rust.

>> If someone would write a book in german, how to write Ada and use
>> $cryptolibrary, $networklibrary and how to integrate it in ones favorite
>> development software, this surely would be very interesting too many.
>
> Can you say how many? I imagine a publisher asking this question.

That's a question most people who wrote books in the
$programming-language-books-section could not answer beforehand i guess.
and i mean, what is this question? Neither does it deconstruct my
argument, nor does it strengthen yours (if you have any). It sounds more
like the elitist perl programmers, who sneered at python because of the
REPL shell, that "a real language does not have or need a repl shell".
That was actually an opinion i read on IRC 6 years ago..

You do not have to like my opinion/experience/viewpoint but i really
would like to communicate that this exactly the reply i feared. not
because of the potential personal attack (which was not here), but
because of the elitist complacency. With attitudes like this, Ada will
only continue withering in the future.

No offense, jm2c and kind regards,
Dennis

Dmitry A. Kazakov

unread,
Aug 8, 2022, 6:28:49 PMAug 8
to
On 2022-08-08 23:38, dennis knorr wrote:
> Am 07.08.22 um 11:08 schrieb G.B.:

>> Just use one that you can trust. If you need it to be more Ada-ish,
>> ChaCha20 cipher and Poly1305 digest have just been mentioned a few
>> postings ago. If algorithms can address securing the entire computation...
>
> The deeper you dig with crypto the more problems you have. For example,
> with TLS terminations, Chacha/salsa/Poly does not help you. Or you want
> to interact with other data structures which implement AES with GCM or
> you need cryptoprotocol elements for a KeyExchange, even without
> implementing TLS?

ChaCha20 is good in first place to avoid TLS. My motivation to implement
ChaCha20 was for deterministic low latency zero traffic overhead secure
network protocols.

If you want TLS, there are Ada bindings to both GNUTLS and OpenSSL.

I would not say that either GNUTLS or OpenSSL were well documented, but,
hey, they are written in C, curly brackets, #ifdefs and void* magically
explain everything for everybody! (:-))

>> I gather that, currently, and in the past, Ada tools are also focusing
>> on topics of embedded computers, a fairly large and attractive market.
>> JSON or MIME, perhaps even interpreters are present, but I think not
>> central to control stuff near sensors and actuators.

Actually the situation is so bad that not just JSON, even HTTP is
actively used in embedded systems for data exchange today. The plague
spreads fast...

>> How does one compute
>> deterministic responses before deadline using Node.js?

By deploying agile determined programmers... (:-))

> but
> because of the elitist complacency. With attitudes like this, Ada will
> only continue withering in the future.

No idea why you consider argumentation to technical issues elitist or
insulting.

There is no way to use Ada without actually using it. Differently to 25
or so years ago, today the entry barrier is basically zero. There is a
free Ada compiler for every possible platform one can imagine for taking
a start. There are lots of Ada libraries.

If you need something concrete, just ask here, somebody will always answer.

P.S. Nobody writes Ada books these days because they do not sell. If you
want a book on some interesting, in your opinion, Ada topic, start a
project on a fundraising site. If it manages to collect 100K, I am sure
some of renown Ada writers will come to collect...

Randy Brukardt

unread,
Aug 9, 2022, 12:12:48 AMAug 9
to
"Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> wrote in message
news:tcs2mr$1o0u$1...@gioia.aioe.org...
...
> P.S. Nobody writes Ada books these days because they do not sell.

Do *any* programming books really sell? If so, why? :-)

There are plenty of free, on-line resources for pretty much any programming
language. Why pay for something you can get free?

When someone starts talking about books, I think they're a troll. I can
understand complaints about having trouble finding stuff (although Google
should find AdaIC.org pretty easily, it usually pretty high in Ada results,
and most of the good stuff is linked from there), and lack of hype, and so
on. But there's lots of good stuff if one looks (or asks here - if someone
knows about here they're ready to use Ada).

AdaIC has an Ada-specific search engine which hopefully makes it easier to
find Ada stuff than a general engine like Google.

Randy.


Paul Rubin

unread,
Aug 9, 2022, 2:05:14 AMAug 9
to
"Randy Brukardt" <ra...@rrsoftware.com> writes:
> When someone starts talking about books, I think they're a troll.

I don't know of any online Ada docs that I'd call helpful past the
beginner level (Ada Distilled). Someone here recommended a book to me a
year or two ago and I bought a copy. It looks good but has just been
sitting around waiting for me to read it. I haven't done that because I
haven't had any occasion to mess with Ada, and have too many other
pending projects. One of these days.

John McCabe

unread,
Aug 9, 2022, 3:22:15 AMAug 9
to
On 09/08/2022 05:12, Randy Brukardt wrote:
>"Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> wrote in message
>news:tcs2mr$1o0u$1...@gioia.aioe.org...
>...
>> P.S. Nobody writes Ada books these days because they do not sell.
>
>Do *any* programming books really sell? If so, why? :-)
>
>There are plenty of free, on-line resources for pretty much any programming
>language. Why pay for something you can get free?

FWIW, I may be 'old school', but I buy loads of programming books. That
obviously doesn't qualify me to answer the question of whether "*any*
programming books really sell", but the main reasons I like books are that
they tend to be more constrained and cohesive than jumping around websites
(at least, the decent ones are :-)). Also for those times when I want to
flick back and forth between sections quickly, when I don't want to be
staring at a screen and so on. One particular reason is that, unless I've
actually got a block of free time to be experimenting with stuff, using a
Web browser presents multiple, frustrating distractions, and it's often the
case that an example of something you might want to do has no explanation
about how it works (books, especially Ada As A Second Language, if I
remember correctly, are generally fairly good at that bit), so that leads
to more searching, more jumping about webpages and, nowadays, a helluva lot
of stale and misleading information.

So, basically, that's why I pay for books.


--
Best Regards

John Perry

unread,
Aug 9, 2022, 9:19:48 PMAug 9
to
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.

Paul Rubin

unread,
Aug 10, 2022, 2:20:45 AMAug 10
to
> 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.

Analysable Real-Time Systems: Programmed in Ada by Prof. Alan Burns is
from 2016 and looks pretty good. It is the book I mentioned that I got
on the recommendation of someone here. I've flipped through it but
still haven't read it.

Luke A. Guest

unread,
Aug 10, 2022, 4:26:44 AMAug 10
to
The only Ada95 DS book I know of is the one I have by Mark Weiss.

John Perry

unread,
Aug 10, 2022, 1:58:28 PMAug 10
to
On Wednesday, August 10, 2022 at 1:20:45 AM UTC-5, Paul Rubin wrote:
> Analysable Real-Time Systems: Programmed in Ada by Prof. Alan Burns is
> from 2016 and looks pretty good. It is the book I mentioned that I got
> on the recommendation of someone here. I've flipped through it but
> still haven't read it.

I hadn't seen that one; thanks!

John Perry

unread,
Aug 10, 2022, 1:59:32 PMAug 10
to
On Wednesday, August 10, 2022 at 3:26:44 AM UTC-5, Luke A. Guest wrote:
> The only Ada95 DS book I know of is the one I have by Mark Weiss.

The one is have is by Feldman.

Randy Brukardt

unread,
Aug 17, 2022, 9:02:57 PMAug 17
to
"John Perry" <dev...@yahoo.com> wrote in message
news:7acda3cc-3b98-4bed...@googlegroups.com...
> On Wednesday, August 10, 2022 at 3:26:44 AM UTC-5, Luke A. Guest wrote:
>> The only Ada95 DS book I know of is the one I have by Mark Weiss.
>
> The one is have is by Feldman.

The Ada 2012 book by Peter Chapin looks promising, although I don't think
he's finished it (https://github.com/pchapin/tutorialada). There is a PDF
version of it available on-line.

Otherwise, I recommend Ada Distilled
(https://www.adaic.org/wp-content/uploads/2010/05/Ada-Distilled-24-January-2011-Ada-2005-Version.pdf)
[Ada 2005], and the Craft of Object Oriented Programming
(http://archive.adaic.com/docs/craft/craft.html) [Ada 95], depending on the
programmer's level. These are all written in the text book style, and are
all available for free on the Internet. I don't think you miss too much
learning with an Ada 95 book first (most of the newer stuff is fairly
obvious, or needs a text book of it's own.

The Wikibook is also a good choice
(http://en.wikibooks.org/wiki/Ada_Programming), but you do have to be
on-line to use it (the others are downloadable and thus usable locally).

I find the Barnes book to be too much of a good thing (sorry, John!). When
John gave me a copy at a Paris ARG meeting, I put it on my lap to look
through it (since my hotel room was tiny), my legs got numb after not very
long. I know better than to put it on a body part again. :-) I'd recommend
it as a reference for serious Ada programmers, since it tries to cover
everything (the latest version has an Ada 2022 appendix).

Randy.




Fabien Chouteau

unread,
Aug 25, 2022, 5:14:02 AMAug 25
to
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 don't know if the people working on Carbon had a bad opinion about Ada before, but sure do now.
In the end I think that you did a lot of damage to Ada, its reputation and its community...

John Perry

unread,
Aug 25, 2022, 1:55:31 PMAug 25
to
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?

> I don't know if the people working on Carbon had a bad opinion about Ada before, but sure do now.
> In the end I think that you did a lot of damage to Ada, its reputation and its community...

Do language designers really draw conclusions about the quality of other languages, or even about the user community of other languages, from a handful of posts by one zealous member?

Olivier Henley

unread,
Aug 26, 2022, 2:59:26 PMAug 26
to
On Thursday, August 25, 2022 at 1:55:31 PM UTC-4, John Perry wrote:
> Assertive and strongly-worded? sure, but aggressive?

In my humble opinion:

This is not aggression. We need to stop relativizing definitions.
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.

> Do language designers really draw conclusions about the quality of other languages, or even about the user community of other languages, from a handful of posts by one zealous member?
Not if they are rational people. A member, a couple of members do not make a community; basic set theory.

If Ada is not a direct contender to C++ since 1983, I will be damned.
If there is no intentional wordplay between "Rust" and "Carbon", I will be damned.
If C++ is "fully baked" and still needs Carbon, I will be damned.
If someone cannot point an elephant in the room anymore, I will be damned.

Can we live and let live, please? (I would definitely be happier in New Hampshire...)

Paul Rubin

unread,
Aug 26, 2022, 4:23:49 PMAug 26
to
Olivier Henley <olivier...@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...") 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"). It also treated some debateable
points as self-evident, such as that enumeration types should always
support 'Image.

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.

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

I didn't read the later posts that were flagged as off-topic, since you
have to be logged in to view them. It was only after several of them
that the thread was locked.

> 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.

> If Ada is not a direct contender to C++ since 1983, I will be damned.

Idk what you mean by that. Ada and C++ don't aim to do the same things
afaict. C++ is certainly used for some things where Ada would be
better, like anything involving safety. It's also used heavily in
e.g. game development, where bugs and crashes won't kill anyone, so
Ada's safety guarantees are less valuable than they are in
e.g. avionics.

> If there is no intentional wordplay between "Rust" and "Carbon", I
> will be damned.

Maybe you are right about that, but it hadn't occurred to me. Rust is
iron oxide and carbon is a different element. I liked the wordplay when
someone called a Rust tool "thermite", which is a mixture of iron oxide
and aluminum powder. There, the connection is more obvious.

> 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. Carbon doesn't have to be backwards
compatible at the language level, as long as it can interoperate.

Programming C++ by staying in a modern subset fixes some of its issues,
though not all:

https://isocpp.org/blog/2015/09/bjarne-stroustrup-announces-cpp-core-guidelines

Olivier Henley

unread,
Aug 26, 2022, 4:59:17 PMAug 26
to
On Friday, August 26, 2022 at 4:23:49 PM UTC-4, Paul Rubin wrote:
> Olivier Henley writes:
> > This is not aggression. We need to stop relativizing definitions.
> I would call the first post somewhat aggressive, though not intensely
> so. (...) The second post came across to me as even more aggressive ("Can you
> please specify...").

Sir respectfully, in my opinion, aggression is not :
me_kid: "mom ... someone aggressed me at school today."
mom: "what, he showed you a finger, he told you names, what.!?"
me_kid: "no, he asked me to specify... in writings"

> > 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.

Make sense. I never thought of a Github discussion as something "that" official, but sure I stand corrected.

> > If there is no intentional wordplay between "Rust" and "Carbon", I
> > will be damned.
> Maybe you are right about that, but it hadn't occurred to me. Rust is
> iron oxide and carbon is a different element.

"Because steel is a mixture of iron and carbon, it will definitely rust."
(https://www.apx-enclosures.com/apx-blog/metals-that-dont-rust#:~:text=Because%20steel%20is%20a%20mixture,more%20chromium%20content%2C%20the%20better.)

I guess my real point was, the guy is willing to take the heat, bluntly asking questions I definitely share.
At this point, who am I to judge some internet tough-love?

Paul Rubin

unread,
Aug 26, 2022, 5:40:15 PMAug 26
to
Olivier Henley <olivier...@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. The criticisms were purely of C++, so I would consider that
a low-effort post. And the part about abandoning Carbon was dismissive
toward the whole Carbon project. The Carbon github site is surely the
wrong place for that.

Olivier Henley

unread,
Aug 26, 2022, 6:19:00 PMAug 26
to
Agree.

Nevertheless, I also understand the upset about the dismissal of the cultural programming landscape, of what happened since 1983.
Sometimes, on that subject, telling people they should know better is really hard to resist.

Do not get me wrong, I know it is not a fertile way, but I will not throw rocks at the guy who decided to spin a round either.
I sincerely do not believe in such a fragile society.



Jeffrey R.Carter

unread,
Aug 26, 2022, 7:21:28 PMAug 26
to
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 ...

--
Jeff Carter
“A key difference between Ada and most other
software development languages is that Ada is
deigned as an engineering tool as well as a
programming tool.”
Ada Distilled
209

Paul Rubin

unread,
Aug 26, 2022, 8:06:04 PMAug 26
to
Olivier Henley <olivier...@gmail.com> writes:
> Sometimes, on that subject, telling people they should know better is
> really hard to resist.

It would be reasonable to spend a while examining the Carbon spec,
identify any issues, and post technical criticism and suggestions.

I myself don't understand what Carbon is supposed to accomplish that
Rust doesn't, or alternatively, if Carbon is supposed to be "Golang++"
or what. Rust it seems to me is more modern than C++ or Ada 2012.
There are some proposals to adapt some of Rust's ideas into Ada 202x.
But that stuff confuses some people. It could be that Carbon is a step
backwards.

John McCabe

unread,
Aug 27, 2022, 5:49:48 AMAug 27
to
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

Rod Kay

unread,
Aug 27, 2022, 7:27:35 AMAug 27
to
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 ? ... :)

John Perry

unread,
Aug 27, 2022, 11:20:09 AMAug 27
to
+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!"

John McCabe

unread,
Aug 27, 2022, 7:39:52 PMAug 27
to
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.

-

John McCabe

unread,
Aug 27, 2022, 7:47:26 PMAug 27
to
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.

John McCabe

unread,
Aug 27, 2022, 8:14:46 PMAug 27
to
On 26/08/2022 21:23, Paul Rubin wrote:
>Olivier Henley <olivier...@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!

John McCabe

unread,
Aug 27, 2022, 8:30:08 PMAug 27
to
On 26/08/2022 22:40, Paul Rubin wrote:
>Olivier Henley <olivier...@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.

Paul Rubin

unread,
Aug 27, 2022, 9:32:29 PMAug 27
to
John McCabe <jo...@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.

John McCabe

unread,
Aug 28, 2022, 4:57:18 AMAug 28
to
On 28/08/2022 02:32, Paul Rubin wrote:
>John McCabe <jo...@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.

G.B.

unread,
Aug 28, 2022, 1:34:37 PMAug 28
to
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;

G.B.

unread,
Aug 28, 2022, 1:39:08 PMAug 28
to
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?

Paul Rubin

unread,
Aug 28, 2022, 2:24:20 PMAug 28
to
"G.B." <bau...@notmyhomepage.invalid> writes:
> Stepanov reminds us that "+" is commutative...

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