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

C++ and the Culture of Complexity (2013)

blog.greaterthanzero.com

Post reply on HN
Print view View original

101–110 of 285 posts

Re: C++ and the Culture of Complexity (2013)

#101

Post by gpderetta »

jcelerier wrote: post #92
WalterBright wrote: post #45

Earlier quoted context omitted.

IBM can support it as an extension in their C++ compiler. No need to burden the rest of the community with it. It's not like C++ compiler vendors are shy about adding extensions :-) Despite C++ supporting EBCDIC, I seriously doubt the overwhelming majority of string processing C++ code will work with EBCDIC anyway, because the programmers probably never heard of it, let alone tested the software with it.

> No need to burden the rest of the community with it. yeah, the problem is when IBM goes with big checks to national standard bodies and complains "muuuuhh we won't be able to assure that the systems we sold you in 1970 will still work in 20 years if the C++ standard removes support for EBCDIC" and then these standard bodies write strongly-worded letters to the ISO commitee: http://www.open-std.org/jtc1/sc22/wg21/do…

I think that implying bribery here is dishonest. 6/7th of the authors of the paper are IBM employees and they are just voting according to their employer wills.

Re: C++ and the Culture of Complexity (2013)

#102

Post by lallysingh »

AboutTheWhisles wrote: post #13
narayanbs wrote: post #10

Earlier quoted context omitted.

Either you are confusing verbosity with complexity or you have never actually written a "complex" software in C++. There are too many things to think about while writing a piece of code in C++, most often than not, you are bound to get things wrong.

I've written and shipped plenty of software with modern C++. Ownership and move semantics mean that after writing a few helper and utility functions, things go pretty smoothly. The most concise and direct software I've written has all been in C++. I can organize and transform data directly instead of jumping through hoops or suffering from enormous amounts of overhead and indirection in a scripting language. Not to m…

There are plenty of directly compiled languages with good performance, linking to C APIs, and higher level abstractions.

Rust, Haskell, Go, and Erlang come to mind.

Re: C++ and the Culture of Complexity (2013)

#103

Post by kamaal »

virmundi wrote: post #14
foo101 wrote: post #7

Earlier quoted context omitted.

C++ is a complex language no doubt. But software written in C++ need not be complex. Java, on the other hand, is a simple language. But the kind of unnecessary complexity I have seen in Java-land (EJBs, Spring, etc.) has no parallel in the C++-land. So going by your argument, I would choose C++ over Java to avoid the complexity jump, then profile the app, and if any part's too slow, improve that again in C++.

I find Spring to be great. I grant that I've used it since 2.0, but really it does everything quickly, easily, and is well documented. Especially with Spring Boot. I'm writing a core service in Go because Java 9 broke a Maven plug-in (that I don't need now). Holy crap is it painful. I know that I'm learning, but it's hard to layer the application. Most tutorials show passing the database connection through all of the…

>>Really, I don't think that Java brings that much complexity now. It use to.

That's because these days you don't learn Java, you learn things that manage Java madness. Like Eclipse, IntelliJ or Maven etc.

You don't really do much using Java these days. You do things using tools, which write bulk of the Java code. In essence learning Java today is learning Java ecosystem tools.

>>But you can get a new developer up and running in Java within 2 months.

That's because it doesn't much time to learn the IntelliJ UI :)

>>Java is like a 10-speed Schwinn. Fast, moderately complex, but easily understood when kept within the wheelhouse of Spring + Core Language.

This is true for most languages today. Java owes much of its success and power to two things. Libraries and Marketing. Marketing money is gone as Oracle doesn't spend a dime on anything that doesn't bring in two in return. And other language ecosystems have caught up with libraries.

So you could use anything instead of Java and it would all still work, in fact in most shops it already does. Haven't heard any major project being started in Java in most places in a long time.

Legacy projects will carry the Java carcass for a lot of time. But If you want to work on projects worth working, Java isn't the language you should be with right now.

Re: C++ and the Culture of Complexity (2013)

#104

Post by bayindirh »

pjmlp wrote: post #84
bayindirh wrote: post #52

Earlier quoted context omitted.

This is not an apples to apples comparison. I've given examples from runtime, not from development time. OTOH, refactoring in C++ is not hard, at least from my experience. With some knowledge of the language, everyone can write reasonably bug-free C++ (or any other language) application in one go. Compilation in C++ is a different story. C# is not native. It's converted to CLI (was that the name, I don't use Win32 fo…

C# is surely native as well. It can be compiled to native code just like C++ via NGEN, .NET Native, CoreRT, IL2CPP, Bartok, Mono AOT. Or if you prefer, C++ is not native. It's converted to LLVM bitcode, OS/400 TIMI, WASM,.... Lets not mix languages with implementations.

> It can be compiled to native code...

In that sense, you are absolutely right.

However, for simplicity I only thought about the out of the box experience, or by the de-facto implementation of the said languages, since it’s the most popular usage scenario as well.

Re: C++ and the Culture of Complexity (2013)

#105

Post by kamaal »

pjmlp wrote: post #80
cageface wrote: post #76

Earlier quoted context omitted.

C++ is a mess but it's one of the few languages that gives you low-level control of memory and fast code with zero or near zero cost abstractions. So for a certain class of application it's still the best choice. Music software, for example, is pretty much exclusively written in C++. I don't enjoy C++ the language very much but you can build some very cool things with it. Personally I'm hoping Rust displaces it from…

Very very slowly. Only now embedded development is starting to accept C++, and C still rules there anyway. Which means it took about 20 years to reach this point. And still Rust will need to go through the same certification processes that C, C++, Ada and Java enjoy for such scenarios.

>>Only now embedded development is starting to accept C++

Well largely on RaspberryPi kind of platforms, which aren't even even embedded systems. More like miniaturized desktops.

Then there is just C and only C. C dominance there isn't going to be replaced anytime soon, if ever.

Re: C++ and the Culture of Complexity (2013)

#106

Post by pjmlp »

bayindirh wrote: post #104
pjmlp wrote: post #84

Earlier quoted context omitted.

C# is surely native as well. It can be compiled to native code just like C++ via NGEN, .NET Native, CoreRT, IL2CPP, Bartok, Mono AOT. Or if you prefer, C++ is not native. It's converted to LLVM bitcode, OS/400 TIMI, WASM,.... Lets not mix languages with implementations.

> It can be compiled to native code... In that sense, you are absolutely right. However, for simplicity I only thought about the out of the box experience, or by the de-facto implementation of the said languages, since it’s the most popular usage scenario as well.

Well, since Windows 8 .NET store apps don't support JIT, they only run AOT compiled to native.

And NGEN is a standard component of the .NET SDK since the beta days.

So AOT compilation has been part of the default tooling since ever.

Re: C++ and the Culture of Complexity (2013)

#107

Post by bjorn2k »

jVinc wrote: post #91
IshKebab wrote: post #63

Earlier quoted context omitted.

Yeah by keeping backwards compatibility they avoided something like the Python 2/3 mess which I would say is worth the effort and cruft.

Looking at the current programming language space, it honestly doesn't look like the Python 2/3 issue hit them that hard in the long run. And while it wasn't popular it might have been the right way forwards. Python is one of if not the most rapidly growing language. In large part due to the data-science movement which for anyone I've talked to is based on Python 3. I still occasionally talk to 2.7 proponents, who ex…

I also would like to drop backwards compatibility in favor for a clean simple language, because I happen to write completely new functionality. If you ask yourself the question: "Do I want to break backwards compatibility in 2020?", then that same question could have been asked in 2003. Which would mean that the language lost traction (at least that is my opinion), because I could not recompile my old code and therefore I keep using the old before C++2003 compiler. So, the reason that it is popular, _is_ because it takes care of installed base and does not break existing code (or at least minimizes breakage).

Re: C++ and the Culture of Complexity (2013)

#108

Post by pjmlp »

kamaal wrote: post #105
pjmlp wrote: post #80

Earlier quoted context omitted.

Very very slowly. Only now embedded development is starting to accept C++, and C still rules there anyway. Which means it took about 20 years to reach this point. And still Rust will need to go through the same certification processes that C, C++, Ada and Java enjoy for such scenarios.

>>Only now embedded development is starting to accept C++ Well largely on RaspberryPi kind of platforms, which aren't even even embedded systems. More like miniaturized desktops. Then there is just C and only C. C dominance there isn't going to be replaced anytime soon, if ever.

During 2017, BMW among other car companies, and Sony have migrated from C to C++ as their main language for embedded development.

https://archive.fosdem.org/2017/schedule/event/succes_failur...

https://www.autosar.org/

"Developing Audio Products with Cortex-M3/NuttX/C++11"

https://www.youtube.com/watch?v=T8fLjWyI5nI

Unless you consider their devices Raspberry Pi kind of platforms

Of course with companies like Microchip still focusing on Assembly and C89, C is going to stay around for a very long time

What is done in C and macros, can be safer done with C++ and constexpr templates and better optimized, problem is to change the culture of those companies.

Re: C++ and the Culture of Complexity (2013)

#109

Post by stinos »

oselhn wrote: post #89
notacoward wrote: post #16

The bullet list near the end closely matches my own experience with C++. There's an inordinate number of features creating an even worse profusion of edge cases where they interact. Then the "solutions" for those edge cases usually add even more complexity. Worse, they force programmers to coddle their compilers. The ratio between what a C++ compiler will accept and what it will produce sane code for is huge . That's…

I agree that C++ is bad but I actually find C much worse for projects bigger than a few thousands of lines. Reasons for this: * lack of namespaces - all names with long prefix look the same to me * just text based macros * no generics * error handling usually based on int constants and output function parameters - in big projects is hard to use them consistently without any type checking * no polymorphism * ton of un…

Never really had a problems with the lack of namespaces actually (and not due to insanely prefixed names), if everything is properly seperated there just doesn't seem to be enough chances for name clashes: headers should have only things which really are publicly needed, sources should only include headers they need, and one of the design targets should be high cohesion/low coupling. Though it probably depends on the project.

Re: C++ and the Culture of Complexity (2013)

#110

Post by stochastic_monk »

banachtarski wrote: post #57
repsilat wrote: post #28

Earlier quoted context omitted.

Disclaimer: I don't program in C++ day to day, so maybe my experience is atypical. Moves and rvalue references (and whatever a PR-value is) and even RVO scare me. They make me want to pass pointers around, because at least I know for sure what'll happen then. (And, funnily enough, C++ seems worse than dynamic languages for this -- more magic around function calls and returns than C or Python or JavaScript.)

They really aren't that bad... in fact, they're pretty useful. Source: your everyday C++ programmer

They’re great, really. Yes, it takes effort to master, but then you can generate faster, safer, generic code with much less effort.

Source: Another everyday C++ programmer. There are dozens of us. Dozens!

Post reply on HN