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

741–750 of 869 posts

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

#741

Post by sgerenser »

Retric wrote: post #641
dudeofea wrote: post #388

Earlier quoted context omitted.

how is it a nightmare? if you aren't getting that energy from natural gas, you'd mostly get it from a CO2 producing power plant, with efficiency losses going from heat (steam) -> electric -> heat (cooktop)

Even Gas cooktops without a pilot light are surprisingly inefficient with under 40% of the energy ending up in your pan. (Which is why the air several feet above the pan is so hot.) On top of this you end up venting air your HVAC system just used a lot of energy to make pleasant outside and/or breathing noxious fumes from incomplete combustion so Carbon Monoxide, NOx, formaldehyde etc Induction stoves powered by natu…

It’s even worse if you don’t size the burner to the pan. My wife always uses the largest burner with an 8 inch pan, probably 70% of the heat goes around and over it. Really made me want to switch to induction but I noticed the same thing that most induction cooktops have stupid, unreliable touch controls.

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

#742

Post by intelVISA »

jack_h wrote: post #175
cmrdporcupine wrote: post #86

Earlier quoted context omitted.

This is what I find astounding. I wonder how much is just EEs looking at SWE resumes and going "why would I pay that much for this?! writing code isn't that hard" I definitely get that vibe from some of the local hw-eng companies. And they may not be wrong, but.. sorry, that's supply and demand. If I have to go write stupid NodeJS stuff to get paid decently, I guess I'll have to go do that.

I worked at a place once where one of the EEs who wrote firmware told me that algorithms and data structures were pointless because in the end it's just bits in a linear address space in RAM. The industry has basically screwed itself. It's pretty typical for companies to consider embedded/firmware as EE work that is done in the gaps of the hardware schedule. EEs generally make bad programmers which shouldn't be a sur…

> one of the EEs who wrote firmware told me that algorithms and data structures were pointless because in the end it's just bits in a linear address space in RAM.

He might be onto something you know...

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

#743

Post by antonb90 »

This is interesting to see. I don’t use c++ professionally but I have started to use it in my spare time for some side projects.

I find it interesting as it gives a lot of control over OS primitives.

One thing I found a little odd was the various different ways to build and import third party libraries. Finding the include directories and linking the libraries can be a pain.

I use cmake and ninja which seems to be somewhat easier to wrangle with.

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

#744

Post by FpUser »

rychco wrote: post #494
DeathArrow wrote: post #488

Earlier quoted context omitted.

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

Mark Russinovich (of Sysinternals fame), thinks Rust should be the non-GC language of choice moving forward. https://twitter.com/markrussinovich/status/15719951172335042...

I do respect Mark and his Sysinternals products. However I could not care less what he thinks is the language I should be using. I choose what works for me and as long as it brings me healthy dosh I am not in need of one's "approval.

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

#745

Post by intelVISA »

lazypenguin wrote: post #483
DeathArrow wrote: post #433

Earlier quoted context omitted.

>solving hard C++ problems when I can go do some easier web backend stuff As guy who worked with both C++ and backend I would assume you don't have much experience if you say one is harder than the other. Different beasts, different problems to solve, complexity lies in different parts.

Why would you dismiss my comment on my presumed experience? Seems a bit arrogant. Did I say all backend problems are easier or that all C++ problems are harder? No, I merely stated why work on hard C++ problems for less pay when one can work on easier backend problems for more pay.

Wasn't even a good comparison either, would be like calling a Ferrari the same speed as a push-bike because you saw the former driving slowly alongside the latter.

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

#746

Post by WorldMaker »

ZephyrBlu wrote: post #719
WorldMaker wrote: post #587

Earlier quoted context omitted.

> The same can be said for dentists or architects or chemical engineers or whatever. - Dentists have dental hygienists that do the day-to-day grunt work so that dentists can focus on the real problems/exceptional cases (cavities, root canals, etc). - Architects build the plans, but they leave it to construction workers to actually construct the project. - Chemical engineers generally work with staffs of chemists and…

> Long story short: other professions clearly delineate between jobs that are (creative) problem solving and jobs that are more "grunt work" like Ikea-assembling CRUD apps. Why don't we? Is that even possible? It's difficult to separate grunt work and problem solving, because you often need similar levels of context to solve both. They also tend to intertwine a lot.

Of course it is possible. There's just currently more reasons for companies not to care and not to do it than to do it: Capital P Professions have education requirements and licensing/certification commitments. Capital P Professions have ethics bodies and mandate professional standards. Capital P Professions have professional societies that sometimes can organize industry wide negotiations (not quite to the same extent as Unions, but kin to it).

I don't think it is a technical problem keeping software from better sorting its various types of jobs by difficulty and types of problem solving. I think it's far more corporate politics and sociopolitics and a general lazy preference for the current status quo (because it works to company's favors in terms of job description opacity and keeping pay scales confused and under-valued and, uh, not having to worry about "quaint" "old timey" things like professional ethics investigations).

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

#747

Post by xedrac »

DeathArrow wrote: post #488
ayberk wrote: 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.

> Rust? It's much more painful to use than C++.

As someone who has used C++ professionally for two decades, I disagree. Rust's pain is superficial and all up front. C++ pain is death by a thousand paper cuts, especially if you have people on your team that aren't intimately familiar with its pitfalls and its more modern constructs. I don't plan to write a new C++ project ever again, unless there's some very compelling reason to do so. Rust is an absolute breath of fresh air.

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

#748

Post by trap_goes_hot »

filoleg wrote: post #423
trap_goes_hot wrote: post #412

Earlier quoted context omitted.

In real-life, engineers aren't just cogs in a wheel that are interchangeable, who can seek work in any organization. There is also a smaller number of people who can/want to do systems level/embedded programming.

Yes, I agree with you. Which is why I explained that despite the overall ratio of crappy/decent shops might be the same for all software work areas, embedded devs are the ones who get the short straw.

Not really, there are a small number of embedded devs competing for a small number of positions, so it all works out.

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

#749

Post by P5fRxh5kUvp2th »

gridspy wrote: post #706
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.

Could you tell me some differences that you see as significant between the C++ and C# type system? I can think of a few but they seem like compiler sugar only. For instance C# classes are treated as a &ClassName or std::shared (handled by reference transparently to the programmer). Otherwise I think that C, C++, C# have very very similar type systems. They don't have alternatives to dynamic dispatch (virtual / overri…

C++'s type system is both more consistent and more expressive.

GC'd languages fall into roughly 2 categories.

1. those that are pure but lack strong primitives (Python, Ruby, et al), 2. those that bifurcate their type system and treat primitives as a special case (Java, C#, et al).

2 is done as a compromise for performance since they'll start making guarantees such as preferring stack allocation. This is the primary difference between 1 & 2, what the language promises with these types (if they have them).

C# learned from Java but added "value types". So now understanding what a piece of code actually does requires you to know not just the type, but whether it's a value or reference. Create a tuple with a string and 2 ints and default construct it. You get (null, 0, 0). Now do it with MyTypeA, MyTypeB, and MyTypeC. You have no idea what that tuple will default construct to unless you know more about MyTypeA, MyTypeB, and MyTypeC.

Default equality is it's own bag of worms.

Whereas in C++ it's a lot simpler. It's value, a reference, or a pointer, and you know which it is by looking at the callsite. C++ has similar ambiguity with respect to function callsites with references vs pointers, but the convention in the C++ community is to pass by pointer if it's going to be mutated and by const reference if it is not.

IOW, the rules for the C++ type system are easier to learn and use effectively, and their semantics are easier to understand from the code.

The existence of typedef automatically makes it more expressive than C#.

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

#750

Post by astrange »

greyhair wrote: post #726
jjav wrote: post #644

Earlier quoted context omitted.

> And what can be used instead of C++? For most use cases Java is a better option. Very fast, without any of the pain. If you truly must not have a VM (rare), there's still C. Perhaps rust.

I think this is probably the most salient point. C/Rust then Java. I don't know why people hate on Java so much. And I think C lives fine along side Rust.

Java is based on Objective-C without any of the nice flexibility, doesn't have value types, has C-like numeric types except they're less flexible yet not any safer, and its culture thinks you organize code by putting it into 6+ layers of namespaces inside other namespaces.

My rule is that languages are good if they have value types, which explains why PHP is good.

Post reply on HN