On Tue, 2007-09-04 at 22:50 +0200, Lukas Sandström wrote:
quoted
Hi.
This is an attempt to use "The Better String Library"[1] in builtin-mailinfo.c
The patch doesn't pass all the tests in the testsuit yet, but I thought I'd
send it out so people can decide if they like how the code looks.
I'm not sending a patch to add the library files at this time. I'll send
that patch when this patch is working.
The changes required to make it pass the tests shouldn't be very large.
Please, no. Let's not pull in a dependency for something as simple as a
string library. How many distros have bstring pcakaged?
The right version?
That's not a good argument. If dependancy is a problem, bsstring can
easily be distributed as part of git. It's really small, so it wont
make git bloated:
$ wc -l *.c *.h
82 bsafe.c
3462 bstest.c
1134 bstraux.c
2964 bstrlib.c
358 testaux.c
43 bsafe.h
112 bstraux.h
302 bstrlib.h
442 bstrwrap.h
8899 total
Does it work on Windows?
The library is totally stand alone, portable (known to work with
gcc/g++, MSVC++, Intel C++, WATCOM C/C++, Turbo C, Borland C++, IBM's
native CC compiler on Windows, Linux and Mac OS X)
We already have strbuf.c, lets just consolidate the string
manipulation code already in git under that interface.
The right question is: what does git need. One way to consolidate
strbuf would be to simply
$ rm strbuf.{c,h}
$ unzip bsstring.zip
and if people decide that git needs a non-trivial string library,
writting/testing more code in strbuf.c would probably be more work
than just reading what bsstring code does to become familiar enough
with it to even be able to maintain it later.
If people decide that git needs a really trivial string library, then
a few improvements to stbuf.c can be good.
I'd argue in favor of the first option. C strings are horrible, and I
think doing something pleasant to use and safe is not completely
trivial. But I'm not a big contributor enough to really decide in
spite of others ;-).
--
Matthieu
[ snip ]
When I first looked at Git source code two things struck me as odd:
1. Pure C as opposed to C++. No idea why. Please don't talk about
portability, it's BS.
2. Brute-force, direct string manipulation. It's both verbose and
error-prone. This makes it hard to follow high-level code logic.
- Dmitry
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:43:33
Dmitry Kakurin [off-list ref] wrote:
When I first looked at Git source code two things struck me as odd:
1. Pure C as opposed to C++. No idea why. Please don't talk about
portability, it's BS.
Git's creator (Linus) codes in C, not C++. He has at various times
stated reasons why he does not use C++. I'm sure one can find such
messages with a bit of searching on mailing lists that he frequents.
He has his reasons. I also happen to agree with at least some
of them. :)
Git evolved from that initial prototype that Linus created. I'm not
sure how much code survives from that initial few versions that
Linus managed before Junio took over, but nobody wanted to rewrite
things that already work so it just stayed in C.
"If it works, don't fix it."
C works. We (now) have 83,215 lines of it. Its not going away
anytime soon in Git. It is also a relatively simple language that
a large number of open source programmers know. This makes it easy
for them to get involved in the project. Instead of say Haskell,
which has a smaller community. Or Tcl/Tk as we recently found out
in the Git User Survey. :-\
--
Shawn.
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:43:33
Shawn O. Pearce wrote:
Dmitry Kakurin [off-list ref] wrote:
quoted
When I first looked at Git source code two things struck me as odd:
1. Pure C as opposed to C++. No idea why. Please don't talk about
portability, it's BS.
It is also a relatively simple language that
a large number of open source programmers know. This makes it easy
for them to get involved in the project.
This is important. Git contains code from more than 300 people. I'm
guessing you could cut that number by 2/3 if it had been written in C++.
Git is cheating a bit though. Its primary audience was (and is) the
various integrators working on the Linux kernel, all of whom are fairly
competent C programmers.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
When I first looked at Git source code two things struck me as odd:
1. Pure C as opposed to C++. No idea why. Please don't talk about portability,
it's BS.
*YOU* are full of bullshit.
C++ is a horrible language. It's made more horrible by the fact that a lot
of substandard programmers use it, to the point where it's much much
easier to generate total and utter crap with it. Quite frankly, even if
the choice of C were to do *nothing* but keep the C++ programmers out,
that in itself would be a huge reason to use C.
In other words: the choice of C is the only sane choice. I know Miles
Bader jokingly said "to piss you off", but it's actually true. I've come
to the conclusion that any programmer that would prefer the project to be
in C++ over C is likely a programmer that I really *would* prefer to piss
off, so that he doesn't come and screw up any project I'm involved with.
C++ leads to really really bad design choices. You invariably start using
the "nice" library features of the language like STL and Boost and other
total and utter crap, that may "help" you program, but causes:
- infinite amounts of pain when they don't work (and anybody who tells me
that STL and especially Boost are stable and portable is just so full
of BS that it's not even funny)
- 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.
So I'm sorry, but for something like git, where efficiency was a primary
objective, the "advantages" of C++ is just a huge mistake. The fact that
we also piss off people who cannot see that is just a big additional
advantage.
If you want a VCS that is written in C++, go play with Monotone. Really.
They use a "real database". They use "nice object-oriented libraries".
They use "nice C++ abstractions". And quite frankly, as a result of all
these design decisions that sound so appealing to some CS people, the end
result is a horrible and unmaintainable mess.
But I'm sure you'd like it more than git.
Linus
When I first looked at Git source code two things struck me as odd:
1. Pure C as opposed to C++. No idea why. Please don't talk about portability,
it's BS.
*YOU* are full of bullshit.
nice
C++ is a horrible language. It's made more horrible by the fact that a lot
of substandard programmers use it, to the point where it's much much
easier to generate total and utter crap with it. Quite frankly, even if
the choice of C were to do *nothing* but keep the C++ programmers out,
that in itself would be a huge reason to use C.
In other words: the choice of C is the only sane choice. I know Miles
Bader jokingly said "to piss you off", but it's actually true. I've come
to the conclusion that any programmer that would prefer the project to be
in C++ over C is likely a programmer that I really *would* prefer to piss
off, so that he doesn't come and screw up any project I'm involved with.
As dinosaurs (who code exclusively in C) are becoming extinct, you
will soon find yourself alone with attitude like this.
Measuring number of people who contributed to Git is incorrect metric.
Obviously C++ developers can contribute C code. But assuming that they
prefer it that way is wrong.
I was coding in Assembly when there was no C.
Then in C before C++ was created.
Now days it's C++ and C#, and I have never looked back.
Bad developers will write bad code in any language. But penalizing
good developers for this illusive reason of repealing bad contributors
is nonsense.
Anyway I don't mean to start a religious C vs. C++ war. It's a matter
of beliefs and as such pointless.
I just wanted to get a sense of how many people share this "Git should
be in pure C" doctrine.
--
- Dmitry
As dinosaurs (who code exclusively in C) are becoming extinct, you
will soon find yourself alone with attitude like this.
Unlike you, I actually gave reasons for my dislike of C++, and pointed to
examples of the kinds of failures that it leads to.
You, on the other hand, have given no sane reasons *for* using C++.
The fact is, git is better than the other SCM's. And good taste (and C) is
one of the reasons for that.
It has nothing to do with dinosaurs. Good taste doesn't go out of style,
and comparing C to assembler just shows that you don't have a friggin idea
about what you're talking about.
Linus
As dinosaurs (who code exclusively in C) are becoming extinct, you
will soon find yourself alone with attitude like this.
Unlike you, I actually gave reasons for my dislike of C++, and pointed to
examples of the kinds of failures that it leads to.
As I said, it's a matter of believes. As such, any reasoning and
arguing will be endless and pointless, as for any other religious
issue.
You, on the other hand, have given no sane reasons *for* using C++.
I'll give you reasons why to use C++ for Git (not why C++ is better
for any project in general, as that again would be pointless):
1. Good String class will make code much more readable (and
significantly shorter)
2. Good Buffer class - same reason
3. Smart pointers and smart handles to manage memory and
file/socket/lock handles.
As it is right now, it's too hard to see the high-level logic thru
this endless-busy-work of micro-managing strings and memory.
The fact is, git is better than the other SCM's. And good taste (and C) is
one of the reasons for that.
IMHO Git has a brilliant high-level design (object database, using
hashes, simple and accessible storage for data and metadata). Kudos to
you!
The implementation: a mixture of C and shell scripts, command line
interface that has evolved bottom-up is so-so.
and comparing C to assembler just shows that you don't have a friggin idea
about what you're talking about.
I don't see myself comparing assembler to C anywhere.
I was pointing out that I've been programming in different languages
(many more actually) and observed bad developers writing bad code in
all of them. So this quality "bad developer" is actually
language-agnostic :-).
--
- Dmitry
The fact is, git is better than the other SCM's. And good taste (and C) is
one of the reasons for that.
To be very specific:
- simple and clear core datastructures, with *very* lean and aggressive
code to manage them that takes the whole approach of "simplicity over
fancy" to the extreme.
- a willingness to not abstract away the data structures and algorithms,
because those are the *whole*point* of core git.
And if you want a fancier language, C++ is absolutely the worst one to
choose. If you want real high-level, pick one that has true high-level
features like garbage collection or a good system integration, rather than
something that lacks both the sparseness and straightforwardness of C,
*and* doesn't even have the high-level bindings to important concepts.
IOW, C++ is in that inconvenient spot where it doesn't help make things
simple enough to be truly usable for prototyping or simple GUI
programming, and yet isn't the lean system programming language that C is
that actively encourags you to use simple and direct constructs.
Linus
As it is right now, it's too hard to see the high-level logic thru
this endless-busy-work of micro-managing strings and memory.
Total BS. The string/memory management is not at all relevant. Look at the
code (I bet you didn't). This isn't the important, or complex part.
IMHO Git has a brilliant high-level design (object database, using
hashes, simple and accessible storage for data and metadata). Kudos to
you!
The implementation: a mixture of C and shell scripts, command line
interface that has evolved bottom-up is so-so.
The only really important part is the *design*. The fact that some of it
is in a "prototyping language" is exactly because it wasn't the core
parts, and it's slowly getting replaced. C++ would in *no* way have been
able to replace the shell scripts or perl parts.
And C++ would in no way have made the truly core parts better.
quoted
and comparing C to assembler just shows that you don't have a friggin idea
about what you're talking about.
I don't see myself comparing assembler to C anywhere.
You made a very clear "assembler -> C -> C++/C#" progression nin your
life, comparing my staying with C as a "dinosaur", as if it was some
inescapable evolution towards a better/more modern language.
With zero basis for it, since in many ways C is much superior to C++ (and
even more so C#) in both its portability and in its availability of
interfaces and low-level support.
I was pointing out that I've been programming in different languages
(many more actually) and observed bad developers writing bad code in
all of them. So this quality "bad developer" is actually
language-agnostic :-).
You can write bad code in any language. However, some languages, and
especially some *mental* baggages that go with them are bad.
The very fact that you come in as a newbie, point to some absolutely
*trivial* patches, and use that as an argument for a language that the
original author doesn't like, is a sign of you being a person who should
be disabused on any idiotic notions as soon as possible.
The things that actually *matter* for core git code is things like writing
your own object allocator to make the footprint be as small as possible in
order to be able to keep track of object flags for a million objects
efficiently. It's writing a parser for the tree objects that is basically
fairly optimal, because there *is* no abstraction. Absolutely all of it is
at the raw memory byte level.
Can those kinds of things be written in other languages than C? Sure. But
they can *not* be written by people who think the "high-level"
capabilities of C++ string handling somehow matter.
The fact is, that is *exactly* the kinds of things that C excels at. Not
just as a language, but as a required *mentality*. One of the great
strengths of C is that it doesn't make you think of your program as
anything high-level. It's what makes you apparently prefer other
languages, but the thing is, from a git standpoint, "high level" is
exactly the wrong thing.
Linus
IOW, C++ is in that inconvenient spot where it doesn't help make things
simple enough to be truly usable for prototyping or simple GUI
programming, and yet isn't the lean system programming language that C is
that actively encourags you to use simple and direct constructs.
Not to mention try finding two C++ compilers that support the same
language features. C is a known quantity. C++ depends on whos compiler
you use and what class libraries you use. Trying to make those things
work crossplatform is not an easy task. (Harder than it is in C at
least.)
A number of years ago, a programmer who will not be named (and is not me),
tried to port Perl to C++. It was a disaster. He found that every
compiler handled something differently.
If you stuck to one compiler, it might work. But trying to get GCC to
work like MS C++ or Borland C++ or whatever is just asking for pain.
--
Refrigerator Rule #1: If you don't remember when you bought it, Don't eat it.
As it is right now, it's too hard to see the high-level logic thru
this endless-busy-work of micro-managing strings and memory.
Total BS. The string/memory management is not at all relevant. Look at the
code (I bet you didn't). This isn't the important, or complex part.
Not only have I looked at the code, I've also debugged it quite a bit.
Granted most of my problems had to do with handling paths on Windows
(i.e. string manipulations).
Let me snip "C is better than C++" part ...
[ snip ]
... and explain where I'm coming from:
My goal is to *use* Git. When something does not work *for me* I want
to be able to fix it (and contribute the fix) in *shortest time
possible* and with *minimal efforts*. As for me it's a diversion from
my main activities.
The fact that Git is written in C does not really contribute to that goal.
Suggestion to use C++ is the only alternative with existing C codebase.
So while C++ may not be the best choice "academically speaking" it's
pretty much the only practical choice.
"Democracy is the worst form of government except for all those others
that have been tried." - Winston Churchill
Now, I realize that I'm a very infrequent contributor to Git, but I
want my opinion to be heard.
People who carry the main weight of developing and maintaining Git
should make the call.
--
- Dmitry
From: Nicolas Pitre <hidden> Date: 2016-06-15 22:43:34
On Fri, 7 Sep 2007, Paul Wankadia wrote:
Wincent Colaiuta <win <at> wincent.com> writes:
quoted
quoted
I just wanted to get a sense of how many people share this "Git should
be in pure C" doctrine.
Count me as one of them. Git is all about speed, and C is the best
choice for speed, especially in context of Git's workload.
I concur, but I also feel that D, Clean and OCaml are viable alternatives.
I happen to have zero experience with any of those, so if Git
development was done with one of them, you'd have to count me out.
C is simply the lingua franca when it comes to programming, and it
happens to be the fastest amongst portable languages too.
Nicolas
From: David Symonds <hidden> Date: 2016-06-15 22:43:34
On 07/09/07, Dmitry Kakurin [off-list ref] wrote:
My goal is to *use* Git. When something does not work *for me* I want
to be able to fix it (and contribute the fix) in *shortest time
possible* and with *minimal efforts*. As for me it's a diversion from
my main activities.
The fact that Git is written in C does not really contribute to that goal.
That's just it -- Git's goal isn't to make it as easy as possible for
Git _users_ to fix it (thought that is a nice thing to have). Git's
goal is to be a very good, very fast SCM. Bugs should be found and
fixed, but that can most effectively be done by the people who are
already knowledgeable about Git's codebase (i.e. its developers), not
its users.
Dave.
On Thu, Sep 06, 2007 at 08:09:23PM -0700, Dmitry Kakurin wrote:
quoted
Total BS. The string/memory management is not at all relevant. Look at the
code (I bet you didn't). This isn't the important, or complex part.
Not only have I looked at the code, I've also debugged it quite a bit.
Granted most of my problems had to do with handling paths on Windows
(i.e. string manipulations).
I consider string manipulation to be one of the places where C++ is a
total disaster. It's way to easy for idiots to do something like this:
a = b + "/share/" + c + serial_num;
where you can have absolutely no idea how many memory allocations are
done, due to type coercions, overloaded operators (good God, you can
overload the comma operator in C++!!!), and then when something like
that ends up in an inner loop, the result is a disaster from a
performance point of view, and it's not even obvious *why*!
My goal is to *use* Git. When something does not work *for me* I want
to be able to fix it (and contribute the fix) in *shortest time
possible* and with *minimal efforts*. As for me it's a diversion from
my main activities.
Yes, and if you contribute something the shortest time possible, and
it ends up being crap, who gets to rewrite it and fix it? I've seen
too many C++ programs which get this kind of crap added, and it's not
noticed right away (because C++ is really good at hiding such
performance killers so they are not visible), and then later on, it's
even harder to find the performance problems and fix them.
Now, I realize that I'm a very infrequent contributor to Git, but I
want my opinion to be heard.
And if git were written in C++, it's precisely the infrequent
contributors (who are in a hurry, who only care about the quick hack
to get them going, and not about the long-term maintainability and
performance of the package) that are be in the position to do the
most damage...
- Ted
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:43:34
Wincent Colaiuta wrote:
El 7/9/2007, a las 2:21, Dmitry Kakurin escribió:
quoted
I just wanted to get a sense of how many people share this "Git should
be in pure C" doctrine.
Count me as one of them. Git is all about speed, and C is the best
choice for speed, especially in context of Git's workload.
Nono, hand-optimized assembly is the best choice for speed. C is just
a little more portable ;-)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:43:34
Dmitry Kakurin wrote:
On 9/6/07, Linus Torvalds [off-list ref] wrote:
quoted
On Thu, 6 Sep 2007, Dmitry Kakurin wrote:
quoted
As it is right now, it's too hard to see the high-level logic thru
this endless-busy-work of micro-managing strings and memory.
Total BS. The string/memory management is not at all relevant. Look at the
code (I bet you didn't). This isn't the important, or complex part.
Not only have I looked at the code, I've also debugged it quite a bit.
Granted most of my problems had to do with handling paths on Windows
(i.e. string manipulations).
Let me snip "C is better than C++" part ...
quoted
[ snip ]
... and explain where I'm coming from:
My goal is to *use* Git. When something does not work *for me* I want
to be able to fix it (and contribute the fix) in *shortest time
possible* and with *minimal efforts*. As for me it's a diversion from
my main activities.
The fact that Git is written in C does not really contribute to that goal.
Coupled with what you said in an earlier mail, namely
---%<---%<---
Obviously C++ developers can contribute C code. But assuming that they
prefer it that way is wrong.
I was coding in Assembly when there was no C.
Then in C before C++ was created.
Now days it's C++ and C#, and I have never looked back.
---%<---%<---
Considering C appeared in 1972, and C++ appeared in 1985, you have been
writing C code for 13 years. And you're telling me that git being written
in C prevents you from contributing?
If you want to do something useful in C++ for git, make it easy for C++
programmers to write apps for it.
Now, I realize that I'm a very infrequent contributor to Git, but I
want my opinion to be heard.
People who carry the main weight of developing and maintaining Git
should make the call.
They already have, but every now and then someone comes along and suggest
a complete rewrite in some other language. So far we've had Java (there's
always one...), Python and now C++.
It happens to all projects, sooner or later. The funny thing is that all those
people that want their favourite software to be rewritten in their favourite
programming language always wants someone else to rewrite it for them.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Walter Bright <hidden> Date: 2016-06-15 22:43:34
Linus Torvalds wrote:
And if you want a fancier language, C++ is absolutely the worst one to
choose. If you want real high-level, pick one that has true high-level
features like garbage collection or a good system integration, rather than
something that lacks both the sparseness and straightforwardness of C,
*and* doesn't even have the high-level bindings to important concepts.
IOW, C++ is in that inconvenient spot where it doesn't help make things
simple enough to be truly usable for prototyping or simple GUI
programming, and yet isn't the lean system programming language that C is
that actively encourags you to use simple and direct constructs.
The D programming language is a different take than C++ has on growing
C. I'm curious what your thoughts on that are (D has garbage collection,
while still retaining the ability to directly manage memory). Can you
enumerate what you feel are the important concepts?
From: Walter Bright <hidden> Date: 2016-06-15 22:43:34
Wincent Colaiuta wrote:
Git is all about speed, and C is the best
choice for speed, especially in context of Git's workload.
I can appreciate that. I originally got into writing compilers because
my game (Empire) ran too slowly and I thought the existing compilers
could be dramatically improved.
And technically, yes, you can write code in C that is >= the speed of
any other language (other than asm). But practically, this isn't
necessarily so, for the following reasons:
1) You wind up having to implement the complex, dirty details of things
yourself. The consequences of this are:
a) you pick a simpler algorithm (which is likely less efficient - I
run across bubble sorts all the time in code)
b) once you implement, tune, and squeeze all the bugs out of those
complex, dirty details, you're reluctant to change it. You're reluctant
to try a different algorithm to see if it's faster. I've seen this
effect a lot in my own code. (I translated a large body of my own C++
code that I'd spent months tuning to D, and quickly managed to get
significantly more speed out of it, because it was much simpler to try
out different algorithms/data structures.)
2) Garbage collection has an interesting and counterintuitive
consequence. If you compare n malloc/free's with n gcnew/collections,
the malloc/free will come out faster, and you conclude that gc is slow.
But that misses one huge speed advantage of gc - you can do FAR fewer
allocations! For example, I've done a lot of string manipulating
programs in C. The basic problem is keeping track of who owns each
string. This is done by, when in doubt, make a copy of the string.
But if you have gc, you don't worry about who owns the string. You just
make another pointer to it. D takes this a step further with the concept
of array slicing, where one creates windows on existing arrays, or
windows on windows on windows, and no allocations are ever done. It's
just pointer fiddling.
------
Walter Bright
http://www.digitalmars.com C, C++, D programming language compilers
http://www.astoriaseminar.com Extraordinary C++
From: Pierre Habouzit <hidden> Date: 2016-06-15 22:43:34
On Fri, Sep 07, 2007 at 05:09:26AM +0000, Walter Bright wrote:
Linus Torvalds wrote:
quoted
And if you want a fancier language, C++ is absolutely the worst one to
choose. If you want real high-level, pick one that has true high-level
features like garbage collection or a good system integration, rather
than something that lacks both the sparseness and straightforwardness of
C, *and* doesn't even have the high-level bindings to important
concepts. IOW, C++ is in that inconvenient spot where it doesn't help
make things simple enough to be truly usable for prototyping or simple
GUI programming, and yet isn't the lean system programming language that
C is that actively encourags you to use simple and direct constructs.
The D programming language is a different take than C++ has on growing C.
I'm curious what your thoughts on that are (D has garbage collection,
while still retaining the ability to directly manage memory). Can you
enumerate what you feel are the important concepts?
Well, to me D has two significant drawbacks to be "ready to use". The
first one is that it doesn't has bit-fields. I often deal with bit-fields
on structures that have a _lot_ of instances in my program, and the
bit-field is chosen for code readability _and_ structure size efficiency.
I know you pretend that using masks manually often generates better
code. But in my case, speed does not matter _that_ much. I mean it does,
but not that this micro-level as access to the bit-field is not my
inner-loop.
The other second issue I have, is that there is no way to do:
import (C) "foo.h"
And this is a big no-go (maybe not for git, but as a general issue)
because it impedes the use of external libraries with a C interface a
_lot_. E.g. I'd really like to use it to use some GNU libc extensions,
but I can't because it has too many dependencies (some async getaddrinfo
interface, that need me to import all the signal events and so on
extensions in the libc, with bitfields, wich send us back to the first
point).
I also have a third, but non critical issue, I absolutely don't like
phobos :) Though I'm obviously free to chose another library. D has
definitely many many many real advances over C (like the .init, .size,
... and so on fields, known types, and whatever portability nightmare
the C impose us). In fact I like to use D like I code in C, using
modules and functions, and very few classes, as few as I can. And even
(under- ?) using D like this, it is a real pleasure to work with. I'm
really eager to see gdc be more stable.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:43:34
Walter Bright wrote:
Wincent Colaiuta wrote:
quoted
Git is all about speed, and C is the best choice for speed, especially
in context of Git's workload.
I can appreciate that. I originally got into writing compilers because
my game (Empire) ran too slowly and I thought the existing compilers
could be dramatically improved.
And technically, yes, you can write code in C that is >= the speed of
any other language (other than asm). But practically, this isn't
necessarily so, for the following reasons:
1) You wind up having to implement the complex, dirty details of things
yourself. The consequences of this are:
a) you pick a simpler algorithm (which is likely less efficient - I
run across bubble sorts all the time in code)
b) once you implement, tune, and squeeze all the bugs out of those
complex, dirty details, you're reluctant to change it. You're reluctant
to try a different algorithm to see if it's faster. I've seen this
effect a lot in my own code. (I translated a large body of my own C++
code that I'd spent months tuning to D, and quickly managed to get
significantly more speed out of it, because it was much simpler to try
out different algorithms/data structures.)
I haven't seen this in the development of git, although to be fair, you
didn't mention the number of developers that were simultaneously working
on your project. If it was you alone, I can imagine you were reluctant to
change it just to see if something is faster.
Opensource projects with many contributors (git, linux) work differently,
since one or a few among the plethora of authors will almost always be
a true expert at the problem being solved.
The current pack-format and how it's read is one such example. It was
done once, by the combined efforts of Linus and Junio (this is all off
the top of my head and I cba to go looking up the details, so bear with
me if there are errors). Linus and Junio are both very good C-programmers,
but the handling of packfiles was not what you'd call their specialty.
Along came Nicolas Pitre, another excellent C programmer, who probably
has done some similar work before. He constructed a better algorithm,
eventually resulting in the ultimate performance win with a net gain
in both time and size (gj, Nicolas).
The point is that, given enough developers, *someone* is bound to
find an algorithm that works so well that it's no longer worth
investing time to even discuss if anything else would work better,
either because it moves the performance bottleneck to somewhere else
(where further speedups would no longer produce humanly measurable
improvements), or because the action seems instantanous to the user
(further improvements simply aren't worth it, because no valuable
resource will be saved from it).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:34
Hi,
On Thu, 6 Sep 2007, Dmitry Kakurin wrote:
Anyway I don't mean to start a religious C vs. C++ war.
You have a very strange way of not meaning to start a C vs. C++ war.
It's a matter of beliefs and as such pointless.
No, it's not. As has been shown by some very good _arguments_. Once you
have facts to back up your claims, it is not any belief any longer.
Ciao,
Dscho
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:34
Hi,
On Fri, 7 Sep 2007, Linus Torvalds wrote:
On Thu, 6 Sep 2007, Dmitry Kakurin wrote:
quoted
I was pointing out that I've been programming in different languages
(many more actually) and observed bad developers writing bad code in
all of them. So this quality "bad developer" is actually
language-agnostic :-).
You can write bad code in any language. However, some languages, and
especially some *mental* baggages that go with them are bad.
There is an important additional point: a language like C _holds_ you to a
certain degree of diligence.
In my day-job I have to code in other languages, which make it "easy" to
code. As a result, the code I have to work with is sloppy, ugly and
buggy. By applying the same principles I am _forced_ to use in C, with
Git, I produce better code.
Ciao,
Dscho
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:34
Hi,
On Thu, 6 Sep 2007, Dmitry Kakurin wrote:
Now, I realize that I'm a very infrequent contributor to Git, but I want
my opinion to be heard.
We are a happy little meritocracy here. Once you proved that you're not
full of shit (some seem to try the opposite, you know who you are), you
can go all caps. Before that, you'll have to show that you earn to be
heard first.
Ciao,
Dscho
Git is all about speed, and C is the best choice for speed,
especially in context of Git's workload.
I can appreciate that. I originally got into writing compilers
because my game (Empire) ran too slowly and I thought the existing
compilers could be dramatically improved.
And technically, yes, you can write code in C that is >= the speed
of any other language (other than asm). But practically, this isn't
necessarily so, for the following reasons:
1) You wind up having to implement the complex, dirty details of
things yourself. The consequences of this are:
a) you pick a simpler algorithm (which is likely less efficient
- I run across bubble sorts all the time in code)
b) once you implement, tune, and squeeze all the bugs out of
those complex, dirty details, you're reluctant to change it. You're
reluctant to try a different algorithm to see if it's faster. I've
seen this effect a lot in my own code. (I translated a large body
of my own C++ code that I'd spent months tuning to D, and quickly
managed to get significantly more speed out of it, because it was
much simpler to try out different algorithms/data structures.)
While I accept that this is generally true, I think Git is somewhat
of a special case. From a design perspective the data structures and
algorithms are remarkably simple -- therein lies its elegance. I
think it's precisely the kind of problem that can be tackled well
with a close-to-the-metal language like C.
2) Garbage collection has an interesting and counterintuitive
consequence. If you compare n malloc/free's with n gcnew/
collections, the malloc/free will come out faster, and you conclude
that gc is slow. But that misses one huge speed advantage of gc -
you can do FAR fewer allocations! For example, I've done a lot of
string manipulating programs in C. The basic problem is keeping
track of who owns each string. This is done by, when in doubt, make
a copy of the string.
But if you have gc, you don't worry about who owns the string. You
just make another pointer to it. D takes this a step further with
the concept of array slicing, where one creates windows on existing
arrays, or windows on windows on windows, and no allocations are
ever done. It's just pointer fiddling.
This mirrors my experience in desktop application development.
Despite GC being "slower" the app actually runs faster and a lot of
nasty problems (shared resources, locking etc) just magically go
away. Development is easier too.
But once again I think Git falls into a special category where the
design makes the "hassle" of developing in C worth it.
Wincent
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:43:34
Johannes Schindelin wrote:
Hi,
On Fri, 7 Sep 2007, Andreas Ericsson wrote:
quoted
Wincent Colaiuta wrote:
quoted
El 7/9/2007, a las 2:21, Dmitry Kakurin escribi?:
quoted
I just wanted to get a sense of how many people share this "Git should
be in pure C" doctrine.
Count me as one of them. Git is all about speed, and C is the best choice
for speed, especially in context of Git's workload.
Nono, hand-optimized assembly is the best choice for speed. C is just
a little more portable ;-)
I have a buck here that says that you cannot hand-optimise assembly (on
modern processors at least) as good as even gcc.
http://www.gelato.unsw.edu.au/archives/git/0504/1746.html
I win. Donate $1 to FSF next time you get the opportunity ;-)
Hand-optimized asm is faster because the optimizer in the compiler is a
general-purpose one that has to guess and make assumptions about the code
and its input to make the correct decisions. While it gets things right
in as many as 80% of the cases, there's still the 20% where it doesn't.
A human can, with sufficient research and effort, make the same optimizations
where they are correct but avoid the 20% erroneous ones.
If the compiler gets it wrong inside your innermost loop, it might be worth
shaving those extra 0.0001 seconds off of each iteration, because in the long
run, world-wide, it might save several weeks worth of CPU-time every day.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Well, you picked a very specific algorithm amenable to that kind of
optimization: small, manageable, with a minimal and well-defined
performance critical section that could be written in assembly. Note
how a good chunk of the implementation was still in C. At most I'd
give you 75 cents for that one. ;-)
Wincent
From: Karl Hasselström <hidden> Date: 2016-06-15 22:43:34
On 2007-09-07 14:33:42 +0200, Wincent Colaiuta wrote:
Well, you picked a very specific algorithm amenable to that kind of
optimization: small, manageable, with a minimal and well-defined
performance critical section that could be written in assembly. Note
how a good chunk of the implementation was still in C.
And this is of course exactly the kind of spot where you _would_ use
assembly in the real world. 99.99% of code is better written in C than
assembler, but there is that 0.01% where hand-coded assembler is a
better choice.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
Well, you picked a very specific algorithm amenable to that kind of
optimization: small, manageable, with a minimal and well-defined
performance critical section that could be written in assembly. Note how
a good chunk of the implementation was still in C. At most I'd give you
75 cents for that one. ;-)
Yes, but that's what I said in the original email as well. C is just so
much more pleasant to write in that the only place you'd (sanely) use
asm is in exactly these tight loops, where the code is likely to be used
and reused until the algorithm it describes is no longer a viable option
for doing what it was originally designed to do.
It still proves the point though, as surely as n+1 > n for any value of n:
Hand-optimized assembly is faster than compiler-optimized C code.
It might be harder to do properly on some architectures than others (RISC
comes to mind), but it's still possible.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
El 7/9/2007, a las 15:58, Andreas Ericsson escribió:
Yes, but that's what I said in the original email as well. C is
just so
much more pleasant to write in that the only place you'd (sanely) use
asm is in exactly these tight loops, where the code is likely to be
used
and reused until the algorithm it describes is no longer a viable
option
for doing what it was originally designed to do.
It still proves the point though, as surely as n+1 > n for any
value of n:
Hand-optimized assembly is faster than compiler-optimized C code.
In a theoretical ideal world, yes; no one would argue that C is
faster than fine-tuned assembly.
But in the *real world* rewriting Git in assembly would be like
painting a house using a single horse hair instead of a paint brush
or roller. Your SHA-1 example is a perfect example of where you
benefit from doing a tiny embellished detail using the single hair
(assembly) and leave all the rest in C.
In the real world and not the theoretical ideal world, it's not just
about the diminishing returns you get from writing more and more of a
code base in assembly instead of just the performance-critical
bottlenecks; it's that you're more likely to make subtle mistakes or
even make things slower. GCC does a remarkable job of optimizing in a
huge number of use cases, and best of all, it does it for free.
Personal opinion, of course, but that's the way I think it is.
Cheers,
Wincent
From: Walter Bright <hidden> Date: 2016-06-15 22:43:34
Pierre Habouzit wrote:
Well, to me D has two significant drawbacks to be "ready to use". The
first one is that it doesn't has bit-fields. I often deal with bit-fields
on structures that have a _lot_ of instances in my program, and the
bit-field is chosen for code readability _and_ structure size efficiency.
I know you pretend that using masks manually often generates better
code. But in my case, speed does not matter _that_ much. I mean it does,
but not that this micro-level as access to the bit-field is not my
inner-loop.
I'm surprised this is such an important issue. Others have mentioned it,
but regard it as a minor thing. Interestingly, the htod program (which
converts C .h files to D import files) will convert bit fields to inline
functions, giving equivalent functionality.
The other second issue I have, is that there is no way to do:
import (C) "foo.h"
And this is a big no-go (maybe not for git, but as a general issue)
because it impedes the use of external libraries with a C interface a
_lot_. E.g. I'd really like to use it to use some GNU libc extensions,
but I can't because it has too many dependencies (some async getaddrinfo
interface, that need me to import all the signal events and so on
extensions in the libc, with bitfields, wich send us back to the first
point).
D does come with htod, which converts C .h files to D files. It's not
possible to do a perfect job (because of macros), but it comes pretty
darned close. The reason htod gets so close is because it is actually a
real C compiler front end, not a perl or regex string processing hack.
Because it (may) require a little hand tweaking of the results (again,
because C headers may include awful things like:
#define BEGIN {
#define print printf(
), it's a separate program rather than built-in.
I also have a third, but non critical issue, I absolutely don't like
phobos :)
You're not the only one <g>. But I'll add that access to the standard C
runtime library *is* a part of D, so at some level it can't be worse
than C. There's also another runtime library available, Tango, which is
very popular.
Though I'm obviously free to chose another library. D has
definitely many many many real advances over C (like the .init, .size,
... and so on fields, known types, and whatever portability nightmare
the C impose us). In fact I like to use D like I code in C, using
modules and functions, and very few classes, as few as I can. And even
(under- ?) using D like this, it is a real pleasure to work with. I'm
really eager to see gdc be more stable.
There are a lot of people hard at work on D to make it more stable and
increase the breadth and depth of tools available. I am fully aware that
there may be non-technical issues to using D in a project like git, like
availability of other D programmers, tradition, etc., but in this thread
I'm concerned mainly with technical issues.
P.S. I'm also NOT suggesting that git be converted to D. Translating a
working, debugged, 80,000 line codebase from one language to another is
usually a fool's errand.
Thanks for taking the time to post your thoughts.
-----------
Walter Bright
http://www.digitalmars.com C, C++, D programming language compilers
http://www.astoriaseminar.com Extraordinary C++
From: Walter Bright <hidden> Date: 2016-06-15 22:43:34
Andreas Ericsson wrote:
Walter Bright wrote:
quoted
1) You wind up having to implement the complex, dirty details of
things yourself. The consequences of this are:
a) you pick a simpler algorithm (which is likely less efficient - I
run across bubble sorts all the time in code)
b) once you implement, tune, and squeeze all the bugs out of those
complex, dirty details, you're reluctant to change it. You're
reluctant to try a different algorithm to see if it's faster. I've
seen this effect a lot in my own code. (I translated a large body of
my own C++ code that I'd spent months tuning to D, and quickly managed
to get significantly more speed out of it, because it was much simpler
to try out different algorithms/data structures.)
I haven't seen this in the development of git, although to be fair, you
didn't mention the number of developers that were simultaneously working
on your project.
On my project, one. But I've seen this problem repeatedly in other
projects that had multiple developers. For example, I used to use
version 1 of an assembler. It was itself written entirely in assembler.
It ran *incredibly* slowly on large asm files. But it was written in
assembler, which is very fast, so how could that be?
Turns out, the symbol table used internally was a linear one. A linear
symbol table is easy to implement, but doesn't scale well at all. A
linear symbol table was implemented because it was just harder to do
more advanced symbol table algorithms in assembler. In this case, a
higher level language re-implementation made the assembler much faster,
even though that implementation was SLOWER in every detail. It was
faster overall, because it was easier to develop faster algorithms.
If it was you alone, I can imagine you were reluctant to
change it just to see if something is faster.
My point was that when I reimplemented it in D, the cost of changing the
algorithms got much lower, so I was much more tempted to muck around
trying out different ones. The result was I found faster ones.
Opensource projects with many contributors (git, linux) work differently,
since one or a few among the plethora of authors will almost always be
a true expert at the problem being solved.
That is a nice advantage. I don't think many projects can rely on having
the best in the business working on them, though <g>.
The point is that, given enough developers, *someone* is bound to
find an algorithm that works so well that it's no longer worth
investing time to even discuss if anything else would work better,
either because it moves the performance bottleneck to somewhere else
(where further speedups would no longer produce humanly measurable
improvements), or because the action seems instantanous to the user
(further improvements simply aren't worth it, because no valuable
resource will be saved from it).
Sure, but I suggest that few projects reach this maxima. Case in point:
ld, the gnu linker. It's terribly slow. To see how slow it is, compare
it to optlink (the 15 years old one that comes with D for Windows). So I
don't believe there is anything inherent about linking that should make
ld so slow. There's some huge leverage possible in speeding up ld
(spreading out that saved time among all the gnu developers).
So while git may have reached a maxima in performance, I don't think
this principle is applicable in general, even for very widely used open
source projects that would profit greatly from improved performance.
------
Walter Bright
http://www.digitalmars.com C, C++, D programming language compilers
http://www.astoriaseminar.com Extraordinary C++
From: Walter Bright <hidden> Date: 2016-06-15 22:43:34
Wincent Colaiuta wrote:
But once again I think Git falls into a special category where the
design makes the "hassle" of developing in C worth it.
That may very well be true. I've never looked at the source code for
git, so I'm not in any position to judge it. Nor do I suggest
translating a debugged, working, 80,000 line project into another language.
My comments here are in more general terms.
From: Pierre Habouzit <hidden> Date: 2016-06-15 22:43:34
On Fri, Sep 07, 2007 at 07:03:24PM +0000, Walter Bright wrote:
Pierre Habouzit wrote:
quoted
Well, to me D has two significant drawbacks to be "ready to use". The
first one is that it doesn't has bit-fields. I often deal with
bit-fields
on structures that have a _lot_ of instances in my program, and the
bit-field is chosen for code readability _and_ structure size
efficiency.
I know you pretend that using masks manually often generates better
code. But in my case, speed does not matter _that_ much. I mean it does,
but not that this micro-level as access to the bit-field is not my
inner-loop.
I'm surprised this is such an important issue. Others have mentioned it,
but regard it as a minor thing. Interestingly, the htod program (which
converts C .h files to D import files) will convert bit fields to inline
functions, giving equivalent functionality.
Well htod does that, but it's very impractical to write them from
scratch. Especially if you want to benefit from the fact that padding
and integer sizes are very well defined to map e.g. structs onto a raw
stream, avoiding deserialization and so on. And for that bit-fields are
a really really fast and simple way to describe things.
I mean, take your classical example of the foreach loop. Your whole
point is that it's way shorter, and safer. And now you are saying that
people should instead of sth like:
struct my_struct {
unsigned some_field : 2;
unsigned has_this_property : 1;
unsigned is_in_this_state : 1;
unsigned priority_level : 2;
...
}
people should write (IIRC it works since ->some_field = 2 calls
->some_field(2) if the member does not exists, or maybe it's
set_some_field, it's not very relevant anyway):
struct my_struct {
unsigned some_field() {
return this->real_field >> 30;
}
void some_field(unsigned value) {
this->real_field |= (value & 3) << 30;
}
...
private:
unsigned real_field;
}
Please it has to be a joke: there is 42 ways for people to write it
wrong (wrong shifts, wrong masks, and so on), it's horribly obfuscated,
hence needs a lot of comments, whereas the bitfield is 90% self
documented, and the syntax is _very_ clear, you cannot beat that. I
would be absolutely fine with it being syntactical sugar for some kind
of template call though.
Not to mention that the usual C idiom:
union {
unsigned flags;
struct {
// many bitfields
};
};
Would need an explicit copy_flags(const my_struct foo) function to
work. Not pretty, not straightforward.
Really, I feel this is a big lack, for a language that aims at
simplicity, conciseness _and_ correctness.
OK, maybe I'm biased, I work with networks protocols all day long, so
I often need bitfields, but still, a lot of people deal with network
protocols, it's not a niche.
quoted
The other second issue I have, is that there is no way to do:
import (C) "foo.h"
And this is a big no-go (maybe not for git, but as a general issue)
because it impedes the use of external libraries with a C interface a
_lot_. E.g. I'd really like to use it to use some GNU libc extensions,
but I can't because it has too many dependencies (some async getaddrinfo
interface, that need me to import all the signal events and so on
extensions in the libc, with bitfields, wich send us back to the first
point).
D does come with htod, which converts C .h files to D files.
Last time I checked it was only available on windows, and closed
source, both are an impediment for many people. It's definitely clear
that gcc being opensource and available on so many platforms helped to
make C what it is today. Lacking portable and free (as in speech) tools
are an impediment to the succes of a language. Right now, for D, only
gdc exists, it lags behind dmd quite a lot afaict, and there is no other
toolchain helpers yet.
It's not possible to do a perfect job (because of macros), but it
comes pretty darned close. The reason htod gets so close is because it
is actually a real C compiler front end, not a perl or regex string
processing hack.
Because it (may) require a little hand tweaking of the results (again,
because C headers may include awful things like:
#define BEGIN {
#define print printf(
), it's a separate program rather than built-in.
Yeah I'm fine with that, but sadly it's not available everywhere like
I said.
quoted
I also have a third, but non critical issue, I absolutely don't like
phobos :)
You're not the only one <g>. But I'll add that access to the standard C
runtime library *is* a part of D, so at some level it can't be worse than
C. There's also another runtime library available, Tango, which is very
popular.
I completely agree, and I knew about Tango, and anyways, I'm so used
to C, and D has so few to bring to my code style when I deal with low
level system functions, that I'm totally fine with std.c.* anyways :)
For the record I wasn't suggesting to rewrite git in D at all. I just
happened to see your post, and being very interested in where D is going
because I feel it's an excellent langage, and saw an opportunity to
mention a few quirks I feel it has, so, well, I answered :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
From: Walter Bright <hidden> Date: 2016-06-15 22:43:34
Pierre Habouzit wrote:
Well htod does that, but it's very impractical to write them from
scratch.
True. I haven't tried yet (nobody else seems to care about it as much as
you do!), but I think this could be automated fairly easily with a template.
And for that bit-fields are
a really really fast and simple way to describe things.
I should point out that inline functions are inlined, and there is no
speed difference in the result.
Not to mention that the usual C idiom:
union {
unsigned flags;
struct {
// many bitfields
};
};
Would need an explicit copy_flags(const my_struct foo) function to
work. Not pretty, not straightforward.
I'm not following this. To copy a union, you just copy it with the
assignment operator:
U a, b;
a = b; // copies all the bit fields, too!
quoted
D does come with htod, which converts C .h files to D files.
Last time I checked it was only available on windows, and closed
source, both are an impediment for many people.
You're right on both counts. It's because htod is built out of a fork of
the Digital Mars C compiler. Something similar could be done with gcc,
but I'm not the person to do it. I should also get off my lazy tail and
port htod to linux.
Right now, for D, only
gdc exists, it lags behind dmd quite a lot afaict, and there is no other
toolchain helpers yet.
GDC was just released for D 1.020, which is behind D 1.021, but 1.021
was released just a couple days ago <g>.
For the record I wasn't suggesting to rewrite git in D at all. I just
happened to see your post, and being very interested in where D is going
because I feel it's an excellent langage, and saw an opportunity to
mention a few quirks I feel it has, so, well, I answered :)
And it's nice to hear your perspective, which is why I dropped by this
thread.
From: Pierre Habouzit <hidden> Date: 2016-06-15 22:43:34
On Fri, Sep 07, 2007 at 08:40:56PM +0000, Walter Bright wrote:
Pierre Habouzit wrote:
quoted
And for that bit-fields are
a really really fast and simple way to describe things.
I should point out that inline functions are inlined, and there is no
speed difference in the result.
I know that, and that's why I said I was totally fine with the
bitfield notation to be only syntactic sugar on a template thingy if
that's the simplest way to have that it's OKay.
quoted
Not to mention that the usual C idiom:
union {
unsigned flags;
struct {
// many bitfields
};
};
Would need an explicit copy_flags(const my_struct foo) function to
work. Not pretty, not straightforward.
I'm not following this. To copy a union, you just copy it with the
assignment operator:
U a, b;
a = b; // copies all the bit fields, too!
That was the point indeed. But if you don't have bitfields, you can't
do the union. And if the bitfield is just syntactic sugar, it may be
unpossible to have such a union. But I may be wrong.
quoted
Right now, for D, only
gdc exists, it lags behind dmd quite a lot afaict, and there is no other
toolchain helpers yet.
GDC was just released for D 1.020, which is behind D 1.021, but 1.021 was
released just a couple days ago <g>.
Sure, but it does not works on amd64 properly (and it's the
architecture I care about) and is not ready for the current gcc (4.2,
only 4.1 builds) and so on. It's not as stable as DMD is. It does not
lags too much version-wise, it lags in maturity. But well, youth has a
cure: time :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
They already have, but every now and then someone comes along and suggest
a complete rewrite in some other language. So far we've had Java (there's
always one...), Python and now C++.
Since this "complete rewrite" was mentioned in multiple emails I'd
like to rectify that:
What I'm offering (for Git) is to use C++ as a "better C".
Don't change any existing *working* code, but start introducing simple
C++ constructs in the new code.
Git is simple enough to not require any high-level abstractions. But
some utility classes could make code much simpler.
And BTW, I don't even like C++ that much :-), I just like it much
better than C. I've been saying that C++ is a legacy language for
quite some time now. But we will use it for many years to come because
the size of this legacy code is huge, so there will be plenty of C++
developers available (to contribute to Git :-).
And C++ is the only way to move with existing C codebase.
--
- Dmitry
From: Walter Bright <hidden> Date: 2016-06-15 22:43:34
Pierre Habouzit wrote:
Sure, but it does not works on amd64 properly (and it's the
architecture I care about) and is not ready for the current gcc (4.2,
only 4.1 builds) and so on. It's not as stable as DMD is. It does not
lags too much version-wise, it lags in maturity. But well, youth has a
cure: time :)
Yes, and the more people use it, the better it will get. These are all
environmental problems, not technical limitations of the language.
On 9/7/07, Johannes Schindelin [off-list ref] wrote:
Hi,
On Thu, 6 Sep 2007, Dmitry Kakurin wrote:
quoted
Anyway I don't mean to start a religious C vs. C++ war.
You have a very strange way of not meaning to start a C vs. C++ war.
I honestly didn't. I didn't even think it's possible. In the
environment of mainstream commercial software development the last war
on this subj was over 8-10 years ago.
Even wars like "do we use exceptions/templates/stl" are pretty much
over. Now days it's "do we use Boost", or "do we use template
metaprogramming". But even more often it's Java/C# vs. C++.
That's why I was wondering how come C was chosen for Git.
quoted
It's a matter of beliefs and as such pointless.
No, it's not. As has been shown by some very good _arguments_. Once you
have facts to back up your claims, it is not any belief any longer.
Well I've heard *opinions* and anecdotal evidence. No facts though.
And it's not surprising. There could be no hard facts in such a
matter. It always boils down to "most of all, I want my software to be
X" where X is different for different people (fast,maintainable,quick
to market, scalable, beautiful, etc ... to name a few).
With different values of X any debate is pointless. And X is exactly
the matter of believes.
Anyway my curiosity is satisfied (thru the roof so to speak) and I
think it's enough on the subj. It has reminded me of good old times
though.
--
- Dmitry
And if you want a fancier language, C++ is absolutely the worst one to
choose. If you want real high-level, pick one that has true high-level
features like garbage collection or a good system integration, rather than
something that lacks both the sparseness and straightforwardness of C,
*and* doesn't even have the high-level bindings to important concepts.
IOW, C++ is in that inconvenient spot where it doesn't help make things
simple enough to be truly usable for prototyping or simple GUI
programming, and yet isn't the lean system programming language that C is
that actively encourags you to use simple and direct constructs.
Linus
I want code that is Correct, Explicit, Fast, and in that order.
I'm 23 years old and learned C++ when I was 13. Back then, my compiler didn't
even support "bleeding edge" C++ language features like namespaces. I'm not a
C++ expert, and I don't have the ego to call myself a superb programmer. The
largest program I've written is 10K SLOC in C. Yet, I'd like to participate in
this discussion, if that is OKay =)
I do think I am capable of an honest critique of the downside of C++:
_Problems_ _With_ _C++_
*size*
On my bookshelf, most recent editions of the canonical C++ _books_:
Accelerated C++: Practical Programming by Example (336 pages)
The C++ Standard Template Library: A Tutorial and Reference (832 pages)
Effective C++: 50 Specific Ways to Improve Your Programs and Design (288
pages)
More Effective C++: 35 New Ways to Improve Your Programs and Designs
(336 pages)
Exceptional C++: 47 Engineering Puzzles, Programming Problems, and
Solutions (240 pages)
More Exceptional C++: 40 New Engineering Puzzles, Programming Problems,
and Solutions (304 pages)
The C++ Programming Language (1030 pages)
Modern C++ Design: Generic Programming and Design Patterns Applied (352
pages)
C++ Templates: The Complete Guide (552 pages)
Altogether, that is 3918 pages. K&R, the canonical C _book_, is 272 pages.
Becoming a C++ language lawyer is much harder than becoming a C language
lawyer. Language lawyers know "how not to hang oneself" while programming in
the language. I don't know how many of these titles are translated to other
languages, however, I am sure the *effort* required to translate all of them is
significant. Open source is more successful if there is a lingua franca for
programming, and that is C. Now, it may move away from C over time, but it will
*never* be C++ because it's encyclopedic.
*hidden complexity*
(1) it's hard to say what code will compile down to. viz., constructors can
be elided, but there is no fitness warranty; profiling your compiler to find out
whether it is elided is tedious and "searching for secrets" that should be
_explicit_
(2) people don't understand static polymorphism and compile-time dispatch;
people are used to objects sending messages dynamically (run-time dispatch)
(3) coercion
(4) networks of objects are not explicitly laid out, hiding quadratically
complex patterns of communication between objects
(5) data structure and data flow come before algorithms. Sometimes, data
structure dictates data flow (ad-hoc networks of objects); sometimes, data flow
dictates data structure (one of life's most disagreeable tasks - waiting in line
- is characterized as FIFO). This, I feel, is the most important point, because
the first rule of programming is to figure out what you want to say before you
figure out how to say it. In C++, ad-hoc networks of objects with cyclic
message paths are all too easy to create [see (4)] which means _code_ _is_ _not_
_explicit_ and as a result _code_ _is_ _not_ _fast_.
*transfer semantics on objects are not robust*
this ties into (1) in hidden complexity
the code author needs to specify a lot of boilerplate to achieve desired
transfer semantics on objects. Similarly, the code audience, be it reviewer,
maintainer or merger, needs to read a lot of boilerplate to understand how
objects get moved around in memory. Moreover, most of these concepts are
intuitively declarative in nature, such as a parent object/child object relation.
*poor re-use of effort*
"code re-use" is a misnomer; when programmers speak of code-reuse they mean
re-use of effort. There is no benefit to polymorphism if effort cannot be
consolidated easily.
*C++ Standard iffy*
Some things just disappear quickly for *frantic* reasons (strstream was
removed for aesthetics), indicating not enough foresight into what is important.
I do not want to pick a language where I have to worry about features in it's
"standard library" becoming deprecated mainly for aesthetics. As Dijkstra
preached, programming is _not_ supposed to be a frantic exercise.
*usually, better options*
See C++??: A Critique of C++ and Programing and Language Trends in the 1990s
by Ian Joyner http://web.mac.com/joynerian/iWeb/Ian%20Joyner/CPPCritique.pdf
(Somewhat outdated, but many of the points are intrinsic and will forever be
relevant). You can add to the list of better options D 1.0.
From: Alex Riesen <hidden> Date: 2016-06-15 22:43:34
Dmitry Kakurin, Sat, Sep 08, 2007 02:32:09 +0200:
On 9/7/07, Johannes Schindelin [off-list ref] wrote:
quoted
Hi,
On Thu, 6 Sep 2007, Dmitry Kakurin wrote:
quoted
Anyway I don't mean to start a religious C vs. C++ war.
You have a very strange way of not meaning to start a C vs. C++ war.
I honestly didn't. I didn't even think it's possible. In the
environment of mainstream commercial software development the last war
on this subj was over 8-10 years ago.
It is because the "environment of mainstream commercial software
development" is stuck in "8-10" back from now.
Even wars like "do we use exceptions/templates/stl" are pretty much
over. Now days it's "do we use Boost", or "do we use template
metaprogramming". But even more often it's Java/C# vs. C++.
Now that's a stupid argument to bring up. Commercial software
development is were the most stupid mistakes are done and repeated.
That's why I was wondering how come C was chosen for Git.
"Just to annoy mainstream commercial software developers" would be a
good reason.
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:43:34
Dmitry Kakurin wrote:
On 9/6/07, Andreas Ericsson [off-list ref] wrote:
quoted
They already have, but every now and then someone comes along and suggest
a complete rewrite in some other language. So far we've had Java (there's
always one...), Python and now C++.
Since this "complete rewrite" was mentioned in multiple emails I'd
like to rectify that:
What I'm offering (for Git) is to use C++ as a "better C".
Don't change any existing *working* code, but start introducing simple
C++ constructs in the new code.
Git is simple enough to not require any high-level abstractions. But
some utility classes could make code much simpler.
There are far too many highly valuable contributors that have spoken
against C++ for me to believe that C++ and C will ever co-exist in the
official git repo. Good thing utility classes can be developed on top
of the existing C-code, but in a separate repo, and packed into a
library. That way, you get some hacking ground for your beloved C++
coderswhile the current git contributors can keep contributing in the
language they like best.
And BTW, I don't even like C++ that much :-), I just like it much
better than C. I've been saying that C++ is a legacy language for
quite some time now. But we will use it for many years to come because
the size of this legacy code is huge, so there will be plenty of C++
developers available (to contribute to Git :-).
The C code base is a lot larger and C++ will drop dead pretty fast if it's
ever removed or left unmaintained. So much for dinosaurs...
And C++ is the only way to move with existing C codebase.
Complete and utter BS. It can also stay in C, or get language bindings for
Python/Perl/PHP/LUA(?)/whatever, or both.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:43:34
Wincent Colaiuta wrote:
El 7/9/2007, a las 15:58, Andreas Ericsson escribió:
quoted
Yes, but that's what I said in the original email as well. C is just so
much more pleasant to write in that the only place you'd (sanely) use
asm is in exactly these tight loops, where the code is likely to be used
and reused until the algorithm it describes is no longer a viable option
for doing what it was originally designed to do.
It still proves the point though, as surely as n+1 > n for any value
of n:
Hand-optimized assembly is faster than compiler-optimized C code.
In a theoretical ideal world, yes; no one would argue that C is faster
than fine-tuned assembly.
But in the *real world* rewriting Git in assembly would be like painting
a house using a single horse hair instead of a paint brush or roller.
Your SHA-1 example is a perfect example of where you benefit from doing
a tiny embellished detail using the single hair (assembly) and leave all
the rest in C.
In the real world and not the theoretical ideal world, it's not just
about the diminishing returns you get from writing more and more of a
code base in assembly instead of just the performance-critical
bottlenecks; it's that you're more likely to make subtle mistakes or
even make things slower. GCC does a remarkable job of optimizing in a
huge number of use cases, and best of all, it does it for free. Personal
opinion, of course, but that's the way I think it is.
The discussion was theoretical from the beginning. Nobody's arguing that
git should be rewritten in asm, and you've been preaching to the choir far
too long now. I'll just drop this thread.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:43:34
Walter Bright wrote:
Andreas Ericsson wrote:
quoted
Walter Bright wrote:
quoted
1) You wind up having to implement the complex, dirty details of
things yourself. The consequences of this are:
a) you pick a simpler algorithm (which is likely less efficient -
I run across bubble sorts all the time in code)
b) once you implement, tune, and squeeze all the bugs out of those
complex, dirty details, you're reluctant to change it. You're
reluctant to try a different algorithm to see if it's faster. I've
seen this effect a lot in my own code. (I translated a large body of
my own C++ code that I'd spent months tuning to D, and quickly
managed to get significantly more speed out of it, because it was
much simpler to try out different algorithms/data structures.)
I haven't seen this in the development of git, although to be fair, you
didn't mention the number of developers that were simultaneously working
on your project.
On my project, one. But I've seen this problem repeatedly in other
projects that had multiple developers. For example, I used to use
version 1 of an assembler. It was itself written entirely in assembler.
It ran *incredibly* slowly on large asm files. But it was written in
assembler, which is very fast, so how could that be?
Turns out, the symbol table used internally was a linear one. A linear
symbol table is easy to implement, but doesn't scale well at all. A
linear symbol table was implemented because it was just harder to do
more advanced symbol table algorithms in assembler. In this case, a
higher level language re-implementation made the assembler much faster,
even though that implementation was SLOWER in every detail. It was
faster overall, because it was easier to develop faster algorithms.
Well, when the ease-of-coding vs the exec-speed of D vs C is that of
C vs asm, C will be dead fairly soon. However, since C is so ingrained
in every language designer's head, I find that unlikely to happen any
time soon.
quoted
Opensource projects with many contributors (git, linux) work differently,
since one or a few among the plethora of authors will almost always be
a true expert at the problem being solved.
That is a nice advantage. I don't think many projects can rely on having
the best in the business working on them, though <g>.
True that. I know a fair few projects that could have done with borrowing
one or two proper gurus, but even opensource programmers are selfish in
that we usually only work for something that benefits ourselves.
quoted
The point is that, given enough developers, *someone* is bound to
find an algorithm that works so well that it's no longer worth
investing time to even discuss if anything else would work better,
either because it moves the performance bottleneck to somewhere else
(where further speedups would no longer produce humanly measurable
improvements), or because the action seems instantanous to the user
(further improvements simply aren't worth it, because no valuable
resource will be saved from it).
Sure, but I suggest that few projects reach this maxima.
True again, but given what I said above holds, it would be madness to
move from the lingua franca of oss hacking to a less common one, as it
would mean fewer eyes on the code.
Case in point:
ld, the gnu linker. It's terribly slow. To see how slow it is, compare
it to optlink (the 15 years old one that comes with D for Windows). So I
don't believe there is anything inherent about linking that should make
ld so slow. There's some huge leverage possible in speeding up ld
(spreading out that saved time among all the gnu developers).
So while git may have reached a maxima in performance, I don't think
this principle is applicable in general, even for very widely used open
source projects that would profit greatly from improved performance.
Interesting. I recently did a spot of work comparing various string-hashing
algorithms. Perhaps I should head over to the ld camp and see if I can help.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Steven Burns <hidden> Date: 2016-06-15 22:43:35
To me, the only thing that C++ has that all other mentioned languages lack
is the power you get from the templates and generic programming.
Sorting will always be faster if you can call the comparison function
directly without using a function pointer, and the only way you can create a
generic sorting algorithm is that way.
Thinking about it with a cold head, most things to hate about C++ are not in
the language but in its libraries.
The only feature I hate from the language itself is the preprocessor
(macros), which you get in C too.
And maybe I also hate the fact that C++ allows for unexperienced programmers
to create a bunch of classes and hierarchies that make sense to nobody but
them. Or even worse, unexperienced programmers start writing their own
frameworks, wrapping and re-wrapping, the same good old C function one
thousand times.
I guess that is why most C++ based projects out there have a strict list of
rules and conventions, you cannot have a stable project without them.
But, nothing prevents anybody from programming in C++ the way you describe,
using simple and clear core structures with some basic methods that
complement them (not obscure them) and make it easier to write the
algorithms.
Sadly, once you start using std::string, their overly complicated and fancy
iostreams, and bulky classes that hide too much from you, I have no other
choice than to agree and call the whole thing a mess.
Steven Burns
"Linus Torvalds" [off-list ref] wrote in message
news:alpine.LFD.0.999.0709070203200.5626@evo.linux-foundation.org...
On Fri, 7 Sep 2007, Linus Torvalds wrote:
quoted
The fact is, git is better than the other SCM's. And good taste (and C)
is
one of the reasons for that.
To be very specific:
- simple and clear core datastructures, with *very* lean and aggressive
code to manage them that takes the whole approach of "simplicity over
fancy" to the extreme.
- a willingness to not abstract away the data structures and algorithms,
because those are the *whole*point* of core git.
And if you want a fancier language, C++ is absolutely the worst one to
choose. If you want real high-level, pick one that has true high-level
features like garbage collection or a good system integration, rather than
something that lacks both the sparseness and straightforwardness of C,
*and* doesn't even have the high-level bindings to important concepts.
IOW, C++ is in that inconvenient spot where it doesn't help make things
simple enough to be truly usable for prototyping or simple GUI
programming, and yet isn't the lean system programming language that C is
that actively encourags you to use simple and direct constructs.
Linus
From: Steven Burns <hidden> Date: 2016-06-15 22:43:35
a = b + "/share/" + c + serial_num;
where you can have absolutely no idea how many memory allocations are
done, due to type coercions, overloaded operators
You are assuming (incorrectly) everybody will use dumb string classes like
that.
It is very possible to create a string class that instead of allocating all
those strings simply concatenates tiny temporary objects and performs one
single operation in the end. Not to mention those temporaries are optimized
away by any decent compiler and you end up with code that runs at the same
speed as your C code.
I've done it, many other programmers have. As a reference, I'd like to
mention Matthew Wilson's chapter on efficient string concatenation in his
book "Imperfect C++". He uses expression templates (that's the technique I
just described) and gets impressive results.
With that said, your point is valid. 90% of C++ programmers will use string
classes that are very inefficient for concatenation, starting with
std::string which I hate for that reason (and many other reasons, e.g. you
have to
resort to Boost for mundane things like trimming)
Steven Burns
"Theodore Tso" [off-list ref] wrote in message
news:20070907061554.GB30161@thunk.org...
On Thu, Sep 06, 2007 at 08:09:23PM -0700, Dmitry Kakurin wrote:
quoted
quoted
Total BS. The string/memory management is not at all relevant. Look at
the
code (I bet you didn't). This isn't the important, or complex part.
Not only have I looked at the code, I've also debugged it quite a bit.
Granted most of my problems had to do with handling paths on Windows
(i.e. string manipulations).
I consider string manipulation to be one of the places where C++ is a
total disaster. It's way to easy for idiots to do something like this:
a = b + "/share/" + c + serial_num;
where you can have absolutely no idea how many memory allocations are
done, due to type coercions, overloaded operators (good God, you can
overload the comma operator in C++!!!), and then when something like
that ends up in an inner loop, the result is a disaster from a
performance point of view, and it's not even obvious *why*!
quoted
My goal is to *use* Git. When something does not work *for me* I want
to be able to fix it (and contribute the fix) in *shortest time
possible* and with *minimal efforts*. As for me it's a diversion from
my main activities.
Yes, and if you contribute something the shortest time possible, and
it ends up being crap, who gets to rewrite it and fix it? I've seen
too many C++ programs which get this kind of crap added, and it's not
noticed right away (because C++ is really good at hiding such
performance killers so they are not visible), and then later on, it's
even harder to find the performance problems and fix them.
quoted
Now, I realize that I'm a very infrequent contributor to Git, but I
want my opinion to be heard.
And if git were written in C++, it's precisely the infrequent
contributors (who are in a hurry, who only care about the quick hack
to get them going, and not about the long-term maintainability and
performance of the package) that are be in the position to do the
most damage...
- Ted
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:43:35
Steven Burns wrote:
quoted
a = b + "/share/" + c + serial_num;
where you can have absolutely no idea how many memory allocations are
done, due to type coercions, overloaded operators
You are assuming (incorrectly) everybody will use dumb string classes like
that.
Not really. He said "It's way to easy for idiots to do something like this:"
just prior to the line you quoted. I wholeheartedly agree, but in no way
does anyone assume that everybody will use dumb string classes.
I'm sure it's perfectly possible to write properly functioning programs in
C++. I know I use a few of them myself. That doesn't change the fact that
it's an idiot-friendly language to write code in that's extremely annoying
for competent programmers to fix up later.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Steven Burns <hidden> Date: 2016-06-15 22:43:36
Another reason GC is sometimes surprisingly faster is not only you end up
allocating less times like you mention, but because some GC are compacting
garbage collectors and that simplyfies allocations dramatically because
allocating memory is just increasing a pointer. Compare that to the way most
C++ heaps get implemented.
I don't know if that's the case with D's GC though.
I completely understand what you say about the strings and who owns it, I've
ran into the same situation a hundred times, not only with strings but with
vectors, matrixes, lists, etc.
After reading your post, I think I will have to revisit D sometime.
I read about it a few years ago and I got the impression some syntax
decisions had been made to ease the writing of the compiler as opposed to
favoring the end user/programmer, but it's been a while and maybe I was too
quick to judge.
Steven
"Walter Bright" [off-list ref] wrote in message
news:fbr2iv$ugg$1@sea.gmane.org...
Wincent Colaiuta wrote:
quoted
Git is all about speed, and C is the best choice for speed, especially in
context of Git's workload.
I can appreciate that. I originally got into writing compilers because my
game (Empire) ran too slowly and I thought the existing compilers could be
dramatically improved.
And technically, yes, you can write code in C that is >= the speed of any
other language (other than asm). But practically, this isn't necessarily
so, for the following reasons:
1) You wind up having to implement the complex, dirty details of things
yourself. The consequences of this are:
a) you pick a simpler algorithm (which is likely less efficient - I run
across bubble sorts all the time in code)
b) once you implement, tune, and squeeze all the bugs out of those
complex, dirty details, you're reluctant to change it. You're reluctant to
try a different algorithm to see if it's faster. I've seen this effect a
lot in my own code. (I translated a large body of my own C++ code that I'd
spent months tuning to D, and quickly managed to get significantly more
speed out of it, because it was much simpler to try out different
algorithms/data structures.)
2) Garbage collection has an interesting and counterintuitive consequence.
If you compare n malloc/free's with n gcnew/collections, the malloc/free
will come out faster, and you conclude that gc is slow. But that misses
one huge speed advantage of gc - you can do FAR fewer allocations! For
example, I've done a lot of string manipulating programs in C. The basic
problem is keeping track of who owns each string. This is done by, when in
doubt, make a copy of the string.
But if you have gc, you don't worry about who owns the string. You just
make another pointer to it. D takes this a step further with the concept
of array slicing, where one creates windows on existing arrays, or windows
on windows on windows, and no allocations are ever done. It's just pointer
fiddling.
------
Walter Bright
http://www.digitalmars.com C, C++, D programming language compilers
http://www.astoriaseminar.com Extraordinary C++
http://www.research.att.com/~bs/applications.html
just as Bjarne once wrote in his TC++PL, its hard to teach an old dog new
tricks. Its even harder to give quality education about how to use something
to someone who doesnt want to learn.
you hate high level, then continue programming operative systems, please NEVER
DO something else. C++ was designed to give programmers high level tools and
still being able to take care about performance.
portability wont be possible after a standard is published and some couple of
years given to the compiler developers. C++ had its standard in 1998, and add
two or three years for compiler development = 2002. "Quite recently", way more
recently that your last use of C++ I can bet.
From: David Kastrup <hidden> Date: 2016-06-15 22:43:36
figo [off-list ref] writes:
http://www.research.att.com/~bs/applications.html
just as Bjarne once wrote in his TC++PL, its hard to teach an old dog new
tricks. Its even harder to give quality education about how to use something
to someone who doesnt want to learn.
you hate high level, then continue programming operative systems,
please NEVER DO something else. C++ was designed to give programmers
high level tools and still being able to take care about
performance.
portability wont be possible after a standard is published and some
couple of years given to the compiler developers. C++ had its
standard in 1998, and add two or three years for compiler development
= 2002. "Quite recently", way more recently that your last use of C++
I can bet.
Care to explain why there are still not two numerical C++ libraries
with compatible matrix classes?
What use is talking about portability and high level when a basic
interoperability feature that has been available since the sixties
(more than 4 decades ago) in Fortran has not yet managed to make it
into C++? C++ by now more or less offers a (somewhat deficient)
standardized way to work with complex numbers, but matrices are still
not standardized in any manner, and libraries won't interoperate.
So C++ should get its head wrapped around the _low_ level problems
first. It is a bloody shame that it still has not caught up with
Fortran IV (or even Fortran II) with regard to usefulness for
numerical libraries.
It is not a matter of "hating high level" to see that C++ is mostly
focused about addressing the wrong kinds of problems in the wrong
ways. The pain/gain ratio is just bad.
--
David Kastrup
From: Steven Burns <hidden> Date: 2016-06-15 22:43:36
The C++ community in general suffers a lot from the NIH Syndrome.
Matrixes, Strings, Vectors, everybody creates their own which are always, or
course, superior to what's already available.
Again, is not the language's fault, a language is just a language.
It's the way it has been driven.
My two cents.
"David Kastrup" [off-list ref] wrote in message
news:86odfstbc6.fsf@lola.quinscape.zz...
figo [off-list ref] writes:
quoted
http://www.research.att.com/~bs/applications.html
just as Bjarne once wrote in his TC++PL, its hard to teach an old dog new
tricks. Its even harder to give quality education about how to use
something
to someone who doesnt want to learn.
you hate high level, then continue programming operative systems,
please NEVER DO something else. C++ was designed to give programmers
high level tools and still being able to take care about
performance.
portability wont be possible after a standard is published and some
couple of years given to the compiler developers. C++ had its
standard in 1998, and add two or three years for compiler development
= 2002. "Quite recently", way more recently that your last use of C++
I can bet.
Care to explain why there are still not two numerical C++ libraries
with compatible matrix classes?
What use is talking about portability and high level when a basic
interoperability feature that has been available since the sixties
(more than 4 decades ago) in Fortran has not yet managed to make it
into C++? C++ by now more or less offers a (somewhat deficient)
standardized way to work with complex numbers, but matrices are still
not standardized in any manner, and libraries won't interoperate.
So C++ should get its head wrapped around the _low_ level problems
first. It is a bloody shame that it still has not caught up with
Fortran IV (or even Fortran II) with regard to usefulness for
numerical libraries.
It is not a matter of "hating high level" to see that C++ is mostly
focused about addressing the wrong kinds of problems in the wrong
ways. The pain/gain ratio is just bad.
--
David Kastrup
From: David Kastrup <hidden> Date: 2016-06-15 22:43:36
"Steven Burns" [off-list ref] writes:
The C++ community in general suffers a lot from the NIH Syndrome.
Matrixes, Strings, Vectors, everybody creates their own which are always, or
course, superior to what's already available.
Again, is not the language's fault, a language is just a language.
It's the way it has been driven.
Having loose wires instead of a brake pedal in a car because the user
might prefer to brake with his teeth or by wiggling his backside or
building any other contraption of his own invention is a design
mistake. Especially when we are talking about public transportation
with changing drivers.
Making a language huge and bloated in order to be able to use the
language itself for defining a set of basic data types is just
masturbation. C++ has the most complicated set of implicit
conversions from any language in the world, and what for? It is
modeled for being able to create a user-defined "complex" type which
behaves almost as well as Fortran's. Too bad that this mostly means
everybody will define his own type (well, at least we have seen two or
three different library "standards" by now), and that the implicit
conversion rules and chains are appallingly wrong for a number of
other possible user-defined arithmetic types.
--
David Kastrup
Walter Bright <boost <at> digitalmars.com> writes:
Sure, but I suggest that few projects reach this maxima. Case in point:
ld, the gnu linker. It's terribly slow. To see how slow it is, compare
it to optlink (the 15 years old one that comes with D for Windows). So I
don't believe there is anything inherent about linking that should make
ld so slow. There's some huge leverage possible in speeding up ld
(spreading out that saved time among all the gnu developers).
http://en.wikipedia.org/wiki/Gold_(linker)
Note that gold is written in C++; the wikipedia quasi-stub article doesn't make
this clear. Normally that wouldn't be relevant, but in this branch of the
thread it is. Its C++-ness seems to be making an argument, but I don't know on
which side!
[ snip ]
When I first looked at Git source code two things struck me as odd:
1. Pure C as opposed to C++. No idea why. Please don't talk about
portability, it's BS.
Word to the wise... you effectively just told one of *the* best known
programmers of all time that they are talking BS... nice one. Hope you've got
some flameproof undies. Whats that? no? ah well...
I smell a troll, but since everyone else has had a go...
Heres some comments picked out from the thread, in no particular order...
quoted
You have a very strange way of not meaning to start a C vs. C++ war.
I honestly didn't. I didn't even think it's possible. In the
environment of mainstream commercial software development the last war
on this subj was over 8-10 years ago.
Really? I dont know what planet you're from, but this 'war' has been raging for
decades, and will probably continue until one side or the other gets round to
using tactical nukes.
And besides, this *isn't* the commercial (closed) software world - we've moved
on. We no longer depend on closed companies handing out features like orphans in
the Victorian times...
quoted
quoted
[bitfields in D]
quoted
Really, I feel this is a big lack, for a language that aims at
simplicity, conciseness _and_ correctness.
OK, maybe I'm biased, I work with networks protocols all day long, so
I often need bitfields, but still, a lot of people deal with network
protocols, it's not a niche.
And strictly speaking, C bitfields are completely useless for that
purpose since the compiler is free to use whatever method he wants for
allocating bit fields. So if you want to write a portable program,
you are back to making the masks yourself.
Sadly. Thats always been one of the things I found annoying in C. There are
times when you want access to the types the hardware itself uses, and there are
times when you want to know your int is 32 bits long, and there isnt really a
standardised way of doing that. Of course, its worked around in practice, but it
all seems so unnecessary.
in the *real world* rewriting Git in assembly would be like
painting a house using a single horse hair instead of a paint brush
or roller. Your SHA-1 example is a perfect example of where you
benefit from doing a tiny embellished detail using the single hair
(assembly) and leave all the rest in C.
The above comment is pure epic win :-)
On another note, some people talked about code reuse...
IMHO Sourcecode reuse is something of a myth in any language. Sure, some small
algorithms get reused, but thats really not a language dependent characteristic.
As soon as you build something much bigger than an algorithm, it starts to need
an interface, and at that point you may as well turn it into a library. Thats
where the REAL code reuse happens. And as it happens at runtime, its good for
users - bugfixes help everyone.
On to language choice...
I have NEVER understood why people seem to think theres some kind of hierarchy
in either ease of coding or speed. You see it all the time, people think that:
assembler is faster than c is faster than c++ is faster than perl etc.
WHY? I've seen some truely braindamaged assembler that could be outperformed by
BASIC on a BBC micro. I've seen 'handcrafted' C and C++ that looked like it was
written during a skydive whilst on crack.
languages are *tools*. Pick the most appropriate. Use two. Embrace the power of
and...
Linux make good use of C and assembler, both compiled/assembled seperately and
inline. Some stuff like accessing weird registers with oddball opcodes is
actually impossible under C. But (say) write a filesystem in assembler? no
thanks! (not that it hasn't been done, but for the love of god, why?)
So, anyway, why do these kind of threads never go away? because opinions are
like arseholes. Everyones got one. As you grow older, you learn stuff. You
hopefully dont repeat the mistakes of ones youth. (theres at least one
ill-conceived C string library out there which I'm embarrased to admit is my
fault (hopefully it'll never leave the company I was at when I wrote it...).
These threads are where the n00bs meet the pros. Usually, the n00bs just need to
suck it up and admit it when they've been dumb. Its a very rare day when
something truely radical comes along, and its even rarer when its born of total
inexperience.
Nothing to see here...
All the best,
-Ian
PS. ironically, in order to post this, gmane required me to enter a word. That
word was "restraint". Gotta love karma.
[ snip ]
When I first looked at Git source code two things struck me as odd:
1. Pure C as opposed to C++. No idea why. Please don't talk about
portability, it's BS.
No gain from C++.
Also, I don't know when Dmitri written his post, but git uses its own
string manipulation mini-library, named strbuf, at least since end of 2007
(Documentation/technical/api-strbuf.txt was added as stub on 2007-11-24).
quoted
in the *real world* rewriting Git in assembly would be like
painting a house using a single horse hair instead of a paint brush
or roller. Your SHA-1 example is a perfect example of where you
benefit from doing a tiny embellished detail using the single hair
(assembly) and leave all the rest in C.
Sidenote: block-sha1 implementation is C plus smidgeon of assembly via
'asm'.
--
Jakub Narebski
Poland
ShadeHawk on #git
On Fri, Jun 11, 2010 at 9:23 AM, Jakub Narebski [off-list ref] wrote:
Also, I don't know when Dmitri written his post, but git uses its own
string manipulation mini-library, named strbuf, at least since end of 2007
(Documentation/technical/api-strbuf.txt was added as stub on 2007-11-24).
An interesting point, Dmitri written this post on September 2007...
why the flamewar continuation? just curiosity...
Now, as a resume of flames and concepts, the 'better' things in the
string library (also the first excuse for C++ apologists, as a
repetitive piece of youknowwhat) are pure algorithms and data
structures, easy to code in C. The goal isn't in the OO design or
abstraction itself, or in the language...
Personally, I use C++ almost every day at work and I found it stupid.
I love pure C.
Cheers,
Dario (argentina)
When I first looked at Git source code two things struck me as odd:
1. Pure C as opposed to C++. No idea why. Please don't talk about port,
it's BS.
*YOU* are full of bullshit.
C++ is a horrible language. It's made more horrible by the fact that a lot
of substandard programmers use it, to the point where it's much much
easier to generate total and utter crap with it. Quite frankly, even if
the choice of C were to do *nothing* but keep the C++ programmers out,
that in itself would be a huge reason to use C.
Linus
C++ has one weakness that is ABI compatibility among compilers.
Other than that Object Model does not make things horrible.
I have seen 15 years old C++ application library which still
uses old implementation to implement new enhancement/features
that just works seamlessly and even an old dog can learn
this old library written in C++.
I have seen C programmers constantly trying how they can mimic
poly-morphism, inheritance and encapsulation in their C.
This is just *BS* - if you dont want C++ then dont use poly-morphism,
inheritance and encapsulation in your C code!
Or else just use C++ or Jave or C#.
Regards
Please note: I am really a Fan of Linus Torvalds since ever :)
Syed Raihan