I think there's a "sweet spot" in complexity (at least for software): too complex gets rejected, but being too simple lacks traction. I think artifacts like C++ memetically infect the brain better than a more elegant PL might, exactly because they require you to think about them a lot, but you can still get things done and not be (totally) overwhelmed.
C++ and the Culture of Complexity (2013)
181–190 of 285 posts
Re: C++ and the Culture of Complexity (2013)
#182Earlier quoted context omitted.
> Being a C++ compiler writer (Zortech C++, Symantec C++, Digital Mars C++) I can assure you this is not true at all. Yeah, after I wrote that I realized it wasn't quite right. C++ is designed by compiler-writer wannabes . Architecture astronauts[1] on standards committees. They think they understand how compilers should work, and that adding support for this or that should be easy. "You just need to..." is their fav…
You can assure us based on what? If you have insider knowledge or particular credentials please share. So far it looks like you're ranting.
http://www.walterbright.com/
> Walter Bright is the creator and first implementer of the D programming language and has implemented compilers for several other languages. He's an expert in all areas of compiler technology, including front ends, optimizers, code generation, interpreter engines and runtime libraries. Walter regularly writes articles about compilers and programming, is known for engaging and informative presentations, and provides training in compiler development techniques. Many are surprised to discover that Walter is also the creator of the wargame Empire, which is still popular today over 30 years after its debut.
Granted it's his own site, but uh, seems legit..?
Re: C++ and the Culture of Complexity (2013)
#183I like the fact that in C++, the line
x = y;
behaves the same if the types are int and vector (unlike e.g. Java and Python).
Re: C++ and the Culture of Complexity (2013)
#184I think it depends on where you sit on the stack. A library can take a lot of the complexity away from the higher levels in C++ code. The user code can look fluent and understandable. On the implementation side of the library being used(depending on where it sits in abstraction) is where some ugly complexity shows. But this also generally reflects the competence of the authors.
On the other hand, it's hard to grab a half dozen C++ libraries off the shelf and just use them together without issues.
Re: C++ and the Culture of Complexity (2013)
#185C++ is not more complex that its competitors like Haskell or Rust.
Having used c++ for many years, this does not come across as a ringing endorsement for looking into Haskell or Rust. I'm quite happy with my current gig using Go. Looking back, the culture of complexity surrounding c++ is obvious, but talking with my peers who have only ever done c++ - it's like they have Stockholm Syndrome.
Any language (or tool for that matter) that you have to invest heavily in, and use for a while will produce a symptoms of "Stockholm Syndrome". Moreover, once you are hard pushed to switch from it to something else, withdrawal symptoms are quite pronounced too.
Go has its own share of idiosyncrasies, and it drives me nuts sometimes even more than C++ did, but these bursts of mental grind are less common and much shorter in comparison :). The arcane complexity of C++ (and tooling around it) is something that I don't miss at all.
Re: C++ and the Culture of Complexity (2013)
#186Earlier 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 used C++ for embedded CPU 68332 (25 MHz CPU) with 4MB of SRAM in ~1996 for DNA sequencer machine. ~100 + classes, single inheritance, 1,2, 3 Axis motor controls, CCD Camera, Laser, serial com channel, scripting engines, etc. No template, no virtual functions. Worked very well at that time. The compiler setup at that time is AT&T cfront generate C from C++ code ran in Mac and embedded C cross compiler generated the…
Very interesting, thanks.
I got introduced to C++ via Turbo C++ 1.0 for MS-DOS, in 1993.
So if it was good enough for 640 KB max, with 64KB executables, it shouldn't be an issue in most micro-controllers, but the biggest issue is the existing dev culture.
Re: C++ and the Culture of Complexity (2013)
#187Earlier quoted context omitted.
What exactly do you mean by "a complex compile-time static typing system"? I'm not familiar with Rust, but C++'s and Haskell's typing systems don't look very similar, or even of similar complexity. I do agree there's an inherent complexity in the problem domain. It's just that some languages are more helpful than others in dealing with this complexity :) PS: my own bias: Haskell's seems both easier (in general) and m…
> C++'s and Haskell's typing systems don't look very similar, or even of similar complexity. yet they are. The difference between the Haskell type system and the C++ type system is that generic constraints on types are explicitely specified with typeclasses in Haskell, while they are implicitely specified with templates in C++ (though this changes in C++20 with concepts). To make a "conceptual leap" beyond the C++ an…
That is not the only difference between both type systems. It's very different to use one or the other. Especially in practice.
Re: C++ and the Culture of Complexity (2013)
#188I think it depends on where you sit on the stack. A library can take a lot of the complexity away from the higher levels in C++ code. The user code can look fluent and understandable. On the implementation side of the library being used(depending on where it sits in abstraction) is where some ugly complexity shows. But this also generally reflects the competence of the authors.
On the other hand, it's hard to grab a half dozen C++ libraries off the shelf and just use them together without issues.
True. That is getting better though and lots of people are putting time into solving that. It's tricky because no one is talking about the same thing either. Like my project structure isn't your's.
It's not byte code so distributing binaries is a crappy problem too. I am of the mind that a dependency system above the build system(s) is probably the best bet. Not as low level as binary interface, but I need libary X >= version n.m.o...
Re: C++ and the Culture of Complexity (2013)
#189Earlier quoted context omitted.
THIS is the reason IMO too. C++ has taken on the very difficult task of remaining broadly compatible with C and with legacy features while at the same time has continuously evolved over the decades, incorporating whatever was the state of the art at that time, without new features breaking old code. That is not an easy task without increasing complexity.
The book "Design and Evolution of C++" is quite interesting in that regard. For all its warts, C++ only got adopted inside AT&T and later by almost every C compiler vendor, because it just fitted on their existing toolchains. Even lack of modules is related to that, C++ object files needed to look just like C ones. Now that C++ is grown up and can live on its own, it needs to pay for the crazy days of its parties goi…
>The book "Design and Evolution of C++" is quite interesting in that regard.
I found that book very interesting in many regards. I had bought and read it several years ago (out of interest, though I have not worked on C++ professionally).
Stroustrup goes into a lot of details about the reasons for many design decisions in the language. While I'm aware that C++ has some issues, I was really impressed by the level of thought etc., that he shows in that book, when he talks about all the reasons for doing various things the way he did them.
Re: C++ and the Culture of Complexity (2013)
#190Earlier 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…
What are Scala's memory issues?