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

111–120 of 285 posts

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

#111

Post by quietbritishjim »

pjmlp wrote: post #40
KayEss wrote: post #37

Part of the problem here is that OO sits nicely with references, but C++ (like C) is a value based language. This can be seen clearly in most of the design of the standard library -- it's all value semantics, and as such relatively simple and obvious to use (so long as you're not trying to cram OO into it). A line like if ( a == b ) In C++ is pretty obvious what it does. It'll always be a value comparison, and if a a…

Object Pascal, Eiffel, Ada, Mesa/Cedar, Oberon, Modula-2, Modula-3, Oberon, Oberon-2, Oberon07, Active Oberon, Component Pascal, Sather, Swift, D, Go, Rust are OO languages[1] and value based as well. [1] - As usual, there are many ways of doing OO, not just C++/Java style.

Object Pascal is definitely reference based, not value-based, at least not when I used it back in Delphi 7.

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

#112

Post by jcelerier »

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.

> Well largely on RaspberryPi kind of platforms, which aren't even even embedded systems

no, for instance Arduino uses C++ as a main language. And an arduino pico has 2.5kb of ram... that's firmly in the "embedded" scale of things.

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

#113

Post by poster123 »

nextos wrote: post #93
osullivj wrote: post #86

Earlier quoted context omitted.

Strongly agree on the inordinate number of features point. Which other mainstream OO language supports dynamic & static dispatch, single & multiple inheritance, interface inheritance via abstract classes, generic types and functions via templates, lambdas, type inference, and operator overloading? Roll that up with C compatibility, a 30 year history of evolution, and the complexity of commonly adopted libraries like…

I think that's spot on. I coded quite a lot of C++ in the early 2000s. Now I'm considering to jump onboard again. C++11 and successors are almost a different language. More importantly, for my niche I don't see anything that can readily replace C++. Rust has very little support for scientific computing. Julia is great, and will replace my high level statistical inference code, but it's not designed to let me design l…

If you are doing scientific computing, have you considered Fortran? The gfortran (GCC Fortran) compiler supports Fortran 2003, which has object-oriented features, and since Fortran 90 the language has had array operations and syntax similar to Matlab or Python with numpy.

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

#114

Post by bayindirh »

pjmlp wrote: post #106
bayindirh wrote: post #104

Earlier quoted context omitted.

> 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.

Well, I’m not very knowledgeable about Windows world, as I said before, I’m not using Windows for 15 years or so. So, my bad, sorry.

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

#115

Post by sempron64 »

klik99 wrote: post #100
api wrote: post #21

Earlier quoted context omitted.

C++ is a language with a lot of features, and not all of them should be used in every code base. It's quite possible to write simple, portable, and relatively clean C++ code if you use only those features you need. It's not the prettiest language by any stretch, but it's quite capable and fast and has excellent support across just about every platform.

I saw Stroustrup give a talk and he said exactly this - C++ is a toolbox of different paradigms that aren't meant to be combined. If you avoid frameworks that impose a particular paradigm and/or shield the parts of the codebase with different paradigms (for example when using Qt you really should have your "engine" running aside the Qt rather than embedding the code in the UI, extreme example I know but the same idea…

> If you avoid frameworks that impose a particular paradigm and/or shield the parts of the codebase with different paradigms...you'll have a grab bag of different approaches for the specific problem you're having for zero cost.

Avoiding frameworks and libraries which use unwanted language features and paradigms is very hard. Once these libraries are integrated, it is nearly impossible to restrict a team from using said features elsewhere in the project. Every C++ developer has pet features and features they hate and will never use, but these sets are rarely compatible between developers.

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

#116

Post by pjc50 »

WalterBright wrote: post #30
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…

> C++, on the other hand, seems to have been designed by compiler writers for their own enjoyment and/or job security. Being a C++ compiler writer (Zortech C++, Symantec C++, Digital Mars C++) I can assure you this is not true at all. As to why C++ is so complex, my opinion is it is because it was designed a long time ago, what is considered better practice in designing languages has moved on, and C++ is unwilling to…

> why does C++ still support

Stop right there! There is plenty of evidence that removing features from a language is fatal to adoption. Both Perl and Python have suffered from this.

Specifically for trigraphs (apart from these, EBCDIC support doesn't affect compilers on other systems) IBM have a vote and they voted not to remove it: https://isocpp.org/files/papers/N4210.pdf

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

#117

Post by gpderetta »

pjc50 wrote: post #116
WalterBright wrote: post #30

Earlier quoted context omitted.

> C++, on the other hand, seems to have been designed by compiler writers for their own enjoyment and/or job security. Being a C++ compiler writer (Zortech C++, Symantec C++, Digital Mars C++) I can assure you this is not true at all. As to why C++ is so complex, my opinion is it is because it was designed a long time ago, what is considered better practice in designing languages has moved on, and C++ is unwilling to…

> why does C++ still support Stop right there! There is plenty of evidence that removing features from a language is fatal to adoption. Both Perl and Python have suffered from this. Specifically for trigraphs (apart from these, EBCDIC support doesn't affect compilers on other systems) IBM have a vote and they voted not to remove it: https://isocpp.org/files/papers/N4210.pdf

IIRC they did lose the final vote though, and trigraphs is one of the few features ever removed from C++.

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

#118

Post by pjc50 »

Gibbon1 wrote: post #94
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.

I feel like embedded development should just avoid c++ and go with a managed languages. I was hopeful abut go, but they kinda wrecked it for embedded. The thing with embedded is you have two cases, hard real time and just don't care.

Embedded devs always care. Managed languages with non-deterministic GC will never be popular there.

What embedded devs end up needing are:

- ability to shove bits directly in and out of a particular memory address

- ability to write interrupt handlers with low and bounded latency (i.e. emit a different function pre/postamble)

- global mutable state

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

#119

Post by neo2006 »

The author is relating a personal experience As a former C++ dev I saw some wonderful code base written in Ç++ and some horrible code base, as any other language. The only specifity Ç++ have in my opinion is that some features have a high learning curve and are not necessary shared with other languages. Once you mastered Ç++ it's easy to move to other languages but it's hard to do the reverse path.

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

#120

Post by KayEss »

pjmlp wrote: post #40
KayEss wrote: post #37

Part of the problem here is that OO sits nicely with references, but C++ (like C) is a value based language. This can be seen clearly in most of the design of the standard library -- it's all value semantics, and as such relatively simple and obvious to use (so long as you're not trying to cram OO into it). A line like if ( a == b ) In C++ is pretty obvious what it does. It'll always be a value comparison, and if a a…

Object Pascal, Eiffel, Ada, Mesa/Cedar, Oberon, Modula-2, Modula-3, Oberon, Oberon-2, Oberon07, Active Oberon, Component Pascal, Sather, Swift, D, Go, Rust are OO languages[1] and value based as well. [1] - As usual, there are many ways of doing OO, not just C++/Java style.

There are, but they all have at their core an idea of an object which has identity, which values don't have. You can easily model objects in value languages, but sometimes it isn't so easy to do the other way around (like Java's strings -- Smalltalk had similar problems).
Post reply on HN