C++ has lost its way?
-
Quote:
However, there are other common solutions that we also employed to reduce build times, including local caching, remote caching, and precompiled headers.
From the rest of the writing, it seems they haven't implemented precompiled headers correctly, because all their efforts to eliminate redundant headers amount to very little savings if the precompiled header gets each precompilation unit added once and then not again with additional redeclarations. At least that is the way I understand precompiled headers, and they have saved me a bunch of time in the past. I wish they would have talked about that aspect more as my understanding could be deepened. PS -
Mike Winiberg wrote:
In part, the effort to maintain backwards compatability at almost any cost (despite the fiasco of i(o)streams and manipulators between versions 1,2 and 3) whilst adding ever more features adds huge amounts of technical debt that then has to be fought against in other ways. This article I think demonstrates this nicely Speeding Up C++ Build Times | Figma Blog[^]
I don't see that article supporting your assertion in any meaningful way. All it seems to be saying is that their coders haven't kept their headers clean, and often included unneeded headers that they had to take out. That doesn't seem to be speaking about the difficulties inherent in modern C++.
Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
-
As an incredibly enthusiastic user of C++ from its very first release, I've expressed this (personal) opinion a number of times over recent years: C++ has lost its way - it now takes more time, learning, effort and skill to make good, efficient use of C++ than it takes to solve the problems one is using it for. A caveat: I am thinking specifically of business tasks and related domains - I accept that for the most cutting edge stuff near to the metal it still offers the one of the best overall effort/performance ratios. In part, the effort to maintain backwards compatability at almost any cost (despite the fiasco of i(o)streams and manipulators between versions 1,2 and 3) whilst adding ever more features adds huge amounts of technical debt that then has to be fought against in other ways. This article I think demonstrates this nicely Speeding Up C++ Build Times | Figma Blog[^] Discuss! (ducks for cover...)
Mike Winiberg wrote:
As an incredibly enthusiastic user of C++ from its very first release,
45 years. And still enthusiastic? Not denigrating C++ but rather that it is difficult to keep the same enthusiasm for anything that long.
Mike Winiberg wrote:
technical debt that then has to be fought against in other ways.
Get a very old set of libraries, say before templates, update them to work with your compiler and then just don't use anything new.
Mike Winiberg wrote:
This article I think demonstrates this nicely
Far as I can tell that doesn't enumerate the size of the code base. But it certainly seems to suggest that the author is working with a large one. And a legacy one at that. So I don't really see anything that suggests that there is a problem with C++ but rather a process problem that has been allowed to grow without bound. And so they want to use technology to fix it. Rather than decoupling the code base to reduce the dependent sections.
-
Mike Winiberg wrote:
As an incredibly enthusiastic user of C++ from its very first release,
45 years. And still enthusiastic? Not denigrating C++ but rather that it is difficult to keep the same enthusiasm for anything that long.
Mike Winiberg wrote:
technical debt that then has to be fought against in other ways.
Get a very old set of libraries, say before templates, update them to work with your compiler and then just don't use anything new.
Mike Winiberg wrote:
This article I think demonstrates this nicely
Far as I can tell that doesn't enumerate the size of the code base. But it certainly seems to suggest that the author is working with a large one. And a legacy one at that. So I don't really see anything that suggests that there is a problem with C++ but rather a process problem that has been allowed to grow without bound. And so they want to use technology to fix it. Rather than decoupling the code base to reduce the dependent sections.
A few vaguely related further comments: TL;DR - just my musings 8) "If you don't use it you don't pay for it" is - IMHO - a good philosophy, and why C++ remains such a good dev environment for cutting edge stuff. It is indeed perfectly possible to use C++ as an 'improved' C and only adopt specific features - but surely in that case you might as well go for a dev environment that is more closely matched to the domain you are working in (if one exists of course)? Attempting to stick with C++ when it isn't a good fit can lead to the kind of thing you see today with web app dev: I regularly see devs posting about the 'stack' they use, sometimes comprising 20 or more different frameworks all bolted together using another framework, simply to create simple web pages that could be easily produced with just HTML and CSS (itself a bit of a dog's breakfast IMHO!). --- Never has KISS been more appropriate than in some of today's dev processes. The interdependencies of such 'stacks' make the whole thing so fragile that one defect or change in the hosting environment can bring the whole thing tumbling down. Pile on the inappropriate adoption of 'Agile' processes and TDD and you end up with the kind of mess you see in the UK on so many GOV.UK web pages: The pages pass all their tests and hence are deemed 'correct' and yet don't perform as the users have a right to expect: I have one classic example that I have reported repeatedly but which has still not been fixed after many years: paying your vehicle excise duty: You are sent a document with a 16 digit number in the same format as a credit card: 4 groups of 4 digits. When you type this into the online form, if you include the spaces and don't notice that the input box only accepts 16 characters (ie you lose the last 3 if you include the spaces), then complete the rest of the page, when you hit submit the page fails but the error message is displayed next to the box itself which by now is off the top of the screen. You have to scroll back up to see it! There is no warning in advance that the spaces must be omitted. Either accepting and ignoring or silently dropping the spaces is a very simple thing to implement but hasn't been done - a typical noob web dev mistake. It gets better though: a bit later you have to enter your card details, which comprise a 16 digit number in four groups of 4. On this page you can enter this with or without spaces and it is accepted quite happily. By chance I met a dev working for GOV.UK on this stuff: he couldn't see the problem, the
-
As an incredibly enthusiastic user of C++ from its very first release, I've expressed this (personal) opinion a number of times over recent years: C++ has lost its way - it now takes more time, learning, effort and skill to make good, efficient use of C++ than it takes to solve the problems one is using it for. A caveat: I am thinking specifically of business tasks and related domains - I accept that for the most cutting edge stuff near to the metal it still offers the one of the best overall effort/performance ratios. In part, the effort to maintain backwards compatability at almost any cost (despite the fiasco of i(o)streams and manipulators between versions 1,2 and 3) whilst adding ever more features adds huge amounts of technical debt that then has to be fought against in other ways. This article I think demonstrates this nicely Speeding Up C++ Build Times | Figma Blog[^] Discuss! (ducks for cover...)
C, in all it's variants (and that includes JAVA and RUST) is an abomination. It should never have survived as long as it has. It was only ever intended to be a 'bridging' language between the horror of Fortran and the "New" languages that were just around the corner.
-
C, in all it's variants (and that includes JAVA and RUST) is an abomination. It should never have survived as long as it has. It was only ever intended to be a 'bridging' language between the horror of Fortran and the "New" languages that were just around the corner.
I'm not sure I entirely agree with that view 8) but its utility and closeness to the metal gave it wings, especially in the early days of desktop computing when efficiency was very important, and once such systems become ubiquitous then one tends to get stuck with them. See COBOL and indeed FORTRAN (never mind MS Word which is as unlike a word processor as it is possible to get whilst still handling text) for further examples...
-
I'm not sure I entirely agree with that view 8) but its utility and closeness to the metal gave it wings, especially in the early days of desktop computing when efficiency was very important, and once such systems become ubiquitous then one tends to get stuck with them. See COBOL and indeed FORTRAN (never mind MS Word which is as unlike a word processor as it is possible to get whilst still handling text) for further examples...
I thought that might get a reaction. But, my opinion still stands. In the bad old days of 8086 through to at least 80386, you were much better off learning assembler. Once Windows became ubiquitous, things got more difficult, but by then, we **should** have had better languages available than C and it's derivatives. The few that were viable seem to have been killed off by the C people to protect their their pet little ecosystem (But that does sound a bit like a conspiracy theory)
-
I thought that might get a reaction. But, my opinion still stands. In the bad old days of 8086 through to at least 80386, you were much better off learning assembler. Once Windows became ubiquitous, things got more difficult, but by then, we **should** have had better languages available than C and it's derivatives. The few that were viable seem to have been killed off by the C people to protect their their pet little ecosystem (But that does sound a bit like a conspiracy theory)
Quite by chance this passed across my feed just after my reply above: https://medium.com/@CognitiveProgrammer/modern-c-programming-things-that-shouldnt-be-used-anymore-f7f046f09c04[^] Reinforces both our points I feel! :-D
-
As an incredibly enthusiastic user of C++ from its very first release, I've expressed this (personal) opinion a number of times over recent years: C++ has lost its way - it now takes more time, learning, effort and skill to make good, efficient use of C++ than it takes to solve the problems one is using it for. A caveat: I am thinking specifically of business tasks and related domains - I accept that for the most cutting edge stuff near to the metal it still offers the one of the best overall effort/performance ratios. In part, the effort to maintain backwards compatability at almost any cost (despite the fiasco of i(o)streams and manipulators between versions 1,2 and 3) whilst adding ever more features adds huge amounts of technical debt that then has to be fought against in other ways. This article I think demonstrates this nicely Speeding Up C++ Build Times | Figma Blog[^] Discuss! (ducks for cover...)
-
As an incredibly enthusiastic user of C++ from its very first release, I've expressed this (personal) opinion a number of times over recent years: C++ has lost its way - it now takes more time, learning, effort and skill to make good, efficient use of C++ than it takes to solve the problems one is using it for. A caveat: I am thinking specifically of business tasks and related domains - I accept that for the most cutting edge stuff near to the metal it still offers the one of the best overall effort/performance ratios. In part, the effort to maintain backwards compatability at almost any cost (despite the fiasco of i(o)streams and manipulators between versions 1,2 and 3) whilst adding ever more features adds huge amounts of technical debt that then has to be fought against in other ways. This article I think demonstrates this nicely Speeding Up C++ Build Times | Figma Blog[^] Discuss! (ducks for cover...)
-
C, in all it's variants (and that includes JAVA and RUST) is an abomination. It should never have survived as long as it has. It was only ever intended to be a 'bridging' language between the horror of Fortran and the "New" languages that were just around the corner.
Member 14564709 wrote:
C, in all it's variants (and that includes JAVA and RUST) is an abomination. It should never have survived as long as it has.
PHP - wasn't intended to be a programming language in the first place. Using the tiobe index and excluding that then removing all of the other languages that did originate with C one gets down to Basic, SQL and Fortran.
Member 14564709 wrote:
between the horror of Fortran and the "New" languages that were just around the corner.
But it doesn't exist. People create a lot of new programming languages every year. And very few are ever generally accepted. So what you are suggesting will not or cannot exist.
