On Sun, Sep 23, 2007 at 09:29:45AM +0000, Marco Costalba wrote: > On 9/23/07, David Kastrup <dak@xxxxxxx> wrote: > > David Brown <git@xxxxxxxxxx> 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@xxxxxxxxxx OOO http://www.madism.org
Attachment:
pgpionXmhsZmR.pgp
Description: PGP signature
