Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Parsing C++ is literally undecidable (2013)

blog.reverberate.org

Post reply on HN
Print view View original

41–50 of 146 posts

Re: Parsing C++ is literally undecidable (2013)

#41

Post by carlmr »

jokoon wrote: post #32
xiphias2 wrote: post #25

Earlier quoted context omitted.

Rust seems to be the most successful zero-overhead language competitor to C++, though it's far not as mature as C++ yet.

Rust has a high learning curve (borrowing, etc). Rust is a competitor to ADA, not C++. You can certainly ask developers to write things in rust instead, and even progressively rewrite codebase in rust since it's compatible with C++, but a language is about adopters, and ease of learning for beginners and students.

Counterpoint, when you write C++ you need to think about borrowing without the compiler telling you when you're making a mistake. Rust in that sense is easier than C++.

Re: Parsing C++ is literally undecidable (2013)

#42

Post by TeMPOraL »

gpderetta wrote: post #34
choeger wrote: post #22

This is one of the major issues with these languages that were initially designed by amateurs (I mean that in the positive sense, someone who does something because they care about it, and not because they are paid to do it). Often they simply did not see the long-term benefit of adhering to the limits of a "standard" architecture (i.e., context-free, unambiguous grammar, decidable static analysis (lookup!), multi-pa…

>Yet these hackers still made a successful product. Worse is, was and always will be better. It seems that's an unchanging law of software design. Practicality, getting things done and catering to user needs always beats purity, elegance and soundness.

Less rosy view: sacrificing quality to increase adoption or decrease time to market always wins, so on the market, all software moves towards being the worst possible design that's still fit for purpose.

Alternative phrasing: the market runs on greedy optimization, which means a lot of value that could be gained is simply unreachable.

Re: Parsing C++ is literally undecidable (2013)

#43

Post by eru »

jstimpfle wrote: post #28
pjmlp wrote: post #24

Earlier quoted context omitted.

Plenty of GC enabled system languages have proven their value, up to building full stack graphical workstations, so far they just lacked somg big corp political and monetary willingness to push them down the anti-GC devs no matter what. Thanfully with the likes of Swift on iDevices, Java/Kotlin on Android (with an increasingly constrained NDK), COM/UWP über alles + .NET on Windows, ChromeOS + gVisor, Unreal + GCed C+…

> I give it about 10 years time, for pure manual memory management to be like Assembly and embedded development. For someone who has spent some time thinking about memory management strategies, manual MM isn't actually that much additional work. By far, most code doesn't allocate or free (and that's a good thing). So MM->GC is hardly like Assembly->Compiler. In Assembly you're constantly allocating and pigeonholing,…

> By far, most code doesn't allocate or free (and that's a good thing).

Depends on the code you write. If, like in C++, non-stack memory management is painful, programmers tend to react like you suggest.

In pure-by-default languages, you are creating new and destroying old objects all the time. (At least conceptually. A sufficiently smart compiler can eliminate most of that.)

Re: Parsing C++ is literally undecidable (2013)

#45

Post by skohan »

choeger wrote: post #22

This is one of the major issues with these languages that were initially designed by amateurs (I mean that in the positive sense, someone who does something because they care about it, and not because they are paid to do it). Often they simply did not see the long-term benefit of adhering to the limits of a "standard" architecture (i.e., context-free, unambiguous grammar, decidable static analysis (lookup!), multi-pa…

In defense of amateurs, there is also something to be said for the ergonomics which come out of designing a language iteratively, against concrete use-cases, rather than from a purely theoretical direction.

Re: Parsing C++ is literally undecidable (2013)

#46

Post by fanf2 »

rienbdj wrote: post #10

Can we design a language (cpp-prime?) that is basically c++ but makes parsing easier? I'm thinking reduce the keyword reuse, use different symbols for multiplication and pointers etc. The code would be easy for c++ developers to read and converting between the two could be automatic. However, we would be able to build tooling for this new language much more easily. It would also compile quicker.

Damian Conway has a couple of papers from 1996 suggesting a better syntax for C++ http://users.monash.edu/~damian/papers/#Human_Factors_in_Pro...

Re: Parsing C++ is literally undecidable (2013)

#47

Post by gpderetta »

TeMPOraL wrote: post #42
gpderetta wrote: post #34

Earlier quoted context omitted.

>Yet these hackers still made a successful product. Worse is, was and always will be better. It seems that's an unchanging law of software design. Practicality, getting things done and catering to user needs always beats purity, elegance and soundness.

Less rosy view: sacrificing quality to increase adoption or decrease time to market always wins, so on the market, all software moves towards being the worst possible design that's still fit for purpose. Alternative phrasing: the market runs on greedy optimization, which means a lot of value that could be gained is simply unreachable.

Definitely.

There is still value in elegant and sound solutions though. Even if inevitably unsuccessful, they will still be influential on the next round of practical hacks.

Re: Parsing C++ is literally undecidable (2013)

#48

Post by tralarpa »

vkazanov wrote: post #40
rightbyte wrote: post #26

Earlier quoted context omitted.

If I remember correctly Stroustrup was working at Bell labs in the initial phases of the cpp design with a formal education in CS. Hardly an amateur? Inexperienced maybe.

"Formal education in CS" is not the same as, say, a degree related to programming languages or compilers.

Yes. There is a section in one of his books where he wrote that he added some feature in an ad-hoc way just because of a request from a colleague. Unfortunately, as I have already written in another comment some months ago, C++ was the wrong thing that came at the right time (C people were starting looking for alternatives, seeing what cool things other languages were doing).

Re: Parsing C++ is literally undecidable (2013)

#49

Post by gmueckl »

gpderetta wrote: post #36
rienbdj wrote: post #10

Can we design a language (cpp-prime?) that is basically c++ but makes parsing easier? I'm thinking reduce the keyword reuse, use different symbols for multiplication and pointers etc. The code would be easy for c++ developers to read and converting between the two could be automatic. However, we would be able to build tooling for this new language much more easily. It would also compile quicker.

You could, but the incompatibility is not necessarily worth it. There was some talk to take advantage of the transition to modules to be able to mark translation units as implementing a specific version of the standard (I think rust doese something similar) to allow for backward incompatibile Evolution of the language. The committee doesn't seem to keen because they fear the language fragmenting and from a more pract…

With the glacial pace in which new language features are picked up by users of C++, I'd be surprised if modules have significant adoption in the first decade after C++20. It'll probably take at least two to three years to get stable support in most of the tooling and then anther couple of years until people start to believe that they are battle tested enough.

Re: Parsing C++ is literally undecidable (2013)

#50

Post by iainmerrick »

vkazanov wrote: post #40
rightbyte wrote: post #26

Earlier quoted context omitted.

If I remember correctly Stroustrup was working at Bell labs in the initial phases of the cpp design with a formal education in CS. Hardly an amateur? Inexperienced maybe.

"Formal education in CS" is not the same as, say, a degree related to programming languages or compilers.

Sure it is! A reputable CS degree will cover multiple programming languages and compiler implementation.

I don’t think you could study just “compilers”, say, at undergrad level. Maybe you mean postgrad or postdoc-level qualifications?

It would certainly be a pretty different world if you were only allowed to design a new programming language after getting your PhD in language design.

Post reply on HN