[Jack-Devel] C++ and the code monkey business (Was: major change in jack1 MIDI handling)

Christian Schoenebeck <[hidden]> writes:

> On Saturday 12 October 2013 18:41:11 Nedko Arnaudov wrote:
>> I for sure would prefer a plain C version (with "proper" object oriented
>> design, of course). With C++ silly attempts to mature/catch/improve, I
>> doubt it will be any stable and prevailing "proper" C++ approach before
>> 2020, maybe even later.
>
> You will never like it, even not after 2030. The C++ language is only 
> extended, but existing parts of the language are not revised, due to backward 
> compatibility reasons. The C++ committee is very strict on that policy. What 
> you are asking for is a new language.

Well, this is getting off-topic (so i changed it) and maybe a bit
trollish but still....

"If you like C++, you don’t know C++. There’s a mutual exclusion going
on here, and I’ve yet to see a counter-example other than possibly a few
of the members of the standards committee."

You cannot like or dislike something you dont know, you can only pretend
you do... and look silly. You can dislike though, a simple fact that the
latest C++ standard is a huge document. After reading it (or more
probably, an overview of it), some may feel that other smart people are
taking care of former people's programs by providing some "proper"
tools/frameworks and design patterns. Unfortunately, this is a fallacy
that plagued our software world since some time. The idea that you can
use code monkeys to produce software that the marketing machine can
promote as useful, resulted in a ton of bloat we are surounded with
today. The C++ bloat by itself is not guarantee for bloated software,
but it for sure pushes the code monkey business further. As for the
tools and workflows that lead to producing quality software, you can
have them with any language. You cannot really teach monkeys to use the
tools properly though, because they don't understand them
profoundly. The code monkey business is the mindset that generally makes
C++ unsuitable for creating quality software. IMO instead of hoping for
smart frameworks (subject to marketing hype and similar shit), people
who have desire to produce quality programs, should invest more time in
understanding the inner working of the software systems they create. And
create more tests, use static analyzers, profilers and similar. After
all, this is the point of the free software, there is no artificially
introduced lack of resource (copyright resitrctions) that leads to
(healthy?) competition and good(?) result. There is no market push
(right?) for delivering the software in time and sacrificing code
quality. This allows the open source software model to produce quality
software that lasts more, as opposed to commercial software whose
quality is reduced by the planned and perceived obsolescence pushed by
the commercial software market. C++ instability and the one of the
frameworks built on top of it (Qt is a good example) don't contribute to
code quality but instead waste developper resources by forcing them to
adhere to the framework currently considered to be the best one. IMO,
this is counterproductive. Progress and improvements must be done, of
course. But doing them in expense of code quality is not what we should
do in the open source world. Commercial software development is much
better in doing this.

1381609442.12584_0.ltw:2, <8738o65jcc.fsf_-_ at arnaudov dot name>