Live data from Hacker News

The pool of talented C++ developers is running dry

efinancialcareers.com

561–570 of 869 posts

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

#561

Earlier quoted context omitted.

holy mother of god! I used C++ around 2000 for some old projects. When new and delete where the object oriented "equivalent" for malloc() and free(). So, if you don't use that, what do you use in 2022 C++?

`std::make_unique()`, `std::make_shared()`, or another function that wraps `new` and `delete` into an RAII type (commonly called a smart pointer) so that you, the developer, worry less about explicit memory management. And the standard smart pointers are perfectly extensible enough to wrap things allocated from C libraries (I like to pick on opengl's glalloc() and glfree(), though malloc() and free() are acceptable t…

std::auto_ptr was broken and didn't work with STL. It wasn't until C++11 introduced "move" semantics that you could really use smart pointers.

You can't really blame him for not using a part of the language that was unusable, right?

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

#562

Earlier quoted context omitted.

As someone who's not an EE (with no degree in anything at all) and has made many circuit boards... No, they're not that complicated. Not really. I've even designed an analog hall effect keyboard PCB with integrated IR sensor, dual power regulators (to handle 95 ultra bright RGB LEDs), invented-by-me analog hall effect rotary encoders (incremental and absolute), and more. It wasn't rocket science.

> I've even designed an analog hall effect keyboard PCB with integrated IR sensor, dual power regulators (to handle 95 ultra bright RGB LEDs), invented-by-me analog hall effect rotary encoders (incremental and absolute), and more. It wasn't rocket science. Sorry to burst your bubble... Glad you learned enough to do it and had fun with it. Yet, such PCB's are trivial to design. Heck, one could auto-route something lik…

> 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 only have 4 analog pins (e.g. RP2040). In a way that can be scanned fast enough for 1ms response times (again, without generating a ton of noise).

It's not so simple like an electromechanical keyboard PCB which is quite trivial.

> For an example of complex design one can look at such things as almost any dynamic RAM implementation, from SDR to DDRn. Timing, signal integrity and power integrity are a big deal and can make a massive difference in performance and reliability.

...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.

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

#563
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++.

The difference between C++ today, and what we had 20 years ago is not much. C++ has functionality built in today, we didn't have, but the OS provided, and now the language has many features we wished we had years ago. Example: Variadic templates. When that happened, the problems we would bang our head against the wall with magically vanished. Twenty years ago, every implementation of the std library had serious bugs…

Template metaprogramming is hardly ever needed anymore. C++20 has better built-in features that for most of what was done with it, that compile much faster.

Almost all C++ programmers completely ignore it. You can too.

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

#565

Earlier quoted context omitted.

> glorified CRUD apps Why is API design/backend engineering the only software discipline that gets maligned like this? These are bread-and-butter operations. I don't mean to attack you, just noting that I never hear anyone talk about mobile development in the same way, for example.

A lot of CRUD app development feels like tedious, repetitive busy work. Data entry was a solved problem in COBOL if not earlier, it's not gotten any harder in the decades since, it's just gotten more tedious. There are generic data entry tools that solve the entire class of problems in that space. In web tooling there are things like Django's Admin app. In "the ancient world" there is Excel for good and bad and ugly.…

I think there's truth to this but you're glossing over details that are critical. If the amount of variation between products were countable and predictable as you paint it, then you'd only need designers and a cms specialist who can configure the product. As a web shop, this is much cheaper to do. There are tons of website builders today which has saturated the "simple" market, but "intermediate" customers have small variations that still need custom integration work.

All in all, saying that dev work is repetetive is a hard sell, because if it was, you could just automate it. And we clearly haven't automated even the space of medium-complexity web apps yet.

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

#566
post #346

Earlier quoted context omitted.

Sounds… problematic. What can you say about the state of security with it?

The code is quite secure, but the process and company are... typical processes and company people. Paper ballots and physical boxes are more secure if good practices are followed. At one point I was tasked with shuffling the data layout on disk in real time to mitigate de-anonymization attacks. Security was real concern. Crypto everywhere. The voted ballots were encrypted with keys generated and delivered immediately…

This is really interesting. Here in Australia we still use paper ballets for the lower house of parliament. I volunteered as a “scrutineer” for one of the parties, which let me go into the warehouse where the ballots were being counted and watch. As an scrutineer, you physically look over the shoulder of the person counting votes and double check their work. You can’t touch anything, but if you disagree with the vote, you can flag it. The voting slip gets physically sent to a committee somewhere for final judgement.

I highly recommend the experience if you’re Australian - it was very cool seeing democracy in action. I personally have a lot more faith in our system of voting after seeing it in action first hand.

That said, the senate votes are all typed into a computer by the election officials. It’s just too hard to do preferential voting by hand with ~200 candidates on the ballot.

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

#567
post #413

Earlier quoted context omitted.

As someone who has been writing C++ at Google, this exactly. Despite all the tooling, guidelines and "internal magic", C++ is still an abomination. And no it has nothing to do with memory management, I actually do like C. I love how Eric Raymond describes it as "anti-compact", because, well, it really is. C++ as a whole should be deprecated -- and no new projects should use C++ (unless for some very odd and specific…

>C++ as a whole should be deprecated -- and no new projects should use C++ (unless for some very odd and specific reason). And what can be used instead of C++? C? If C was better, then C++ wouldn't have been invented. Rust? It's much more painful to use than C++. Zig? It's immature and has very low usage. Nim? Has very low user base. Julia? It isn't solving the same problems.

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++.

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

#568

Earlier quoted context omitted.

I’m building a house at the moment and I have been insisting that I am able to actually test all the built in appliances with power to see if the software is garbage. I have found that most of the high end brands have a completely horrible user experience. Miele is the worst I’ve tried, and I found that as you go up the price range even inside that brand the experience gets worse. The top end Miele induction cooktop…

Good to know about Miele ranges -- this would certainly infuriate me. I wonder if their higher end dishwashers have the same usability problems.

Most dishwashers stay on all the time, drawing watts 24/7. That could be microwatts, but that might cost an extra dollar.

Probably the cooktop boots up anew each time because otherwise you would have to be able to reset it when it crashes.

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

#569

I can see why since I am searching for jobs: 1. Juniors are no hired for C++ type roles. Employers want someone with 5+ years of experience, because just knowing the syntax is not enough. And training on the job is also not offered. 2. It pays shit in comparison. 3. Job positions are relatively scarce. My actual niche is numerics (so writing numerical libraries and simulations), btw. I was really dismayed to see how…

#1 needs to be emphasized.

8-12 years ago I knew modern C++ inside-and-out. I worked on high-performance template developer libraries. These days whenever a C++ opening comes up in my job feed, it's in game development or it requires extensive domain-specific embedded/firmware experience. I just shrug and move on.

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

#570
post #209

I’ll offer a perspective unrelated to pay: It’s a pain to start learning C++, and even after you do, older devs will roast the hell out of your code because your book/tutorials of choice forgot to mention a crucial (in their opinion) feature that you absolutely should/shouldn’t use! Not to mention you’ve only programmed on Mac/Linux so far & windows is totally different, has a different compiler, different ways to in…

As a C++ enjoyer I would 100% have learned Rust if it was around when I started... just for Cargo alone.

Problem is now I've already done my time in the Makefile trenches there's little incentive in me re-learning another systems lang and having to compete with lots of smarter people, with more Rust exp, for jobs whilst giving up all my arcane knowledge of CMake and friends.

Rust being popular atm is great for C++ if I'm honest as it siphons away a new gen of systems programmers over to another lang allowing me to sell my dark services for more coins.

Post reply on HN