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

The pool of talented C++ developers is running dry

efinancialcareers.com

Post reply on HN
Print view View original

681–690 of 869 posts

Re: The pool of talented C++ developers is running dry

#681

Post by jupp0r »

commandlinefan wrote: post #671
jupp0r wrote: post #393

Earlier quoted context omitted.

There's also the opposite problem: older devs will use outdated features and have best practices in place that are now considered antipatterns. This exacerbates the existing difficulties to modernize legacy code bases and creates incentives to not do so. New devs are forced to learn C++ from 20 years ago which is much worse than modern C++.

> have best practices in place that are now considered antipatterns Like using C++ you mean?

C++ is a tool and it still has its use. If you have ever tried to slowly sprinkle Rust into a large C++ code base you will know that it's hard, laborious and error-prone. For completely new projects that don't need existing C++ libraries: sure, I wouldn't use C++ nowadays. There's tons of good reasons that lots of actively developed code is still C++ though.

Re: The pool of talented C++ developers is running dry

#683

Post by zabzonk »

ninefathom wrote: post #670

To quote Yogi Berra, "it's déjà vu all over again." Those of us of a certain vintage remember this precise issue with Fortran a couple decades ago, and those out there of a certain further vintage probably remember it with COBOL. So on and so forth back through PL/I, Algol, and so on to the dawn of time. While there have certainly been consequences of the dearth of COBOL and Fortran devs, ultimately the world has thu…

cobol, fortran, pl/i and algol are all pretty much of the same vintage

Re: The pool of talented C++ developers is running dry

#684

Post by P5fRxh5kUvp2th »

gridspy wrote: post #627
P5fRxh5kUvp2th wrote: post #594

Earlier quoted context omitted.

I would argue C++ type system is superior to even C# and I'm a huge fan of C#. But more to the point, people claim it's somehow harder in C++ to learn programming so either I'm super smart or they're wrong.

The C# standard library is more consistent and powerful (batteries included, more modern). That means there is a "standard, correct" way to do most things in C# in a multi-platform way. C/C++ has massive variety here. Memory management is trivial in C#. So yeah, C# is easier to learn. Perhaps you're super smart?

I'm curious, how did you hear standard library when I said type system?

Re: The pool of talented C++ developers is running dry

#685

Post by wewtyflakes »

germandiago wrote: post #631
astrange wrote: post #623

Earlier quoted context omitted.

My experience with C++ is that every five years I come in and see people claiming that not only should I never do whatever I was told five years ago, but actually it was never popular and nobody ever did it. Mostly about ways to allocate objects or use smart pointers. I'm still wondering why `(int)` is spelled `reinterpret_cast ` in C++. Do they just like hitting keys on the keyboard?

> I'm still wondering why `(int)` is spelled `reinterpret_cast ` in C++ 1. because it is greppable and unsafe 2. because there is also static_cast and dynamic_cast 3. Because in C (int) is all three at once and not greppable -> C will let you do whatever, C++ will not let you do with a static_cast everything you can do with a (T) cast. All in all, it is nice to ask, but if you do not know what you are talking about e…

It doesn't matter since (int) is in the C++ language regardless of how we feel about it, so it seems their point still stands.

Re: The pool of talented C++ developers is running dry

#686

Post by ekidd »

jeffreyrogers wrote: post #647
bdavisx wrote: post #603

Earlier quoted context omitted.

More like NY to SF. The Appalachians would be when you're first learning pointers and the Rockies would be about the time you hit the STL and friends.

You have to learn pointers in Rust too and I don't think the STL is any more complicated than Rust's standard library.

Regular Rust code uses references almost exclusively. (Unless you're working in kernel space or building fancy data structures.)

The big difference between C++ and Rust is what happens when you get something wrong. C++ has lots of undefined behavior and nasty surprises for the unwary. (I led a C++ project for a decade and saw it all.) In Rust, if you get something wrong, the compiler typically refuses to compile it. Which is also very frustrating, but the frustration is all up front.

Re: The pool of talented C++ developers is running dry

#687

Post by ninefathom »

zabzonk wrote: post #683
ninefathom wrote: post #670

To quote Yogi Berra, "it's déjà vu all over again." Those of us of a certain vintage remember this precise issue with Fortran a couple decades ago, and those out there of a certain further vintage probably remember it with COBOL. So on and so forth back through PL/I, Algol, and so on to the dawn of time. While there have certainly been consequences of the dearth of COBOL and Fortran devs, ultimately the world has thu…

cobol, fortran, pl/i and algol are all pretty much of the same vintage

Of origin, certainly, though they experienced very different curves of decline, which seems more pertinent in this case

Re: The pool of talented C++ developers is running dry

#688

Post by riskable »

metalforever wrote: post #634
riskable wrote: post #562

Earlier quoted context omitted.

> Yet, such PCB's are trivial to design. No, analog keyboard PCBs are not trivial at all. You have to keep a lot of things in mind when routing your analog VS digital tracks. Especially if you've got per-key RGB LEDs right next to your hall effect sensors (can be a lot of noise if you don't do it right). Not only that but you also have to figure out how to get loads of analog sensors into a microcontroller that may o…

I don't really see why you would create a keyboard in this way. > ...except 99% of all PCBs aren't that complicated. You don't need to know the specifics of RF in order to design a board that controls some LEDs. There is a difference between creating something that works, which is easy enough to do, and creating something that is competitive on the consumer market, i.e. that BARELY works. This is the difference and w…

Haha... So I can use my awesome contactless magnetic separation+levitation 3D printable Void Switch design of course:

https://github.com/riskable/void_switch

...and so I can do this:

https://gfycat.com/costlyglaringhyracotherium

..and this:

https://gfycat.com/unconsciousvigilantkinglet

You can clean it in the sink with soap and water because there's no electrical contacts or components in the switches.

... But that's really just scratching the surface of what it can do.

Re: The pool of talented C++ developers is running dry

#689

Post by nuancebydefault »

jupp0r wrote: post #675
astrange wrote: post #623

Earlier quoted context omitted.

My experience with C++ is that every five years I come in and see people claiming that not only should I never do whatever I was told five years ago, but actually it was never popular and nobody ever did it. Mostly about ways to allocate objects or use smart pointers. I'm still wondering why `(int)` is spelled `reinterpret_cast ` in C++. Do they just like hitting keys on the keyboard?

> I'm still wondering why `(int)` is spelled `reinterpret_cast ` in C++. Do they just like hitting keys on the keyboard? They are doing different things. For example, `reinterpret_cast ` cannot cast away constness but `(int)` can. There are other differences and you should never use C-style casts. In most C++ code bases I worked on, there were static code analysis checks pre merge that would prevent anybody from merg…

This is a very good example of C++ being difficult to master. There are heaps of ways of doing one thing and usually there are just one or a few of those a good practice, but to explain the best practice's rationale, you need to know and tell a whole story. A simple cast even needs a story. Let alone smart pointers combined with normal pointers; ampersands and const qualifiers that have different meanings depending on where you put them and so on. You can fill a small book with explaining initializers, a big book with explaining templating. In the same amount of pages you can explain the complete ANSI C.

Re: The pool of talented C++ developers is running dry

#690

Post by eigenspace »

programmer_dude wrote: post #680
adgjlsfhk1 wrote: post #567

Earlier quoted context omitted.

Julia is solving many of the same problems as C++. GPU compute, HPC, high performance algebra kernels are all well within Julia's purview. It's not (at least yet) good for things like writing OS kernels but there is a large amount of overlap with C++.

Isn't Julia a dynamically typed language?

Yes. So what?
Post reply on HN