* Re: [OT] Re: C++ *for Git*
From: Marco Costalba @ 2007-09-23 18:43 UTC (permalink / raw)
To: David Kastrup
Cc: Linus Torvalds, Pierre Habouzit, Frank Lichtenheld,
Alex Unleashed, Kyle Rose, Miles Bader, Dmitry Kakurin, Git
In-Reply-To: <85hcllmdzb.fsf@lola.goethe.zz>
On 9/23/07, David Kastrup <dak@gnu.org> wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> > On 9/23/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >>
> >> There are a few features of C++ that I really really like. For example, I
> >> think the C preprocessor is absolutely horrid, and a preprocessor that is
> >> built into the language - and integrates with the syntax - would be
> >> wonderful. And while C++ doesn't improve on that, at least templates are
> >> an example of something like that. Not perfect, but that's the kind of
> >> feature that C really would like.
> >>
> >
> > Yes, I really agree. IMO templates are the thing that more resembles
> > procedural programming, a common way of using them is to split data
> > structures (containers) from functions that operates on them
> > (algorithms). I find them very similar to the struct + functions
> > classical approach of C.
> >
> > And BTW
> >
> > template <typename T>
> >
> > is the thing in C++ that more remembers me of opaque pointers and
> > their use in C, the difference is that the first is fully type
> > checked.
>
> Not really. The difference is that the first generates new (and
> optimized) code for every type which is something you can only do
> using macros in C. Class programming is similar to opaque pointers
> (in particular concerning the generated code) but templates are really
> more like macros, as their instantiation generates specialized code,
> not at all like the handling of opaque pointers.
>
Probably if I had written like this was more clear:
template <typename T> int some_function(T* p);
And regarding 'new' code for each type I would like to remember that
template instantations of different types can be removed by
compiler/linker when the instantations are the same (i.e. produce the
same binary instuctions), this could happen for function templates
that handle pointers, as example.
Marco
^ permalink raw reply
* Uninstalling Git
From: in-call @ 2007-09-23 18:30 UTC (permalink / raw)
To: git
Hello!
This must be a stupid-obvious-newbie question but...
Well, the point is that I installed the git version 1.5.2.1 in an ubuntu
box. That was done following the INSTALL instructions in the
corresponding tarball. I typed:
$ make configure
$ ./configure --prefix=/usr/local
$ make all doc
$ sudo make install install-doc
First, I'd like to uninstall the thing completely, how do I do that?
Second, what would be the correct procedure to follow if I would like
just to upgrade to a newer version? install over the older perhaps? Is
that always safe in the sense that there won't be any dangling piece of
bin nor doc?
Thanks in advance!
^ permalink raw reply
* Re: [OT] Re: C++ *for Git*
From: David Kastrup @ 2007-09-23 18:30 UTC (permalink / raw)
To: Marco Costalba
Cc: Linus Torvalds, Pierre Habouzit, Frank Lichtenheld,
Alex Unleashed, Kyle Rose, Miles Bader, Dmitry Kakurin, Git
In-Reply-To: <e5bfff550709231105h94d08e2n9b1234e7c1a7e6a8@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> On 9/23/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>
>> There are a few features of C++ that I really really like. For example, I
>> think the C preprocessor is absolutely horrid, and a preprocessor that is
>> built into the language - and integrates with the syntax - would be
>> wonderful. And while C++ doesn't improve on that, at least templates are
>> an example of something like that. Not perfect, but that's the kind of
>> feature that C really would like.
>>
>
> Yes, I really agree. IMO templates are the thing that more resembles
> procedural programming, a common way of using them is to split data
> structures (containers) from functions that operates on them
> (algorithms). I find them very similar to the struct + functions
> classical approach of C.
>
> And BTW
>
> template <typename T>
>
> is the thing in C++ that more remembers me of opaque pointers and
> their use in C, the difference is that the first is fully type
> checked.
Not really. The difference is that the first generates new (and
optimized) code for every type which is something you can only do
using macros in C. Class programming is similar to opaque pointers
(in particular concerning the generated code) but templates are really
more like macros, as their instantiation generates specialized code,
not at all like the handling of opaque pointers.
While I tend to agree that templates are probably the one thing
actually worth having, it was stupid to lift the restrictions syntax
along with the concept of generics from the Ada shop. Borrowing
syntax along with features is such a Perlesque approach.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [OT] Re: C++ *for Git*
From: Marco Costalba @ 2007-09-23 18:05 UTC (permalink / raw)
To: Linus Torvalds
Cc: Pierre Habouzit, David Kastrup, Frank Lichtenheld, Alex Unleashed,
Kyle Rose, Miles Bader, Dmitry Kakurin, Git
In-Reply-To: <alpine.LFD.0.999.0709230911360.16478@woody.linux-foundation.org>
On 9/23/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> There are a few features of C++ that I really really like. For example, I
> think the C preprocessor is absolutely horrid, and a preprocessor that is
> built into the language - and integrates with the syntax - would be
> wonderful. And while C++ doesn't improve on that, at least templates are
> an example of something like that. Not perfect, but that's the kind of
> feature that C really would like.
>
Yes, I really agree. IMO templates are the thing that more resembles
procedural programming, a common way of using them is to split data
structures (containers) from functions that operates on them
(algorithms). I find them very similar to the struct + functions
classical approach of C.
And BTW
template <typename T>
is the thing in C++ that more remembers me of opaque pointers and
their use in C, the difference is that the first is fully type
checked.
Marco
^ permalink raw reply
* Re: [OT] Re: C++ *for Git*
From: Paul Franz @ 2007-09-23 17:49 UTC (permalink / raw)
To: Git
In-Reply-To: <85zlzdo3ch.fsf@lola.goethe.zz>
To me the methods that an OO class defines is the same thing as an API.
And you can screw up an API whether it is C++ or C. Both give you the
same opportunity to screw up the model and create code that needs to be
re-written.
Paul Franz
David Kastrup wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
>
>> On 9/23/07, Pierre Habouzit <madcoder@debian.org> wrote:
>>
>>>> Object oriented languages creates black boxes: that's the reason
>>>> why object oriented exsists and also the reason why Linus hates
>>>> it ;-)
>>>>
>
>
>>> 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.
>>>
>> From a Linus recent thread:
>>
>>
>>> In other words, the only way to do good, efficient, and system-level
>>> and portable C++ ends up to limit yourself to all the things that
>>> are basically available in C. And limiting your project to C means
>>> that people don't screw that up, and also means that you get a lot
>>> of programmers that do actually understand low-level issues and
>>> don't screw things up with any idiotic "object model" crap.
>>>
>> Perhaps I have misunderstood, but the idea I got is that for Linus
>> OO brings in more problems than what it tries to fix.
>>
>
> I read that as OO bringing in more programmers capable of creating
> problems than those capable of fixing them.
>
> It is not the fault of OO in itself, but it is the bottom line that
> counts: if it draws the wrong audience for the wrong reasons, it
> better had great benefits to offset that. Not quite unsimilar with
> communism: the idea is great in principle, but the idea has no
> built-in self-check. Capitalism, in contrast, is a distasteful idea
> at its heart, but it is rooted soundly in individual egoism. Which
> does not make it any less distasteful, but at least it tends to work.
>
>
--
-------------------------------------------
There are seven sins in the world.
Wealth without work.
Pleasure without conscience.
Knowledge without character.
Commerce without morality.
Science without humanity.
Worship without sacrifice.
Politics without principle.
-- Mohandas Gandhi
-------------------------------------------
^ permalink raw reply
* user-manual changes
From: J. Bruce Fields @ 2007-09-23 17:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Michael Smith, Miklos Vajna
I've got the submodule chapter plus another pending fix at:
git://linux-nfs.org/~bfields/git.git maint
The submodule documentation looks fine to me. My only suggestion is
that it should start with a brief explanation of why we have submodules
and what somebody would use them for.
--b.
J. Bruce Fields (1):
user-manual: don't assume refs are stored under .git/refs
Miklos Vajna (1):
User Manual: add a chapter for submodules
Documentation/user-manual.txt | 220 +++++++++++++++++++++++++++++++++++++++--
1 files changed, 213 insertions(+), 7 deletions(-)
^ permalink raw reply
* Re: [OT] Re: C++ *for Git*
From: Linus Torvalds @ 2007-09-23 16:54 UTC (permalink / raw)
To: Marco Costalba
Cc: Pierre Habouzit, David Kastrup, Frank Lichtenheld, Alex Unleashed,
Kyle Rose, Miles Bader, Dmitry Kakurin, Git
In-Reply-To: <e5bfff550709230642v7fa5e837s7a5b9082b043672d@mail.gmail.com>
On Sun, 23 Sep 2007, Marco Costalba wrote:
>
> Perhaps I have misunderstood, but the idea I got is that for Linus OO
> brings in more problems than what it tries to fix.
Not really.
I'm a huge believer in OO, and if you look at the kernel, for example,
there's just a ton of interfaces that are basically object-oriented. All
the VFS is, for example, is really just a object model around low-level
filesystems. The same largely goes for virtual memory mappings, or indeed
for things like the interrupt or DMA controller abstractions, the network
packet filtering etc etc etc.
But I'm also a huge believer in *explicit*syntax*. People should see what
is going on, and the abstraction should be explicit.
[ Honesty in advertising: we do end up often hiding *some* abstractions.
Sometimes it happens for historical reasons: if the code didn't have any
indirection/abstraction initially, we may end up using macros and inline
functions to hide the fact that it now is actually going through an
indirect object-oriented interface.
And sometimes it happens because the thing is *so* common or *so*
obvious that making the indirection explicit is just syntactically too
intrusive. ]
And we do all of this in C. There is no need to go to C++ for any "object
oriented principles". It really is just a syntactic issue, and in many
ways the syntax "advantage" of C++ is actually a big *disadvantage*.
I'm one of those people who think that interactions should be *locally*
visible. If you need to understand the "big picture" in order to
understand what a line of code does, that's usually a bad idea. So
syntactic tricks that hide what is actually going on are bad.
You can see some of my opinions on C in the extensions I did for sparse. I
think the C type system is a bit too sloppy, and much of what sparse does
is more totally static type checking. Things like being able to decorate
types statically, and having to explicitly carry those decorations around
is a *good* thing - because it does the opposite of hiding. Having to say
struct somestruct __user *p
to explicitly say that it's a pointer to user space - and then having
every function that takes that pointer have to have that "__user" there is
a VERY GOOD THING.
That's very different from having "accessor functions" and making "p" an
abstract type, and having the compiler automatically generate the right
kind of access. That kind of stuff is TOTAL CRAP, and it's an example of
how C++ has a horrible design, where you carry around _implicit_ knowledge
instead of making the knowledge explicit and visible locally too.
(And no, C doesn't do it very well. The C type system makes it too hard to
add explicit markers that get statically checked, and you generally have
to do it by making the code unreadable by turning things into special
structures, one for each use, or something like that).
The same goes for things like memory allocation. Memory allocation issues
are often some of the *biggest* performance issues, and that means that
they have to be explicit. I'm actually a big fan of GC, but most languages
that implement GC do it exactly the wrong way in my opinion: they make it
a fundamental thing that covers everything, and it all happens implicitly,
instead of making it explicit.
I don't know how many people have noticed that git internally actually
does do some garbage collection. It's just that we call it "caches", and
we do it explicitly. I'd love to have a language that helps me with that,
but I would *hate* to have a language that does it for everything. As it
is, we *could* do garbage collection much more, but we don't, just because
it's a bit too painful.
In practice, it means that I'm considering writing some helper routines in
C, which actually would do exactly what I want them to do: make the
(reasonably few) data structures that want to have a dynamic cache use
that dynamic cache explicitly, the way we now do for delta caching etc.
There are a few features of C++ that I really really like. For example, I
think the C preprocessor is absolutely horrid, and a preprocessor that is
built into the language - and integrates with the syntax - would be
wonderful. And while C++ doesn't improve on that, at least templates are
an example of something like that. Not perfect, but that's the kind of
feature that C really would like.
In the kernel, we (ab-)use the C preprocessor a lot for things like that.
Some of our macros are really disgusting. I'm not proud, but it works
well, and together with gcc extensions like "__typeof__" and thigns like
"__builtin_constant_p()" you can do some rather powerful things.
But other parts of C++ are just nasty. The whole OO layer seems designed
to do a lot of things implicitly and in the wrong way. I also disagree
with exception handling, and the "new" keyword kind of exemplifies a lot
of what is wrong in C++.
So in short:
- the one big feature that I think really makes a huge difference to
people, C++ does not have: garbage collection. Yes, there are GC
modules, but let's face it, you can do that equally well in C too, it's
just slightly different syntax.
- the stuff C++ *does* have is usually nasty. Implicit initializers and
destructors and the magic lifetime rules of objects etc are all just a
piece of incredible bogosity. And that all comes from the OO stuff that
is totally worthless, because it's really just syntactic fluff that can
be done easily in C.
- the C preprocessor really is horrible, and every single language beats
C handily in this area. Except for C++, which didn't fix anything at
all in that area.
Even assemblers have macro languages that allow conditionals,
repetition, nesting, etc etc. C and C++? Not so much. (Some languages
don't need it, because the language itself is dynamic and you can do
everything from within the language - ie you just evaluate an
expression that you built up dynamically as in LISP etc).
(And don't tell me about m4. It's a better preprocessor, but it's not
syntactically integrated, and it's too complex, imho)
There are other problems in C. The implicit type conversions should at
least have some way to be disabled on a type-for-type basis.
Linus
^ permalink raw reply
* Re: [OT] Re: C++ *for Git*
From: Marco Costalba @ 2007-09-23 15:15 UTC (permalink / raw)
To: David Kastrup
Cc: Pierre Habouzit, Frank Lichtenheld, Alex Unleashed, Kyle Rose,
Miles Bader, Dmitry Kakurin, Git
In-Reply-To: <85zlzdo3ch.fsf@lola.goethe.zz>
On 9/23/07, David Kastrup <dak@gnu.org> wrote:
> >
> > Perhaps I have misunderstood, but the idea I got is that for Linus
> > OO brings in more problems than what it tries to fix.
>
> I read that as OO bringing in more programmers capable of creating
> problems than those capable of fixing them.
>
> It is not the fault of OO in itself, but it is the bottom line that
> counts: if it draws the wrong audience for the wrong reasons, it
> better had great benefits to offset that.
Perhaps I'm wrong, but I think one of the advantages of big projects
written in C vs comparable size projects in an OO language (read C++)
it's exactly the opposite.
Because C lets a random developer to understand, quickly enough, and
do little local modifications also to big projects like Linux, it
attracts a lot of developers that have the possibility to start with
some janitorial work or some little patch without incurring in the
very steep learning curve you have understanding the object hierarchy
of a big C++ code base, an almost mandatory step, before to start
hacking as example in Firefox.
This is, IMHO, a big advantage: fresh meat is always welcomed, the
damage it can potentially create is more then compensated by the long
term benefit of a large and live developer community.
Marco
^ permalink raw reply
* Re: [OT] Re: C++ *for Git*
From: Marco Costalba @ 2007-09-23 14:45 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Pierre Habouzit, David Kastrup, Frank Lichtenheld, Alex Unleashed,
Kyle Rose, Miles Bader, Dmitry Kakurin, Git
In-Reply-To: <alpine.LFD.0.9999.0709231018450.32185@xanadu.home>
On 9/23/07, Nicolas Pitre <nico@cam.org> wrote:
> You must have misunderstood. Why? The linux kernel is itself very
> heavily "object oriented" already, even if it is written in C. You
> don't need C++ for that.
>
Yes it's true, you don't need it. Object oriented in C is achived
using function pointers.
In C you fill a struct of function pointers with proper values instead
of inherithing from an (abstract) base class as you would do in C++.
The results are more or less the same modulo some type safe.
Marco
^ permalink raw reply
* git-svn --migrate ?
From: Joakim Tjernlund @ 2007-09-23 14:44 UTC (permalink / raw)
To: git
noticed that git-svn --help has a migrate option but the docs
does not metion the migrate option. Is this option obsolete or
is it just missing from the docs?
Jocke
^ permalink raw reply
* Re: [OT] Re: C++ *for Git*
From: David Kastrup @ 2007-09-23 14:37 UTC (permalink / raw)
To: Marco Costalba
Cc: Pierre Habouzit, Frank Lichtenheld, Alex Unleashed, Kyle Rose,
Miles Bader, Dmitry Kakurin, Git
In-Reply-To: <e5bfff550709230642v7fa5e837s7a5b9082b043672d@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> On 9/23/07, Pierre Habouzit <madcoder@debian.org> wrote:
>> >
>> > Object oriented languages creates black boxes: that's the reason
>> > why object oriented exsists and also the reason why Linus hates
>> > it ;-)
>> 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.
>
> From a Linus recent thread:
>
>>In other words, the only way to do good, efficient, and system-level
>>and portable C++ ends up to limit yourself to all the things that
>>are basically available in C. And limiting your project to C means
>>that people don't screw that up, and also means that you get a lot
>>of programmers that do actually understand low-level issues and
>>don't screw things up with any idiotic "object model" crap.
>
> Perhaps I have misunderstood, but the idea I got is that for Linus
> OO brings in more problems than what it tries to fix.
I read that as OO bringing in more programmers capable of creating
problems than those capable of fixing them.
It is not the fault of OO in itself, but it is the bottom line that
counts: if it draws the wrong audience for the wrong reasons, it
better had great benefits to offset that. Not quite unsimilar with
communism: the idea is great in principle, but the idea has no
built-in self-check. Capitalism, in contrast, is a distasteful idea
at its heart, but it is rooted soundly in individual egoism. Which
does not make it any less distasteful, but at least it tends to work.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [OT] Re: C++ *for Git*
From: Nicolas Pitre @ 2007-09-23 14:23 UTC (permalink / raw)
To: Marco Costalba
Cc: Pierre Habouzit, David Kastrup, Frank Lichtenheld, Alex Unleashed,
Kyle Rose, Miles Bader, Dmitry Kakurin, Git
In-Reply-To: <e5bfff550709230642v7fa5e837s7a5b9082b043672d@mail.gmail.com>
On Sun, 23 Sep 2007, Marco Costalba wrote:
> From a Linus recent thread:
>
> > - inefficient abstracted programming models where two years down the road
> > you notice that some abstraction wasn't very efficient, but now all
> > your code depends on all the nice object models around it, and you
> > cannot fix it without rewriting your app.
> >
> >In other words, the only way to do good, efficient, and system-level and
> >portable C++ ends up to limit yourself to all the things that are
> >basically available in C. And limiting your project to C means that people
> >don't screw that up, and also means that you get a lot of programmers that
> >do actually understand low-level issues and don't screw things up with any
> >idiotic "object model" crap.
>
> Perhaps I have misunderstood, but the idea I got is that for Linus OO
> brings in more problems than what it tries to fix.
You must have misunderstood. Why? The linux kernel is itself very
heavily "object oriented" already, even if it is written in C. You
don't need C++ for that.
Nicolas
^ permalink raw reply
* Re: [OT] Re: C++ *for Git*
From: Marco Costalba @ 2007-09-23 13:42 UTC (permalink / raw)
To: Pierre Habouzit, Marco Costalba, David Kastrup, Frank Lichtenheld,
Alex Unleashed
In-Reply-To: <20070923104525.GC7118@artemis.corp>
On 9/23/07, Pierre Habouzit <madcoder@debian.org> wrote:
> >
> > 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.
>
>From a Linus recent thread:
> - inefficient abstracted programming models where two years down the road
> you notice that some abstraction wasn't very efficient, but now all
> your code depends on all the nice object models around it, and you
> cannot fix it without rewriting your app.
>
>In other words, the only way to do good, efficient, and system-level and
>portable C++ ends up to limit yourself to all the things that are
>basically available in C. And limiting your project to C means that people
>don't screw that up, and also means that you get a lot of programmers that
>do actually understand low-level issues and don't screw things up with any
>idiotic "object model" crap.
Perhaps I have misunderstood, but the idea I got is that for Linus OO
brings in more problems than what it tries to fix.
> The real problem with big applications, is not that they are written
> with C, C++, D, APL or Perl, but that they are big.
I have said exactly this, I don't understand where's your point in
repeating the same concept.
> 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 really don't get how you made up your mind I'm advocating OO ? The
only comment I made on OO until now was to highlight one of its
downsides.
> I mean, the two really interesting
> things in OO (that haven't a tremendous cost in return) are member
> overloading and inheritance.
You have listed two things that are a world apart one from each other.
member overload is just syntactic sugar for name mangling, while
inheritance and the _strictly_ related virtual member functions (AKA
polymorphism) is what opens the gates to all the stuff you have deeply
blamed in your post.
>I see very few places where git would
> benefit from that
Instead I see none. But probably you have looked at git code better then me.
> Can we go back to git now ?
>
You are not forced to follow this thread if this bores you.
Thanks
Marco
^ permalink raw reply
* Re: [OT] Re: C++ *for Git*
From: Pierre Habouzit @ 2007-09-23 10:45 UTC (permalink / raw)
To: Marco Costalba
Cc: David Kastrup, Frank Lichtenheld, Alex Unleashed, Kyle Rose,
Miles Bader, Dmitry Kakurin, Git
In-Reply-To: <e5bfff550709230229t79004ce2j5ce8c2ae7744a7f2@mail.gmail.com>
[-- 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 --]
^ permalink raw reply
* Re: [PATCH 4/5] git-merge: add support for --commit
From: Lars Hjemli @ 2007-09-23 10:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vir62dx0u.fsf@gitster.siamese.dyndns.org>
On 9/23/07, Junio C Hamano <gitster@pobox.com> wrote:
> Lars Hjemli <hjemli@gmail.com> writes:
>
> > This option can be used to override --no-commit and --squash. The change
> > also introduces slightly different behavior for --no-commit: when specified,
> > it explicitly overrides --squash.
>
> Makes me wonder if --no-squash also make sense to override a --squash.
> Is this really needed? IOW, does it ever make sense to have --no-commit
> in the configuration?
>
Actually, I did add --no-squash but the semantics (and implementation)
was identical to --commit so I decided it wasn't worth it (but maybe
it is - just to avoid user confusion?).
--
larsh
^ permalink raw reply
* Re: [PATCH 3/5] git-merge: add support for branch.<name>.mergeoptions
From: Lars Hjemli @ 2007-09-23 10:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vps0adx0x.fsf@gitster.siamese.dyndns.org>
On 9/23/07, Junio C Hamano <gitster@pobox.com> wrote:
> Lars Hjemli <hjemli@gmail.com> writes:
> > +branch=$(git-symbolic-ref HEAD | sed -e 's|^refs/heads/||')
> > +mergeopts=$(git config "branch.$branch.mergeoptions")
> > +parse_config $mergeopts
>
> What should happen when your head is detached?
>
My plan was 'nothing', but I should have tested it (it does work, but
also prints an ugly "fatal: ref HEAD is not a symbolic ref").
--
larsh
^ permalink raw reply
* Re: [PATCH 1/5] Add test-script for git-merge porcelain
From: Lars Hjemli @ 2007-09-23 10:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsuidx1a.fsf@gitster.siamese.dyndns.org>
On 9/23/07, Junio C Hamano <gitster@pobox.com> wrote:
> Lars Hjemli <hjemli@gmail.com> writes:
>
> > This test-script tries to excercise the porcelainish aspects of git-merge.
>
> It does exercise; no need for "tries to" ;-).
Heh, ok
> > + cmp -s file result.1
> > +'
>
> Unless there is a compelling reason otherwise, I'd prefer tests
> with a test vector like this to be spelled like this:
>
> diff -u result.1 file
>
> That is, compare to show the difference actual output might have
> from the expected result. It's easier to spot the difference
> when you later break things this way.
Good point, I'll change it.
>
> > +test_expect_success 'merge c1 with c2' '
> > + git reset --hard c1 &&
> > + git merge c2 &&
> > + test "$c1" = "$(git rev-parse HEAD^1)" &&
> > + test "$c2" = "$(git rev-parse HEAD^2)"
> > +'
>
> We might also want to test:
>
> - the index is merged;
>
> - the working tree matches the index;
>
> - the merge message (e.g. "git show -s --pretty=format:%s
> HEAD") is as expected;
Yes, sorry for being lazy ;-) I'll add more thorough verification
>
> Otherwise I think it is a good idea to add these tests.
>
> By the way, I think squash_message() leaves a wrong message
> template for an Octopus, which might be worth fixing.
Ok, I'll try to detect it in the test-script and send a proper fix.
Thanks for the review.
--
larsh
^ permalink raw reply
* Re: [OT] Re: C++ *for Git*
From: Marco Costalba @ 2007-09-23 9:50 UTC (permalink / raw)
To: David Kastrup
Cc: Frank Lichtenheld, Alex Unleashed, Kyle Rose, Miles Bader,
Dmitry Kakurin, Git
In-Reply-To: <856421ra3l.fsf@lola.goethe.zz>
On 9/23/07, David Kastrup <dak@gnu.org> wrote:
> >
> > Well, according to your reasoning
>
> Who is "you"? You are replying to a post of mine, yet commenting on
> Alex.
>
Sorry, you are right, I'm not meticolus either ;-)
Marco
^ permalink raw reply
* Re: [OT] Re: C++ *for Git*
From: David Kastrup @ 2007-09-23 9:42 UTC (permalink / raw)
To: Marco Costalba
Cc: Frank Lichtenheld, Alex Unleashed, Kyle Rose, Miles Bader,
Dmitry Kakurin, Git
In-Reply-To: <e5bfff550709230229t79004ce2j5ce8c2ae7744a7f2@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> 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
Who is "you"? You are replying to a post of mine, yet commenting on
Alex.
> assembly should be the gotha of elite programmers, only very
> disciplined and meticulous programmers survive, much more then in C.
I am neither disciplined nor meticulous, yet have designed and
programmed applications and complete systems in assembly language.
Programmers can easily survive assembly language without being
disciplined or meticulous. Their projects can't: they get tied to the
programmers. Porting an assembly language application to a different
processor might be easier than porting it to another programmer.
> Is this a good way to measure a language?
It is a good way to measure programmers, at least concerning some
interesting metrics.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [OT] Re: C++ *for Git*
From: Marco Costalba @ 2007-09-23 9:29 UTC (permalink / raw)
To: David Kastrup
Cc: Frank Lichtenheld, Alex Unleashed, Kyle Rose, Miles Bader,
Dmitry Kakurin, Git
In-Reply-To: <851wcpsv4z.fsf@lola.goethe.zz>
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.
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
^ permalink raw reply
* Re: [PATCH] Allow shell scripts to run with non-Bash /bin/sh
From: David Kastrup @ 2007-09-23 8:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eygene Ryabinkin, git
In-Reply-To: <7vtzpnf6c9.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Eygene Ryabinkin <rea-git@codelabs.ru> writes:
>
>> OK, you're right. Especially if /bin/sh from Solaris and OpenBSD
>> are working and they are not Bash. But I would not tell that
>> the shell is broken now -- I had not seen the POSIX specification.
>> Does it specifies how the shell should work in this case?
>
> I have always been assuming it to be the case (this construct is
> not my invention but is an old school idiom I just inherited
> from my mentor) and never looked at the spec recently, but I
> re-read it just to make sure. The answer is yes.
Independent of that: would you mind a patch replacing that idiom with
while : do case xxx) break; esac
instead? I find breaking out of the condition rather than the body
awkward, and I find a non-matching case statement, POSIX or not, quite
unobvious in the place of a true while condition.
It is a bit too much of cleverness for my taste. Never mind that the
current FreeBSD shell does not understand it due to being buggy: I
find that this is not very readable to the human reader either without
a double take.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] Allow shell scripts to run with non-Bash /bin/sh
From: Eygene Ryabinkin @ 2007-09-23 8:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzpnf6c9.fsf@gitster.siamese.dyndns.org>
Junio, *, good day.
Sat, Sep 22, 2007 at 01:32:38AM -0700, Junio C Hamano wrote:
> > OK, you're right. Especially if /bin/sh from Solaris and OpenBSD
> > are working and they are not Bash. But I would not tell that
> > the shell is broken now -- I had not seen the POSIX specification.
> > Does it specifies how the shell should work in this case?
>
> I have always been assuming it to be the case (this construct is
> not my invention but is an old school idiom I just inherited
> from my mentor) and never looked at the spec recently, but I
> re-read it just to make sure. The answer is yes.
>
> Visit http://www.opengroup.org/onlinepubs/000095399/ and follow
> "Shell and Utilities volume (XCU)" and then "Case conditional
> construct".
Yes, thanks for the pointer.
> So, as David suggests, if
>
> false
> case Ultra in
> Super) false ;;
> Hyper) true ;;
> esac && echo case returned ok
>
> does not say "case returned ok", then the shell has a bit of
> problem.
Correct: the current /bin/sh for FreeBSD does not set zero exit
code if no case patterns were matched. So, I apologize for my quick
decision on the non-brokenness of the /bin/sh -- it is broken.
I had fixed the shell and filed the problem report. May be the
change will be incorporated into the future release of FreeBSD.
Meanwhile, I had added workarounds to the other places Junio mentioned
in his follow-up and will try to push this patch to the FreeBSD
port of Git. The explanation had been changed too ;))
Thanks to all people who helped me to realize what is wrong and where!
--
Eygene
^ permalink raw reply
* Re: [OT] Re: C++ *for Git*
From: David Kastrup @ 2007-09-23 7:23 UTC (permalink / raw)
To: Frank Lichtenheld
Cc: Alex Unleashed, Kyle Rose, Miles Bader, Dmitry Kakurin, Git
In-Reply-To: <20070923062527.GA8979@old.davidb.org>
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.
>>
>>Idiot-proofness-by-complexity is a myth IMHO. Idiots can be quite
>>persistent...
>
> I work with plenty of them :-) It's all C. All of the same things
> happen, with management looking for magic bullets to solve problems
> caused by bad programmers.
C++ is good for creating black boxes. 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. For a project where people come and go, black
boxes might hide a lot about bad design and implementation.
In particular, changing an algorithm to require different black boxes
is something that is very unpleasant to do.
Having everything in the open is an advantage as long as the
complexity to be managed is at a reasonable level.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [OT] Re: C++ *for Git*
From: David Brown @ 2007-09-23 6:25 UTC (permalink / raw)
To: Frank Lichtenheld
Cc: Alex Unleashed, Kyle Rose, Miles Bader, Dmitry Kakurin, Git
In-Reply-To: <20070923020951.GF24423@planck.djpig.de>
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.
>
>Idiot-proofness-by-complexity is a myth IMHO. Idiots can be quite
>persistent...
I work with plenty of them :-) It's all C. All of the same things happen,
with management looking for magic bullets to solve problems caused by bad
programmers.
Dave
^ permalink raw reply
* Re: C++ *for Git*
From: Dmitry Kakurin @ 2007-09-23 4:54 UTC (permalink / raw)
To: Marco Costalba; +Cc: Johannes Schindelin, Git
In-Reply-To: <e5bfff550709220823p241d04d1n370bda4fa0ef2733@mail.gmail.com>
On 9/22/07, Marco Costalba <mcostalba@gmail.com> wrote:
> On 9/22/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > We don't want C++. Why is that so hard to accept?
> >
>
> Dmitry, I think what Johannes says in the above line is 100% the core
> point of this (sad) discussion.
Actually after a couple of responses to this thread I had a BFO
(Blinding Flash of Obvious). I cannot believe I was so naive :-). Now
I have my answer.
P.S. Mysteries like this could drive me crazy. Now I'm much happier.
--
- Dmitry
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox