I have found all of this discussion relevant to my learning. Perhaps this has not been relevant to the original topic of C++ codebases, however it has given me further insight on why people choose the languages they choose. This thread has helped me place C++ into context.

Please leave this thread as is.

Thank you.

I think for most people probably a mixture of both ring true, but I think particularly for me when I think about it I would consider the former. Particularly in the context of a strong task specific 'codebase' for your project for making developing common use cases easier to maintain and develop usually with strong semantic overrides or hooks for specialized code. Particularly, for me at least, it wouldn't include the nuts and bolts of the memory model (although I supposed there may be such hooks involved.).

I'm glad that it was useful to you and am thankful that you said as much. :smile: I enjoy this kind of discussion because I find that I learn something every time (even, or perhaps especially, when there is disagreement) so it makes me happy that others feel the same.



(Long post alert! There's a TL;DR version at the end…)

I would probably think of things similarly: I tend to care about semantics, generally speaking, until I realize that there's a performance problem. Of course, after years of development etc., you develop natural tendencies toward decent solutions for problem types (like using sets rather than lists if you need to quickly test if a given item is present), so you write decently efficient code for the common case without thinking too hard. At this point, I prefer to Get Stuff Done (TM) which usually means working at the semantics level.

<side note>
Of course, as I said earlier, it often doesn't make sense to rewrite an entire large framework just because you happen to prefer another language; the amount of time spent in the rewriting will often dwarf the amount of time gained by using the new language. Besides, the advantage to dynamic languages comes in full force precisely when developing new stuff, because you can be more agile. If the task is already quite clear and generally solved, and you're doing basically incremental work, C++ is just fine, I think.
</side note>

But as you are Getting Stuff Done, you occasionally find that stuff is simply too slow and you need to drop down a level or two and get closer to the bytes being shuffled. This is what libraries like Numpy for Python are for: when you're doing very heavy, inner-loop-intensive math (like matrix multiplication) over very large inputs, you simply cannot afford to add unnecessary overhead. So you write the extension in C/C++ and link into it somehow from your application. If you're lucky, your language provides an FFI to speak directly to the C (most of them do); if you're unlucky you need to do inter-process communication or some other unpleasant thing (which adds overhead of its own, of course).

As somebody who learned to code "for real" with C and C++, and who has looked into compiler and VM implementation theory and practice, I sort of cannot help but think about what is going on under the hood, at least sometimes. But making all this explicit in my mind as I write code slows me down, plain and simple. I try to just internalize this knowledge so that expressing it becomes second-nature, and fix things later as I need to.

This is partly what I meant about C++ not being as concise, incidentally. You are forced into treating many things at a lower-level, or writing all the higher-level abstractions yourself. C++'s STL is a godsend compared to not having anything, but frankly it is still pretty icky compared to a very nice abstract container library. Iteration is a pain: you need to create all these dinky iterators, write three-part for loops, bla bla bla. (Contrast with the "for each var x in container y" notation you find in many scripting languages – or even Java.) This isn't to say that you can't write nicer abstractions in C++ – of course you can, and I have in many cases – but the point remains that you still have to do it, and every new project involves tracking down and plugging what amounts to plain boilerplate stuff to get to a comfortable level.

(Yes, the new C++ standard makes an awful lot of this an awful lot easier; iteration becomes much more concise with auto types. But this is only just starting to catch up to the ease that other languages have enjoyed for some time already.)

Something I found interesting is that when I started programming in Java, I felt revulsion at losing the low-level "control" that C++ gave me. I actually really hated the feeling for quite a while. Eventually, though, I realized that I was being kind of stupid and pig-headed, and holding on to what was essentially a useless artifact of a language I had learned before. I realized that writing code wasn't about shuffling bytes, it was about getting stuff done. The whole point of abstractions over time is to get further away from the mechanics of shuffling stuff around and to get closer to actually expressing what you mean. (This is a basically incontrovertible trend in computing, I think.) This moment was an epiphany of sorts, for me, as it taught me a great deal about what it meant to actually be productive. Of course, it's crucial to understand the lower-level stuff when you're optimizing performance. But one should also seek to liberate oneself from these lower-level details to the extent that one can. There will always be tension between them, at least until hardware becomes so powerful that the details simply don't matter anymore. Being a good programmer, IMHO, is learning to strike a balance between expressing concepts semantically and abstractly on the one hand, and with appropriate care to not ignore the low-level details on the other.

</essay>

TL;DR:
- I like to write code at a high-level when I can.
- A good framework to me is one that lets me express my ideas, first and foremost.
- Being able to shuffle bytes is important only for optimization.

That sounds like my story as well. In that order, even. After C/C++ it was Java I went to next. And I think the last line sums it up for me as well. Getting stuff done has become most important for me.