Re: [OT] Re: C++ *for Git*

[Pierre Habouzit <madcoder@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 4098 bytes --]

On Sun, Sep 23, 2007 at 09:29:45AM +0000, Marco Costalba wrote:
> On 9/23/07, David Kastrup <dak@gnu.org> wrote:
> > David Brown <git@davidb.org> writes:
> >
> > > On Sun, Sep 23, 2007 at 04:09:51AM +0200, Frank Lichtenheld wrote:
> > >>On Sun, Sep 23, 2007 at 12:50:00AM +0200, Alex Unleashed wrote:
> > >>> 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.

  This non argument was raised before in the recent thread we just had.
Could we at least wait say, a month, before spawning the same trolls
again and again ?

> > 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 ;-)

  This is just nonsense. This has been proved, though I can't find the
paper about this anymore, than modules (or packages whichever name you
give them) plus abstract types are as good as OO languages at creating
black boxes. I mean it has been proved that it gives the exact same
amount of expressiveness. So please stop with this myth. And don't speak
for people, I would be very surprised that Linus would dislike "black
boxes". Abstractions are good, when used wisely, and I would be much
surprised to see Linus pretend otherwise.

  The real problem with big applications, is not that they are written
with C, C++, D, APL or Perl, but that they are big. Most of the time,
big means that many people are not able to grok the big picture, and you
end up with 102 implementations of base64, 10 string libraries, 4
general purpose buffers, and at least half of the common lisp
features[0]. And for the record git is _not_ big. It's around 100k
slocs, which rougly the size of postfix or mutt.

  I for one do believe that bad programmers will write bad code
whichever language they use, and that what is wrong is to end with code
bases in one monolithic thing like in [1]. OO design patterns and other
craps of the like helps you generate insane amount of codelines, and
hide all the simplicity under huge loads of proxies and interfaces. In
C, when your API suck, you usually need to refactor it under the
pressure of the huge amount of code you have to repeat each time you use
the API. in an OO language, you add a new class for that purpose. In C++
it's even worse, you just hide it in a copy constructor, or an operator
so that when you write:

  Foo a = b;

  Instead of a simple memcpy, you end up with an horrible pile of crap
to be started and run behind your back. C++ is very good at hiding bad
code. At least in C, when someone writes bad code, it's obvious to any
reader. C has many many quirks, I don't discuss that, but OO programming
solves none of them, and the problems OO addresses are not the one that
may interfere in the git development. I mean, the two really interesting
things in OO (that haven't a tremendous cost in return) are member
overloading and inheritance. I see very few places where git would
benefit from that, and believe me, I looked at git's code with
refactoring in mind and only that.

  Can we go back to git now ?



  [0] http://en.wikipedia.org/wiki/Greenspun's_Tenth_Rule

  [1] http://www.ohloh.net/projects/29/analyses/latest

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]