Hacker News Reader

Comment by sifoobar | Hacker News Reader

I went the other way, started writing C++ in 95 and digging into C properly around 2005.

Just make sure that the cure isn't worse than the disease. It's all to easy to slip into identifying with C++ because of the substantial effort it takes to master.

Should you, like me and many others; eventually find yourself spending more time and effort on taming C++, don't hesitate to let go. It's a tool.

View on HN

The solution is easy, managed languages for 90% of the code and C++ for the remaining no-excuses full throtle execution speed, while offering reasonable safety for arrays, strings, out parameters, enumerations, lifetimes.

Not everyone is running Solaris on an ADI enabled SPARC.

I have a somewhat different perspective to offer: C or C++ for components (effectively 90% of all code), a managed or scripted code (10%) for the glue.

The reason is that the modern C++ is perfectly suitable for high-level programming -- on par with Java, C# or Visual Basic. No "taming" is needed.

Taming is necessary, because regardless of what you and me think about modern C++, there is a large crowd that still writes C with C++ compiler with total disregard for any kind of security validation tools.

So the only way to prevent such security exploits is by preventing copy-paste compatibility with C, which C++ sadly cannot do without breaking backwards compatibility.

You can see this happening across all desktop and mobile oriented OSes, where both C and C++ have been reduced to high performace low level OS layers, with userspace migrating to something else.

Microsoft is the only vendor left on OSes for the consumer space that still cares enough to support C++ on their UI toolkits.

Apple supports Objective-C, which is arguably just as bad as C++.

It does, due to its NeXTSTEP legacy, but the roadmap is quite clear.

"Swift is intended as a replacement for C-based languages (C, C++, and Objective-C)."

Taken from https://swift.org/about/

"Swift is a successor to both the C and Objective-C languages."

Taken from https://developer.apple.com/swift/

I would be very surprised if Apple’s frameworks ended up becoming Swift-only any time in the next decade. While Swift is the spiritual sucessor to Objective-C, there is far too much Objective-C already written that would be costly to obsolete, even if Swift had the facilities to do everything Objective-C can (and, as I’m sure you’re aware, it is not at that point yet).

Sure, but that will eventually happen, even if they do just a couple of components per OS release.

Launchd, dock were announced as rewritten at WWDC 2017, the new XCode build system and instrumentation at WWDC 2018, and it will continue little by little.

Naturally it won't happen overnight, but Apple isn't known to endure Python 2/3 scenarios for that long.

Those are not frameworks, those are apps that ship as part of the system. Apple has not and seemingly will not deprecate Objective-C for third party developers. They haven’t even rewritten any significant code in Swift, IIRC. Maybe parts of launchd?

Timac analysed several MacOS and iOS versions for swift usage, and its growing through the system surprisingly rapidly for a language awaiting a stable ABI. Here’s the most recent analysis, which also links to others: https://blog.timac.org/2018/0924-state-of-swift-ios12/

Yup, I’ve read those and that’s what I based my statement on. Apple doesn’t seem to have rewritten any code in Swift “just for the sake of it”; they have slowly introduced it the in places they could to add new features.

They need to start somewhere.

At WWDC 2017 they mentioned that launchd was fully ported. The video is available.

This is the "right" approach - speaking from experience after having tried both ways (10-90 vs 90-10). The general structure is that your application is built as a DAG with the nodes representing C++ functions (not methods on classes), with edges representing arbitrary datastructures (not objects), with the graph being constructed and hooked up in python and executed using a library like TBB

> C++ is perfectly suitable for high-level programming -- on par with Java, C# or Visual Basic. No "taming" is needed.

This is completely untrue.

This just doesn't work for making fast software in my experience. It's very rare that 90% of your execution time is in 10% of your code because that code is obvious low hanging fruit and will have already been optimised.

Selective optimisation of hot code will always lead to execution time being spread evenly through your code.

My experience replacing software 100% written in C++ by a mix of JVM/.NET + C++ shows otherwise.

Most of the time, the C++ help isn't even necessary anymore, unless the systems were doing some GPGPU stuff, real time audio or high performance graphics.

That's just because Java and C# (or whatever) are fast languages. C++ is only a little faster. Try it with Python or Ruby.

From my point of view Python and Ruby are only worthy of shell scripts, and scenarios where performance isn't even part of the requirements list.

Using them in scenarios where performance matters is the typical everything looks like a nail.

Feel free to disagree, my experience during the early 2000 with Tcl has taught me to never use languages without native support for JIT/AOT toolchains ever again when performance matters.

Anything related to distributed computing, performance does matter.

I prefer embedding scripting languages [0] in C. Which is another path to the same kind of compromise, with the added advantage of controlling the world for the scripting language.

[0] https://gitlab.com/sifoo/snigl

I work in both C and C++ code bases so I get to dive deep into both sets. Only find solutions and language idioms when an actual problem arises.

Reply on news.ycombinator.com