Hacker News Reader

Comment by mdp2021 | Hacker News Reader

mdp2021

Sorry, I have only a sketchy idea of Zig: I understood it should have been a competitor? Why does the article writer in fact disregard it?

The authors of Val state:

> Our goals overlap substantially with that of Rust and other commendable efforts, such as Zig or Vale

View on HN

Zig is usually seen as a 'better C', not as a 'better C++'. Whether this is actually the case is debatable though (some of Zig's features are 'leaking' into the territory of higher level languages such as C++ or Rust).

I feel this viewpoint is pedantic. Zero cost abstractions is the space we're looking at and from this perspective, C and C++ are in the same space.

If not then are we implying a successor to C++ needs to be Object Oriented? Because that's the main difference between C++ and C. Clearly the successor languages mentioned in the article do not have the same heavy OOP bias embedded into themselves as C++ and thus they all can be looked upon as successors to C as well.

I think the goal here is just to find a language that does the whole "zero cost abstraction" thing better than the status quo.

There are so many more differences between C and C++. Templates, RAII, type inference, lambdas, etc. These are the abstractions that try to be zero cost; C has little abstraction overall so it doesn't claim "zero cost abstraction".

I don't think you need to be fully OOP to claim to be a C++ successor, but you definitely need to have decent zero cost abstractions, including a form of templates/generics. Having RAII might also be a requirement.

All the successor languages mentioned on the article have ways to provide methods and some form of polymorphism directly supported in the language, and not the OOP in C kind of kludge.

polymorphism is not an OOP concept.

https://en.wikipedia.org/wiki/Polymorphism_(computer_science...

You will see Wikipedia doesn't treat it as such. Examples are shown in functional languages and it is not hierarchically categorized as a exclusively a part of OOP.

From that link,

"In a 1985 paper, Peter Wegner and Luca Cardelli introduced the term inclusion polymorphism to model subtypes and inheritance,[2] citing Simula as the first programming language to implement it"

Polymorphism is part of what makes a language OOP capable, naturally it also exists in other paradigms.

We can also do other examples like discussing the semantics of closure and methods equivalency.

https://wiki.c2.com/?ClosuresAndObjectsAreEquivalent

Do you also want Simon Peyton Jones point of view on Haskell type classes and OOP relate to each other?

"Classes, Jim, but not as we know them"

https://www.microsoft.com/en-us/research/publication/classes...

We can keep the discussion going but I don't see why?

Polymorphism is not part of OOP it's much more universal then that. It can be used by OOP the same way numbers can be used as in OOP programming. But numbers are not hierarchically under the umbrella of OOP.

I mean what is the point you're trying to make here? That polymorphism is fundamentally and categorically OOP? Are you saying that anything that uses polymorphism (which is almost every language under the sun) is OOP?

>Do you also want Simon Peyton Jones point of view on Haskell type classes and OOP relate to each other?

No? Wouldn't that be a completely different topic?

All worthy candidates to successor languages to C++ also support OOP in some form, that is the point.

Not the OOP from all I know is Java, rather the OOP from SIGPLAN, ECOOP, IEEE, ACM papers, which happen to have polymorphism as one of the common features across all variations of what can be considered as an OOP capable language.

I think some people believe C++ to be a mistake - if such people were to develop a new langauge they might take issue with framing the new language as a better mistake.

I don’t know that I’ve heard anyone claim that C++ itself was a mistake, although there have obviously been many (acknowledged) mistakes made with C++.

All things considered, for the time, given the paradigms we understood to be effective, and for the value within the design space, C++ was about as close to excellence as we could’ve hoped for. It didn’t replace C, nor was it meant to, but for its purpose it was a great success.

No. C++ being a mistake is a valid argument. There are enough smart people claiming this that you can't dismiss it (Linus Torvalds for example). While the argument is not definitive it is valid enough that it must be considered.

One thing I highly disagree with in your statement is this: " C++ was about as close to excellence as we could’ve hoped for."

In my opinion, C++ is nowhere close to excellence. Best available option for certain applications is more inline with my opinion of it.

> One thing I highly disagree with in your statement is this: " C++ was about as close to excellence as we could’ve hoped for."

It’s fine to disagree, but it seems mildly disingenuous to omit all the qualifiers I (very deliberately and intentionally) prefaced that statement with when you do so. In that sense, you’re actually disagreeing with an opinion I don’t actually hold.

I omitted out of brevity. But ok, I'll put it in:

>All things considered, for the time, given the paradigms we understood to be effective, and for the value within the design space, C++ was about as close to excellence as we could’ve hoped for. It didn’t replace C, nor was it meant to, but for its purpose it was a great success.

I disagree with this entire statement. It's not even close to excellence even given all the deliberate and intentional qualifiers you put around it.

I believe that when I re-clarify my comment in this context it becomes clear that I am in totality disagreeing with your statement.

I think C++ became popular due to luck in the same way javascript came to dominate the frontend. I believe there could've been a number of possible better alternative outcomes if luck would have been different.

> There are enough smart people claiming this that you can't dismiss it (Linus Torvalds for example)

Torvald's anti-C++ rant was full of factual errors when he wrote it and it hasn't improved with age.

If you want to point to "smart people claiming C++ was a mistake" you need to actually use people who actually know & have experience with C++ in the first place - which isn't Torvalds.

There's also other smart people, like John Carmack, who have been converted from C to C++ and now prefer the later especially for working in a team environment. C++ is far from perfect, but there's also pretty strong arguments that it does still represent an improvement over C on average. Yet (almost) nobody argues that C was a mistake.

>There's also other smart people, like John Carmack, who have been converted from C to C++ and now prefer the later especially for working in a team environment. C++ is far from perfect, but there's also pretty strong arguments that it does still represent an improvement over C on average. Yet (almost) nobody argues that C was a mistake.

Agreed. Here is Wikipedia article on criticism of C++. https://en.wikipedia.org/wiki/Criticism_of_C%2B%2B

The second sentence has a short list of some of the smart people who don't like it: "Among the critics have been: Robert Pike, Joshua Bloch, Linus Torvalds, Donald Knuth, Richard Stallman, and Ken Thompson". I'll leave it up to the reader to research why they criticize C++ (not C). However in the references there's a good article from Rob Pike:

https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

Being critical of something does not at all mean they don't like it or, more significantly, think it's a mistake.

Rob Pike's post there, for example, absolutely never comes anywhere close to calling C++ "a mistake."

I don’t understand. For what reason would Pike and Thompson have created Go if they had no criticism of C?

Quoting "celebrities" as if their word is infallible for some reason is just silly.

Torvalds has ranted about many things he knows nothing about and this is no exception. His opinions belong in the trash bin and should be ignored, not used as evidence.

I'd say, RAII and the template system are the main difference between C and C++, not the OOP features. "Zero cost abstraction" is mainly just a welcome side effect of the compiler's optimization passes, and those work in C just as well as in C++ (but typical C++ code depends more heavily on compiler optimizations to clean up redundant "left-overs" from template resolution).

> RAII and the template system

Also function and operator overloading, often overlooked while being of critical importance.

No. Zero cost abstraction was a term used by inventor of C++. It was one of the design principles. Not a side effect.

Source: https://www.stroustrup.com/ETAPS-corrected-draft.pdf

Search for "Zero-overhead abstraction mechanisms".

If you read it you will see Bjarnes goal was to provide the highest level of abstraction possible at "zero overhead". At the time he was creating the language, OOP was the newest and "highest" forms abstraction around... problems with it as an abstraction weren't as evident back then as they are now.

But yeah, I agree that you can make an argument for RAII and templating being the main differences over OOP. But Zero cost abstractions are not a side effect at all.

C++ is not object oriented; it's a multi-paradigm language that supports OO, generic, even some functional, etc. It is a schizophrenic beast that will go (and take you) in any direction you do and do not wish to go.

For example, the STL is everything with a sprinkling of OO. Generics and template metaprogramming are everywhere. Algorithms are defined as distinct for data structures IN ADDITION TO object methods. It is simultaneously elegant and monstrous.

Once the diamond inheritance pattern for iostreams emerged, there was a HARD turn away from OO in the standards body. C++ is literally the embodiment of every programming trend for the last 30 years.

hmm tell me about the diamond inheritance pattern for iostreams and that hard turn away from OO. Never heard of this and couldn't find any sources on an initial search. Got any links on it?

The 'Mutable value semantics' section reads like a carbon copy of the Rust borrow checker. Is it just me or is val just ripping it off completely? I'm honestly not sure of this part so if I'm wrong someone can let me know.

Other than that, the whole title of the article is manipulative. It's not a fair and balanced examination of all the possible successors of C++. The author admits he works on Val, and the article is obviously promoting Val as superior to other alternatives.

What's the difference between Val and Vale? Besides that one letter, of course. There's also Vala which is its own thing, but also in the "not quite C++" space. Very confusing!

Main one is that Val comes from previous Swift developers, and is kind of sponsored by Adobe.

This one is the best introduction. Never heard of Val before until these last few days.

AFAICT, they're both trying to achieve Rust's power with much more simplicity. Val uses mutable value semantics, which (afaict) is like using Rust's &mut and .clone() a lot. Vale uses a foundation of generational references, then region borrow checking to eliminate their overhead.

And it gets even better! There's VALE (Verified Assembly Language for Everest) and two Vlangs ;)

Reply on news.ycombinator.com