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

I learnt C++ in 2018 and have no regrets

vishnubharathi.codes

Post reply on HN
Print view View original

251–259 of 259 posts

Re: I learnt C++ in 2018 and have no regrets

#251

Post by mhh__ »

smallstepforman wrote: post #236
mhh__ wrote: post #185

Earlier quoted context omitted.

Only if you write unidiomatic ( Read crap) C++. In modern C++ it is very much possible to write fast and safe code, but the tradeoff is now put into the amount of stuff the developer needs to know to be productive (Which in my experience isn't as bad as people like to go on about on here/reddit, even if it still pretty shoddy)

> Only if you write unidiomatic (Read crap) C++. Thats a bit unfair. A recent headache for my C++ project was mixing audio buffers. The buffers are cached to avoid repeated reads, the channel count differs, the sample rate can differ, the output rate can differ, and mixing has gain limiters applied etc. Lots of buffers, lots of copying, lots of boundary cases (eg. sample #1 doesnt start until t=100ms, sample #2 ends…

I'm not entirely sure - only just learning audio programming atm, but the way to approach would be to encapsulate then use encapsulation and ranges/iterators.

Efficiency should be roughly the same, especially given that you can optimise loops (and other code) with just as much access.

Re: I learnt C++ in 2018 and have no regrets

#252

Post by mmjaa »

vedantroy wrote: post #83
mmjaa wrote: post #22

Earlier quoted context omitted.

Things I'd rather be doing: * C++ * Lua .. .. [a thousand other things] .. .. * Node * Javascript __ bottom of the pile.. The Node/JS ecosystem is such a steaming pile of garbage, I can honestly see with great clarity why people should be running from it back into the arms of C++[11,17] ..

You shouldn't make broad statements like that. In my personal experience, I have found Javascript much easier than C++. If I want to install a package, I can just do "npm install Now, I'm sure some people have an easier time with Makefiles, but I've found it even easier to get up and running in Javascript. Most of the tools in Javascript (create-react-app, Webpack, etc.) are very user friendly, making setup trivial.…

>It is best not to speak with such authority/certainty that C++ is easier to use than Javascript.

Unless of course you have 30+ years of experience in the software business, have kept abreast of all the latest and greatest distractions from proper software engineering practices, have built a few hundred examples of such personally, and have no desire to throw more garbage at the fiery pile. As is my personal case. Node/Javascript are the Visual Basic of the 21st Century - this doesn't mean people haven't been productive with them as technologies, just that they've been productive in spite of them.

Re: I learnt C++ in 2018 and have no regrets

#253

Post by phab »

lmm wrote: post #217
phab wrote: post #103

Earlier quoted context omitted.

Because legacy. Maybe one can't reorganise the source tree layout because to do so would break our custom tooling / integration systems / interface with proprietary vendor tools. We can't change version numbering schemes because our packages already exist 'in the wild' and can't be changed mid-sequence without causing both technical and user pain. Fundamentally: the codebase has worked perfectly well this way for the…

> Maybe one can't reorganise the source tree layout because to do so would break our custom tooling / integration systems / interface with proprietary vendor tools. That hardcodes the source layout? I don't buy that a tool that's being sold for money would do that (precisely because there's no standardization in the C++ world; any tool that wants to have more than 1 customer will have to support more than 1 directory…

> I don't buy that a tool that's being sold for money would do that

If you work with proprietory hardware (think FPGAs), if you want to use the hardware, you have to use proprietory vendor tools, whether you want to or not.

> if the tools are internal then by definition you have the ability to make changes to them.

This misses the point. Having the technical ability to modify the tool does not equal having the real-world-practicability, business-case-defendable ability to change the tool.

> Well, if you make adopting good tooling in C++ harder than switching to a language that already has good tooling

The point is that in a 20 year, n-million line codebase, neither is "easy", and the pragmatic solution is to do neither.

Re: I learnt C++ in 2018 and have no regrets

#254

Post by smileypete »

retro64 wrote: post #100
viach wrote: post #64

One can't just learn C++ in one year, imho.

I've been coding heavily in C++ for now over 2 decades, and when I interview someone I typically can get a pretty decent picture of within a general 3 - 5 year range of how long they've been coding based on the various details they gave when answering the questions about the language. And yes, of course someone could have 10 years experience, or the same experience for 10 years and never grow, but in general I found…

>you need the experience of watching your masterpiece crumble under its own weight (sometimes several times) or have the joy of hunting some obscure bug because you failed to recognize the trap you had set for yourself.

Very good point, but that's by no means unique to C++. Maybe that level of experience ;) in a related language, plus a good working knowledge of C++ would be acceptable?

Re: I learnt C++ in 2018 and have no regrets

#255

Post by lmm »

vasilipupkin wrote: post #133
lmm wrote: post #86

Earlier quoted context omitted.

Nonsense. C++'s template system behaves unlike any other language (things like SFINAE and the techniques that use it do not transfer), C++-style RAII is relatively unusual, I don't think any other language requires the programmer to think about virtual versus non-virtual inheritance, the C-derived sequence point rules are obscure and much looser than most languages' evaluation rules, the exception-safety rules are un…

well, that's just like, your opinion, man ( big lebowski reference for those too young to know ). The reason I disagree with you is because I have never met a C++ programmer who only knew C++ and couldn't easily do work in some other language, but of course plenty of people know other languages and can't do C++. Yes, SFINAE and RAII - you can go for many years of working in C++ without writing much code using either…

> I have never met a C++ programmer who only knew C++ and couldn't easily do work in some other language

Did they try the languages I mentioned? C++-trained programmers might be able to write lowest-common-denominator code in other languages but they'll struggle to write effective, idiomatic code in languages that make significant use of pattern matching/sum types or polymorphism, or rely on extensive use of higher-order functions.

> but of course plenty of people know other languages and can't do C++.

I'd agree that C++ programmers can usually write Java/Python, Java programmers can usually write Python but not C++, and Python programmers can usually write Java but not C++. But the implication is not that C++ is more general than Java or Python but just the opposite: programming in C++ requires learning a lot of C++-specific stuff that programmers in those other languages don't bother with.

Re: I learnt C++ in 2018 and have no regrets

#256

Post by HelloNurse »

lmm wrote: post #208
HelloNurse wrote: post #190

Earlier quoted context omitted.

All the complications you list derive from the peculiar C++ language design principle of ensuring high performance despite sophisticated abstractions; popular languages are simpler because they stop at basic abstractions (e.g. C and Forth) or because they trade performance for elegance (e.g. C# and to a higher degree Python and Smalltalk). C++ does more at a higher cost, and in recent standard updates the cost has be…

> popular languages are simpler because they stop at basic abstractions (e.g. C and Forth) or because they trade performance for elegance (e.g. C# and to a higher degree Python and Smalltalk). I'm not convinced. C++ offers some abstractions but is also missing some quite basic ones (no sum types, no true parametric polymorphism, polymorphic code can only be typechecked once fully expanded). ML-family languages offer…

ML-family functional languages, which you seem a fan of, also trade performance for elegance, with few fortunate exceptions in case elegance goes far enough to allow extreme optimizations that recover whole-program performance despite widespread inefficiency "in the small".

Significant bad parts of C++ have been deprecated or effectively replaced with something better; you just have to adopt the good way. For example, the new initializer syntax allows for simpler and saner rules about type conversions and lookup of constructors.

Re: I learnt C++ in 2018 and have no regrets

#257

Post by gdy »

lmm wrote: post #76
salawat wrote: post #61

Earlier quoted context omitted.

I do not understand the mentality of "opinionated" frameworks or tools being a good thing, and the trend toward said frameworks disturbs me greatly. What people call "opinionated" is nothing more than something being "architected". Someone has made a bunch of decisions for you that down the road you have no idea whether or not it will actually be good for you. Using these types of frameworks short-circuits the proces…

A framework that gives you all the choices that you have without it will suffer the inner-platform effect and end up becoming just as complicated to use as the thing it was supposed to help you with. The whole point of a framework is to make certain decisions for you, to make certain paths easier by closing off other possibilities. If you don't trust the framework to make good choices for you, you're better off not u…

Not quite.

https://en.m.wikipedia.org/wiki/Convention_over_configuratio...

Re: I learnt C++ in 2018 and have no regrets

#258

Post by lmm »

HelloNurse wrote: post #256
lmm wrote: post #208

Earlier quoted context omitted.

> popular languages are simpler because they stop at basic abstractions (e.g. C and Forth) or because they trade performance for elegance (e.g. C# and to a higher degree Python and Smalltalk). I'm not convinced. C++ offers some abstractions but is also missing some quite basic ones (no sum types, no true parametric polymorphism, polymorphic code can only be typechecked once fully expanded). ML-family languages offer…

ML-family functional languages, which you seem a fan of, also trade performance for elegance, with few fortunate exceptions in case elegance goes far enough to allow extreme optimizations that recover whole-program performance despite widespread inefficiency "in the small". Significant bad parts of C++ have been deprecated or effectively replaced with something better; you just have to adopt the good way. For example…

> ML-family functional languages, which you seem a fan of, also trade performance for elegance, with few fortunate exceptions in case elegance goes far enough to allow extreme optimizations that recover whole-program performance despite widespread inefficiency "in the small".

I'm not convinced. Small-scale heavily-optimized microbenchmarks show C++ as at most a single-digit multiple faster than e.g. Haskell. I wouldn't expect you to achieve even that much over Rust. And like I said, I've yet to see such a performance advantage to C++ in a real-world scenario - quite the opposite. It's not always a tradeoff - sometimes one thing really is better than another thing.

> Significant bad parts of C++ have been deprecated or effectively replaced with something better; you just have to adopt the good way.

And ensure that all your libraries/tools/coworkers have adopted the good way, which you have no way of enforcing; at best you have ad-hoc linters that flag up some (but not all) bad practices.

Re: I learnt C++ in 2018 and have no regrets

#259

Post by lmm »

AnimalMuppet wrote: post #212
lmm wrote: post #209

Earlier quoted context omitted.

Sure, but certain programming techniques become impractical without garbage collection, and a general purpose programmer would be expected to be familiar with those techniques. E.g. C++ programmers tend to just not learn graph-based models/techniques because they're not a practical way of working in C++.

Graph-based isn't practical in C++? Why not? I mean, yes, in C++ you have to clean up the memory yourself. That means that you need to know when to do so. That means that, for the graph nodes, you're probably doing some kind of reference counting, and it will be a bit fiddly to get right. If you do it in a base class, though, you'll only have to do it once. I wouldn't call that "impractical" at all. (I might call tha…

Fair point. I'd agree that a skilled generalist programmer should have no particular trouble doing graph-based work in C++. My experience is that monoglot-C++ programmers were less likely to learn those approaches because, just as if you need to do graph-based work then C++ is usually a less-good choice of language, if you need to use C++ then a graph-based model is usually a less-good way of solving a given problem (i.e. often the problem admits alternative approaches that are more easily accommodated in C++).
Post reply on HN