Re: [OT] Re: C++ *for Git*
From: Marco Costalba <hidden>
Date: 2016-06-15 22:43:36
On 9/23/07, David Kastrup [off-list ref] wrote:
David Brown [off-list ref] writes:quoted
On Sun, Sep 23, 2007 at 04:09:51AM +0200, Frank Lichtenheld wrote:quoted
On Sun, Sep 23, 2007 at 12:50:00AM +0200, Alex Unleashed wrote:quoted
I'd say being forced to be explicit is a good thing here, so that the programmer at least has some sort of good understanding of what is going on, and chances are that if he doesn't really know, things just won't work out (quite unlike a lot of other languages where this programmer might actually end up with something half-assed that "mostly" works). For some reason it seems to me a lot harder to find bad programmers surviving using C than a lot of the other languages.
Well, according to your reasoning assembly should be the gotha of elite programmers, only very disciplined and meticulous programmers survive, much more then in C. Is this a good way to measure a language?
C++ is good for creating black boxes.
Object oriented languages creates black boxes: that's the reason why object oriented exsists and also the reason why Linus hates it ;-) Difference between C++ and other OO languages is mostly in the size of the applications written in that language IMHO. C++ noramlly has the bigger code bases, so problem you mention are enanched and perhaps seem to depend on the language itself not on the size of application. IOW a Python (Ruby) app probably does not have the size of Firefox or Open Office, this _could_ induce the naive idea that the python app is cleaner or easier to understand just becasue of Python vc C++. I really don't think so. I think this could be true for toy problems, but for real, for big applications is the design of the appllcation, not the language, that at 90% state the difference between clean and crap.
A black box that has been fitted into its environment and that has good innards is fine. A black box with rotten innards, or not really being well-suited for the job at hand, isn't.
I really agree here. The biggset downside of OO is that for it to work you should have a much deeper knowledge of the problem you want to handle. OO force you to analyze more and know more because a bad design normally means throwing everything in the trash can and start again. Procedural programming as C is more immune to this 'good problem analysis' dependency. Marco