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

C++26 Reflections adventures and compile-time UML

reachablecode.com

Post reply on HN
Print view View original

111–118 of 118 posts

Re: C++26 Reflections adventures and compile-time UML

#111

Post by einpoklum »

rramadass wrote: post #70
einpoklum wrote: post #60

Earlier quoted context omitted.

Much of the complexity may be perceived, but much is also real, because of the commitment to backwards compatibility and non-breakage, plus poor default behavior of many things, often due to the C legacy, sometimes due to inopportune choices in earlier versions of the standard. Just think of things like variable initialization with () and/or {} ; or various kinds of implicit casts ; the hoops you need to go through t…

The problem is that many confuse C++ Language expertise (often snarkily called a "language lawyer") with C++ Programming expertise. A famous example is Scott Meyers who is squarely in the first camp and who has publicly stated as not having written any sizeable C++ programs. Given that C++ is quite a baroque language it is important for programmers to focus on the second aspect and slowly build up their knowledge of…

As a person who has some of both, I'm not so sure I agree. Many developers just get into the habit of assuming they don't need any more language knowledge, since they get by already, and the codebase they use is filled with code which fails to utilize most modern language features, and _that_ is already quite a hassle to know well enough to use.

Re: C++26 Reflections adventures and compile-time UML

#112

Post by motorest »

jcelerier wrote: post #108
motorest wrote: post #91

Earlier quoted context omitted.

> I'm not a fan of the C++26 linalg stuff. I don't agree at all. For most, linear algebra is the primary reason they pick up C++. Up until now, the best option C++ newbies had was to go through arcane processes to onboard a high performance BLAS implementation which then requires even more arcane steps such as tuning. With C++26, anyone can simply jump into implementing algorithms. If anything, BLAS support was consp…

> I don't agree at all. For most, linear algebra is the primary reason they pick up C++. Out of hundreds of hundreds of projects I've interacted with, maybe less than 1% have used linear algebra in any non-basic capacity (e.g. more than multiplying two 4x4 matrices) and had to use Eigen or BLAS

> Out of hundreds of hundreds of projects I've interacted with, maybe less than 1% have used linear algebra in any non-basic capacity (e.g. more than multiplying two 4x4 matrices)

Are you really trying to argue that if you ignore the bulk of applications that have linear algebra then only a few have linear algebra?

> and had to use Eigen or BLAS

What if I told you that if C++ provided basic support for linalg, your average C++ developer wouldn't ever have to hear about Eigen or blas?

It's perfectly fine if you want to use the likes of Eigen. It's also perfectly fine if any developer opts to ditch the STL and use any performance-oriented container.

But is it ok to force everyone to onboard a third party library just to be able to do very basic things like use a stack or do a dense matrix-vector multiplication? I don't think that leads to a good developer experience.

Re: C++26 Reflections adventures and compile-time UML

#113

Post by motorest »

account42 wrote: post #107
motorest wrote: post #91

Earlier quoted context omitted.

> I'm not a fan of the C++26 linalg stuff. I don't agree at all. For most, linear algebra is the primary reason they pick up C++. Up until now, the best option C++ newbies had was to go through arcane processes to onboard a high performance BLAS implementation which then requires even more arcane steps such as tuning. With C++26, anyone can simply jump into implementing algorithms. If anything, BLAS support was consp…

> This blend of comments is more perplexing given that a frequent criticism of C++ is its spartan standard lib The frequency doesn't make the criticism more valid and those repeating it would be better served to let go of their fear of third-party libraries.

> The frequency doesn't make the criticism more valid (...)

The criticism is not valid. It's specious reasoning at best, fueled by a hefty dose of gatekeeing.

The only rationale that is relevant is whether the standard library provides a way to do a very basic and fundamental task instead of having to force anyone to onboard and manage third party dependencies. That's the whole point of a standard library, isn't it?

Re: C++26 Reflections adventures and compile-time UML

#114

Post by account42 »

motorest wrote: post #113
account42 wrote: post #107

Earlier quoted context omitted.

> This blend of comments is more perplexing given that a frequent criticism of C++ is its spartan standard lib The frequency doesn't make the criticism more valid and those repeating it would be better served to let go of their fear of third-party libraries.

> The frequency doesn't make the criticism more valid (...) The criticism is not valid. It's specious reasoning at best, fueled by a hefty dose of gatekeeing. The only rationale that is relevant is whether the standard library provides a way to do a very basic and fundamental task instead of having to force anyone to onboard and manage third party dependencies. That's the whole point of a standard library, isn't it?

No the point of a standard library is to provide vocabulary types (so that third-party libraries can interoperate) as well as basic operations that are essentially set in stone. Anything beyond that needs to have its usefulness weighted against its maintenance burden, which for a standard library that is serious about backwards compatibility is enormous. C++ is already also heavily criticized for being complex with many problems having multiple outdated solutions that you're not supposed to use.

"Onboarding" a third party library isn't this herculean task that you make it out to be but is in fact a very basic part of software development that almost any project will have to deal with anyway unless you are into reinventing the wheel - even excessively bloated standard libraries don't manage to cover everything.

Re: C++26 Reflections adventures and compile-time UML

#115

Post by rramadass »

einpoklum wrote: post #111
rramadass wrote: post #70

Earlier quoted context omitted.

The problem is that many confuse C++ Language expertise (often snarkily called a "language lawyer") with C++ Programming expertise. A famous example is Scott Meyers who is squarely in the first camp and who has publicly stated as not having written any sizeable C++ programs. Given that C++ is quite a baroque language it is important for programmers to focus on the second aspect and slowly build up their knowledge of…

As a person who has some of both, I'm not so sure I agree. Many developers just get into the habit of assuming they don't need any more language knowledge, since they get by already, and the codebase they use is filled with code which fails to utilize most modern language features, and _that_ is already quite a hassle to know well enough to use.

Information and knowledge can be had at any age but it takes experience over time to gain wisdom. It is not that experienced developers are reluctant to learn new things but are cautious and conservative when it comes to adopting and putting them into practice especially for non-trivial systems in production. They have already tamed the complexity of their system and devised workable solutions to thorny problems and hence do not deem it wise to rewrite everything just because of some new fad and/or exciting feature being introduced in their language of use.

The fact that C++ is a multi-layered language with assured backwards compatibility really helps in slowly migrating to newer design paradigms and performant techniques while being sure/stable every step of the way.

Re: C++26 Reflections adventures and compile-time UML

#116

Post by burnt-resistor »

matt123456789 wrote: post #3

Whenever I start to feel like a real programmer making games and webapps and AI-enhanced ETL pipelines, I inevitably come across the blog post of a C++ expert and reminded that I am basically playing with legos and play-doh.

That's pretty advanced. I realize now I've been finger-painting on the non-washable walls all along. I will now sit in the corner with a dunce cap and consider an execution model for each of greedy and lazy functional languages.

Re: C++26 Reflections adventures and compile-time UML

#117

Post by burnt-resistor »

devjab wrote: post #38
tombert wrote: post #2

I had to do a UML thing for the first time in years for a class a few weeks ago[2]. I'm not 100% convinced that UML is actually useful at all. Obviously if you find value from it, don't let me take that from you, by all means keep doing it, but all it seemed to provide was boxes pointing to other boxes for stuff that really wasn't unclear from looking directly at the code anyway. It's really not that hard to look dir…

For many of us UML has been completely irrelevant for decades. If you're deep down the OOP rabbit hole, then UML can have it's place in helping you keep track of your hierarchies. If you use it then I'd assume that getting your process of keeping it updated as automated as possible would be a high priority, unless you want it to rod in some ivory tower. Personally I view architecture in UML, ArchiMate or draw.io rath…

Remember when people used tools like Rational Rose to satisfy project managers and pointy-hair bosses?

And not to satisfy documentation requirements for critical safety systems.

Re: C++26 Reflections adventures and compile-time UML

#118

Post by [deleted] »

motorest wrote: post #77
SleepyMyroslav wrote: post #51

Earlier quoted context omitted.

You are sounding like rose tinted glasses are on. I think your glass is half full if you recheck actual versions and features. And mine is half empty in gamedev. Anecdata: A year or so ago I have been in discussion if beta features of C++20 on platforms are good to be used on large scale. It makes it not a sum but an intersection of partial implementations. Anyway it looked positive until we needed a pilot project to…

> One of the projects came back with 'just flipping C++20 switch with no changes causes significant regression on build times'. I think this just proves that your team is highly inexperienced in C++ projects, which you implicitly attest by admitting this was your first C++ upgrade you had to go through. Let me be very clear: there is never an upgrade of the C++ version targeted by a project that does not require full…

[deleted]
Post reply on HN