Re: Top 10 most common hard skills listed on resumes...

On 27/08/2024 01:47, Bart wrote:

On 27/08/2024 00:33, Janis Papanagnou wrote:

On 25.08.2024 20:24, Bart wrote:

On 25/08/2024 19:12, Bonita Montero wrote:

Am 25.08.2024 um 18:28 schrieb Michael S:
>

Define "abstraction".

>
This could have been looked up online (e.g. in a Wikipedia article).
>

>
OOP, functional programming, generic programming, exceptions.

>
(And there are yet more.)
>

>
That isn't surprising. The code you constantly post always uses the most
advanced features, uses every toy that is available, and the most
elaborate algorithms.

>
I'm not sure in what bubble you lived the past decades. The listed
abstraction examples date back to the 1960's. They were realized in
many programming languages,

 Perhaps not so much in the ones people used. Assembly? Fortran? Cobol? There have always been academic languages.
   including long existing ones as well as

many contemporary ones. I suggest to try to understand the concepts
if you want to reach the next experience level. :-)

 I sometimes use (and implement) such features in scripting code which has the support to use them effortlessly.
 I've rarely needed them for systems programming.
 

As a counterpoint, I /have/ seen at least some of these in systems programming - namely my own, and that of colleagues, customers and suppliers.  (Small-systems embedded and microcontroller programming is pretty much all "systems programming".)
But it is also fair to say that abstractions are less than you might see on "big" systems.  For systems programming, there is more concern about the efficiency of the results, leading to a different balance with respect to speed or ease of coding, maintainability, code re-use, etc.
In this field, C++ usage is on the way up, C usage has peaked and is going down, assembly is mostly dead (at least as a language for entire programs), and newcomers such as Rust and Micropython are emerging.
We very rarely see exceptions in this field, but OOP is certainly common now.  Classes with non-virtual inheritance are basically cost-free, and provide structure, safety, encapsulation and flexibility.  Virtual functions have overhead, but can be a solid alternative to call-backs or function pointers.  I use generic programming - templates - regularly, with inheritance and CRTP for compile-time polymorphism.  I've even used lambdas.
Yes, abstractions are, and always have been, vital to systems programming.  They have always been important to systems programming in C too, using the limited tools available in C ("void*" pointers, typedef "handle" types, struct pointers so that client code does not see the struct contents, etc.).  C++ gives you a lot more tools here, and lets you get more efficient results in the end (if you use it appropriately).
But you certainly can use a range of abstractions in C programming too. Every time you use an enumerated type instead of an int, it's an abstraction.  You can encapsulate your data and functions in structs. You can do generic coding with macros.  C++ makes it easier to get right, and harder to get wrong (while still compiling), but you can still do abstractions in C.
And yes, C++ gives more opportunities to write incomprehensible code than C, and the language suffers from having been built up gradually over time by adding features to a base (roughly C).  It is no more a "perfect" language than any other language.

My comments were in connection with their clunky and abstruse implementations in C++, and BM's habit of posting C++ code full of gratuitous uses of such features.
 

I don't think BM's posts are generally good or clear examples of uses of C++.  And I don't think continuously posting "C++ would be ten times easier" in c.l.c is helpful to anyone.