"C++ proposal dismisses backward compatibility"

[Lynn McGuire]

"C++ proposal dismisses backward compatibility"

https://www.infoworld.com/article/3535795/c-plus-plus-proposal-dismisses-backward-compatibility.html

"Proposal to the C++ standards committee would give up backward and
binary compatibility for safety and simplicity"

Lynn

[Melzzzzz]

Bad idea. C++ will be then like languages who break old code every now
and then. Not for professionals...
>
> Lynn


--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala

[Ned Latham]

Melzzzzz wrote:

> Lynn McGuire wrote:
> >
> > "C++ proposal dismisses backward compatibility"
> >
> > https://www.infoworld.com/article/3535795/
> > c-plus-plus-proposal-dismisses-backward-compatibility.html
> >
> > "Proposal to the C++ standards committee would give up backward and
> > binary compatibility for safety and simplicity"
>
> Bad idea. C++ will be then like languages who break old code every now
> and then. Not for professionals...

It's been heading that way for years.

Safety and simpolicity are both good ideas, but if they *really* head
down that path, they might as well define it strongly and give it a
new name. C3?

[alelvb]

Il 06/04/20 20:35, Ned Latham ha scritto:

> Safety and simpolicity are both good ideas, but if they *really* head
> down that path, they might as well define it strongly and give it a
> new name. C3?
>

I'd propose C³ - C cubed ; )

cheers

[Melzzzzz]

Yes. C++ is used because of it's backwards compatibility. Changing code
costs time and money...

[Ned Latham]

alelvb wrote:
> Ned Latham ha scritto:
> >
> > Safety and simpolicity are both good ideas, but if they *really* head
> > down that path, they might as well define it strongly and give it a
> > new name. C3?
>

> I'd propose Cł - C cubed ; )

Good one.

[alelvb]

Il 06/04/20 21:41, Melzzzzz ha scritto:

> On 2020-04-06, Ned Latham <nedl...@woden.valhalla.oz> wrote:
>> Melzzzzz wrote:
>>> Lynn McGuire wrote:
>>>>
>>>> "C++ proposal dismisses backward compatibility"
>>>>
>>>> https://www.infoworld.com/article/3535795/
>>>> c-plus-plus-proposal-dismisses-backward-compatibility.html
>>>>
>>>> "Proposal to the C++ standards committee would give up backward and
>>>> binary compatibility for safety and simplicity"
>>>
>>> Bad idea. C++ will be then like languages who break old code every now
>>> and then. Not for professionals...
>>
>> It's been heading that way for years.
>>
>> Safety and simpolicity are both good ideas, but if they *really* head
>> down that path, they might as well define it strongly and give it a
>> new name. C3?
>
> Yes. C++ is used because of it's backwards compatibility. Changing code
> costs time and money...
>

...and the rewriting of many tools and libraries

[Jorgen Grahn]

Most authors seem to be Google employees. I wonder how much of a
serious suggestion it is, and how much it's a provocation intended
to start a discussion on language goals.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Alf P. Steinbach]

On 06.04.2020 22:33, Jorgen Grahn wrote:
> On Mon, 2020-04-06, Lynn McGuire wrote:
>> "C++ proposal dismisses backward compatibility"
>>
>> https://www.infoworld.com/article/3535795/c-plus-plus-proposal-dismisses-backward-compatibility.html
>>
>> "Proposal to the C++ standards committee would give up backward and
>> binary compatibility for safety and simplicity"
>
> Most authors seem to be Google employees. I wonder how much of a
> serious suggestion it is, and how much it's a provocation intended
> to start a discussion on language goals.

Have you considered an April Fool's joke, like Google's previous roman
numerals proposal, or Bjarne's significant whitespace proposal?

- Alf (who hasn't looked at that)

[Keith Thompson]

No, the paper was published on March 2.

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[Chris M. Thomasson]

Well... shi%. Bust out the legacy code that worked fine, then figure out
how its ruined.

[Chris M. Thomasson]

:^D Nice.

[Öö Tiib]

The article from April 2 and the "proposal" it refers from March 2
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2137r0.html>
are both philosophical political. There are zero actual technical
facts.
Such should be dismissed as usual political brainwash since actual
changes are not proposed and so it is impossible to judge if it
is aiming for improvements or for even more deterioration of C++.

[Marcel Mueller]

Am 06.04.20 um 21:44 schrieb alelvb:

>> Yes. C++ is used because of it's backwards compatibility. Changing code
>> costs time and money...
>>
>
> ...and the rewriting of many tools and libraries

This will not happen (excluding some exceptions). No one ever pays for
no business value. And no open source programmer spends time just for
nothing.

And every new platform which did not start with a reasonable large base
of usable software is a stillbirth. Remember D (and several other
languages), Win Phone, dozens of Raspberry Pi replacements, non x86
compatible CPUs.

Successful incompatible platforms require a promoter who pays for years
for the development of the software ecosystem.

In contrast totally antiquated platforms like COBOL are still alive.
Or remember SAP (ABAP). One of their success factors is the language
compatibility. Code of the 90's still run on their platform with minimal
changes.


Marcel

[Marcel Mueller]

Am 06.04.20 um 19:41 schrieb Lynn McGuire:

This would be another new language which (almost) no one uses unless
some other one pays him for years to do so. It's like reinvention of the
wheel.

The value of a programming company (or a community project) is the code
base. Whatever breaks the compatibility decreases this value.

There are a few business cases where compatibility is not an issue or
even not wanted. But this applies only to very large companies and
near-monopoly. They can exclude competitors this way.


Marcel

[Marcel Mueller]

Am 06.04.20 um 20:13 schrieb Melzzzzz:

>> "Proposal to the C++ standards committee would give up backward and
>> binary compatibility for safety and simplicity"
>
> Bad idea. C++ will be then like languages who break old code every now
> and then. Not for professionals...

Full ack. A fork of the language will be the consequence.


Marcel

[Cholo Lennon]

I'd like to see a new C++ without backward compatibility, but I know
that this is a key feature, but at the same time a huge pain in the
neck. And we already have several examples about breaking the backward
compatibility like Python2 vs Python3. I don't want to be in the middle
of that kind of scenario. The referenced paper is very interesting BTW.

--
Cholo Lennon
Bs.As.
ARG

[David Brown]

Surely C+=2 would be the natural choice?

[David Brown]

(Disclaimer - I haven't read the link in detail.)

Given that new languages come and go all the time, a new C++ would not
be unreasonable - /if/ it is a fork with a new name and does not hinder
existing C++.

The best idea would be if it were a subset of C++.

C++ has a great deal of historical baggage that can't be dropped because
of backward compatibility, but which is not necessary. For example, you
could re-do a fair amount of the fundamental types and give a simpler
and safer language. Drop the dog's breakfast of character types and
integer types, and retain "std::byte", "char8_t", "char32_t", "intXX_t"
and "uintXX_t". Make it an error to combine signed and unsigned
integers in most expressions without an explicit conversion. Requite
8-bit std::byte. Raw pointers could be banned unless a "#pragma unsafe"
was in effect.

Code written to this new subset would still compile correctly on
standard C++ compilers.

I'm sure this would be possible - but far from easy.

[Chris Vine]

It seems to me like a great idea. It would enable those on the
standard committee and working groups who have an irresistable urge to
mess around with the language (aka "have great new ideas and features")
will have something new to play with and thus leave the actual C++
language to practising programmers. Then maybe there could be a
moratorium on all changes for, say, 10 years except to iron out plain
deficiencies or which have provably no known adverse impact on code
actually out there, unless the benefits of the change are so substantial
as to be worth the additional turbulence. Concepts may have fallen
within this latter rubric.

The fact that the standard actually mandates that some of its support
library must have undefined behaviour (I am thinking
std::uninitialized_copy here, but it seems probable there are others)
means that the standard is already so unwieldy that even the standard
committee cannot hold all of it in their heads at the same time.

The new language will be no more successful than D and almost
certainly a lot less successful than Rust. That's fine.

[Lynn McGuire]

It does kinda sound like Go.

Lynn

[jacobnavia]

I quote from the document
<quote>
Titus Winters writes in "Non-Atomic Refactoring and Software
Sustainability":

What is the difference between programming and software engineering?

These are nebulous concepts and thus there are many possible answers,
but my favorite definition is this: Software engineering is programming
integrated over time. All of the hard parts of engineering come from
dealing with time: compatibility over time, dealing with changes to
underlying infrastructure and dependencies, and working with legacy code
or data. Fundamentally, it is a different task to produce a programming
solution to a problem (that solves the current [instance] of the
problem) vs. an engineering solution (that solves current instances,
future instances that we can predict, and - through flexibility - allows
updates to solve future instances we may not be able to predict).


From this definition of "software engineering" vs. "programming" we
suggest that C++ should prioritize being more of a "software
engineering" language, and less of a "programming" language. We
specifically are interested in dealing with the time-oriented aspects of
software built in this language.

<end quote>

OK, C++ should deal with maintaining software over time. Great. But THAT
IMPLIES BACKWARDS COMPABILITY!!!

You CAN'T have stable software if the underlying language forces a
rewrite evrey year or so, even if it is a minimal rewrite.

For instance GTK and the Windows API.
I have written an IDE in C using the windows API with windows 95, i.e.
25 years ago. Most of the logic has survived UNCHANGED from windows 95
to windows 10. And that is one of the best features of that API. You
write your software and with minor changes it will go on running for
MANY years.

I ported my IDE to GTK 2, and after 6 months of work it was running.
Then, I discovered that I should rewrite it because GTK had changed all
the API in many incompatible ways.

That was the end of it. I never used GTK again.

Today, the GNOME people are changing everything each 6 months or so, as
they explicitely said. Nobody is following and you just can't write any
software for Linux GUI unless you use some propietary language where
somebody else does the job of porting a stable API to the new GTK+
version each 6 months.

Nobody will follow, nobody will rewrite their software again and again.

[Melzzzzz]

On 2020-04-08, jacobnavia <ja...@jacob.remcomp.fr> wrote:
>
> Nobody will follow, nobody will rewrite their software again and again.

+1. I programmed in Rust before 1.0, what a nightmare. Now that goes for
libraries. You don't know what is worse? If library api changes or
language changes. What a wasted time.

[Tim Rentsch]

Reading the actual proposal reminds me of a comment made about
another programming language proposal from many many years ago:
"An exercise in group wishful thinking."

[Richard]

[Please do not mail me a copy of your followup]

Lynn McGuire <lynnmc...@gmail.com> spake the secret code
<r6fpk9$7pg$1...@dont-email.me> thusly:

OK, finally had enough time to read through the cited Google paper on
refactoring and the proposal.

I don't know that I would summarize the proposal in the dire terms
cited above.

The things they are talking about jettisoning are along the likes of
trigaphs, which noone has sad to see disappear from the standard.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>