9 ms·
In my experience, I have to qualify I program "ANSI C", otherwise people assume that I am really talking about C++. I list ANSI C and no C++ in my professional
by lmilcin 5y ago
In my experience, I have to qualify I program "ANSI C", otherwise people assume that I am really talking about C++.
I list ANSI C and no C++ in my professional experience and yet I have had a bunch of people call me to seriously talk about me helping in their C++ project. Maybe I shouldn't fault recruiters too much, though they should probably understand what language they are hiring for. But some of these guys were technical managers.
It kinda seems to me a lot of technical world assumes C died and C++ is newer and better version of it, which obviously is wrong way to look at it. These are separate languages that for unfortunate historical reasons share a lot of tooling and language syntax.
- harry8 5y agoIf you can program C well, C++ isn't going to be too much of a problem for you. The reverse is not necessarily true. If I were hiring on a C++ project I'd definitely want to talk to someone who is genuinely good at C - they may not want to talk of course.
- lmilcin 5y agoI have been programming professionally for over 20 years in languages ranging from assembly to Lisp and everything inbetween and applications from embedded to Linux kernel, to OS, to backend systems to algorithmic trading. That I don't touch C++ is my choice because after years of development I decided that most of all I value simple and readable code, working with people who like to write simple and readable code or helping projects write simple and readable code. And C++ and community is, in my opinion, anything but about simplicity and readability. For some reason I do not fully understand, C++ projects I have participated are a contest of who can think of more convoluted C++ construct that nobody ever will be able to understand and C++ seem to be absolutely perfect platform for it. Even if I am able to understand it (which I frequently do not), I just can't rationalize putting crap like that in a project that is expected to then be grokked and modified by new developers. I have tried restricting the types of constructs and C++ syntax used in projects in the past but this inevitably causes flamewars and lots of discussions about why these rules were instituted and whether they are necessary. I am sick and tired of explaining the value that exists in moderation and restriction.
- harry8 5y agoyep. That's a reasonable view. Hence: >> they may not want to talk of course. C++ as an indicator of dud project, poor team and programmer lack of taste is valid. It isn't necessarily always true but there's no reason for you to care if you've gone that way and it worked.
- wruza 5y agoNo upvote can tell how much I relate to this. The only way to get a good maintainable C++ code is to hire very mediocre programmers whose “C++” really means “Qt with some shared ptrs”. The reason (I believe) is that complex things are like hard drugs for smart people. Instead of solving business tasks, which honestly are often just boring, they long for an art in programming. In C++ this inevitably leads to solving non-existing problems in a most complex, efficient and unstable way that requires a hard set of prerequisites to work, and then these break. You can see it on forums. C, python, js folks discuss libraries, idioms and best practices, and C++ folks discuss a turing completeness of template metaprogramming and the most obscure ways to pass results up the callstack without copying 8 to 24 bytes. Almost no one I talked with there actually worked for someone who actually needed these microscopic gains all over the code. Or who understood what they do beyond “it’s complex and expensive, but in the end they deliver the results we need, so that’s justified”.
- lmilcin 5y ago> The reason (I believe) is that complex things are like hard drugs for smart people. That is the golden explanation I kind of understood internally but never formulated consciously. Yes, that's exactly it. It takes willpower to be able to refrain from all those shiny toys. You see one and you are immediately imagining what you could use it for. Writing C is like using typewriter or distraction-free editor, putting away your phone and disconnecting the Internet. Just imagine your team is told to write all their pieces of code in any language they want. Writing C is like telling the team: sorry, you can't do that. We know all those languages exist and they even may have fancy features that could improve your work, but for reasons of sanity we want you to stay programming single language.
- praptak 5y ago> If you can program C well, C++ isn't going to be too much of a problem for you. I only agree that understanding C helps somewhat, e.g. by avoiding the traps of not thinking hard about the underlying memory model. But it won't help you with template metaprogramming or how exceptions can break your supposedly memory-safe code: https://herbsutter.com/gotw/_102/ https://herbsutter.com/gotw/_102/
- lmilcin 5y agoAnd that's why I am not claiming I know C++. Don't get me wrong, I can read the code, debug it and correct it. But in C++ being able to read the code and understanding consequences of every single line of it are completely different things. There is just so much magic involved that no one ever can claim they fully know C++ and if they do I can safely and provably call them liars and find something they will not be able to explain.
- praptak 5y agoMy main problem with C++ is not that there's a lot to know (although this too). It's something else: even if you know C++ very well, you need a lot of external research to understand a snippet of code. A single line of C++ can trigger a lot of mechanisms which change the semantics. Overloaded operators, custom allocation, template overloads, copy vs reference - all of this depending on a huge graph of header files.
- user-the-name 5y agoAbsolutely not. I program C well - very well, I'd even brag - and I've used C++ long ago as well. I've programmed in many other languages besides. I am not adverse to picking up new languages. But when I look at a modern C++ project, I get instantly overwhelmed. There is so much going on. So many weird features interacting with each other. So much you have to be aware of and familiar with. It is massively painful to work with. I would not be comfortable with working any kind of C++ codebase without years of experience with this absolute beast of a language.
- varajelle 5y ago> C died and C++ is newer and better version of it That's kind of my opinion. C didn't die for legacy reasons, but starting new project in C seems a nonsense to me. C++ just has so many features that makes the development of programs and libraries easier, for almost no extra costs.
- harry8 5y agoThis is a perfectly valid and fine opinion for many new projects. Possibly even most. The point were I dismiss this sort of thing is where it is "all" new projects.
- Y_Y 5y agoMaybe you're just an unusually talented coder, but I pay dearly for every little extra bit of C++ my code touches. It's often worth it, but never a freebie.
- mettamage 5y agoI'm distinguishing between a hobby perspective and a professional perspective. IMO that really depends on the project size and goal of the project. I've written a C++ project of about 1000 lines (algobot trader with some optimized data structures in keeping the order book consistent). I've written it in VS Code, used a GUI debugger and I haven't really paid for anything. Meanwhile, I have this friend that programs so much C++ that his mantra is "in C++ assume all tools are broken." When I hear his horror stories, oh dear! Heisenbugs come by every 2 to 3 months. So for small projects that aren't touching the lower OS/systems level parts, you're not paying any extra costs. However, the deeper and further you go, I'd fully agree.
- fnord123 5y agoAre you sure you're not hitting heisenbugs every 2-3 months?
- lmilcin 5y agoThe issue is for small project you don't really require C++ over C. Because supposedly the price you pay for abstractions has better returns the larger the application is (and that is generally true). My largest C project was 60k lines of code. The code was very, very dense. It had a lot of functionality that had to be packed to as little code as possible (due to memory limitation). It had things like transactional log-based database working in very small, static amount of memory, point in time recovery (so if the application failed it could restore itself to a number of possible checkpoints before the failure), parsers for various protocols (BER-TLV, for example), a lot of cryptography and custom cryptographic protocols, a GUI framework for a small monochromatic screen and keypad, drivers for a bunch of devices (thermal printer, external pinpad, etc.), SSL, a lot of business logic, state machines for talking to a network host, etc.