Thread (11 messages) flat view 11 messages, 8 authors, 2016-06-15

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help