I did my time in C++, had fun, learnt plenty, then got an offer to do some python with a way better salary. At some point company have to seriously up their offer if they want me to care about ABI breakage, weird bug cause by undefined behavior, and the usual 100k loc of legacy code with 10+MB sized object and no coherent memory ownership.
As I see it, Carbon have in its explicit goals to fix both the syntax issue and the major ABI retrocompatibility issue, while herb approach is to just deal with the syntax: Sure it is better than nothing, but I'm willing to bet that this will not convince most of people that saw their idea being killed by the committee on the ABI altar.
That song was so good at making what generally reads like a healthy lifestyle seem hollow and pointless. I love it, even as I question whether its effect on my teenaged self was a good one, or maybe just fueled my neuroticism. It makes me look at life a little bit more like an opportunity to be creative and make risky, weird choices and less like a continuous process of self improvement, for better or worse.
I'm currently living in a country with an healthy approach on work/life balance, seeing the appalling situation in the us always made me defiant to move there. I hope this awakening on the issue will be picked up by politics and will lead to better regulation.
I would like to point out that yosefk fqa is a bit old now, and while some problems mentioned are still relevant, tools and conformity across up to date compilers are magnitudes better now.
Also keep in mind that Mozilla is researching better rendering methods through the Quantum project. The potential boost will be huge -- CSS styling and compositing will be faster, JS code that interacts with the DOM will be faster, etc.
I'm very excited about Quantum CSS and Quantum DOM landing.
Welcome back to the 80's, where C++ used to play with macro to make templates and inheritance was only a basic compiler trick.
I can only emphasizes the need to move to real C++ if you want to use C++ idioms, to do it safely and performances wise: here you just opened the gate of Macro error's hell which will be more horrible than anything the C++ could throw at you.
The code in the article is just a plaything, a C programmer wouldn't use any of that and wouldn't use C++ as a starting point for their C implementation. Don't let it reflect negatively on C.
In what way? I have seen several examples of C programs that implemented a form of interfaces using structs of function pointers. The GIMP code base does it, as does the Linux kernel's Virtual File System layer. This is a good overview: https://www.kernel.org/doc/Documentation/filesystems/vfs.txt
Mind this is only the simplest functions and thing can already go wild if you apply classic bad C++ coding practices, like cascade inheritance or god object.
Add to that, you will (oh yes, you will, at least once) make type errors with macros, and you will fail to maintain all the class constructors and virtual functions.
