From: Pierre Habouzit <email@example.com> To: Andreas Ericsson <firstname.lastname@example.org> Cc: Walter Bright <email@example.com>, firstname.lastname@example.org Subject: Re: [RFC] Convert builin-mailinfo.c to use The Better String Library. Date: Sun, 09 Sep 2007 02:37:18 +0200 [thread overview] Message-ID: <20070909003718.GE13385@artemis.corp> (raw) In-Reply-To: <46E3354A.email@example.com> [-- Attachment #1: Type: text/plain, Size: 4510 bytes --] On Sat, Sep 08, 2007 at 11:50:34PM +0000, Andreas Ericsson wrote: > Walter Bright wrote: > > David Kastrup wrote: > > > Again, C won't keep you from shooting yourself in the foot. > > Right, it won't. A good systems language should do what it can to > > prevent the programmer from *inadvertently* shooting himself in the > > foot, while allowing him to *deliberately* shoot himself in the foot. > > No, a good systems language should do exactly what it's told. > Supporting tools should tell the programmer if he's risking shooting > himself in the foot. I beg to differ. I mean, knowing enough of D, I think that what Walter tries to say is that a good language should provide constructions that when used prevent the programmer to shoot himself in both foot at the same time. D supports most of the C constructions, so when you want to juggle with razor blades, you're free to do so in D. Though, the language provides idioms that prevent you to write stupid mistakes when used. And that is great. D is not Java, you have pointers, you can deal with memory explicitely, you can do whatever you can do in C with no or very little overhead. Or you can use higher level D, at your own discretion. > > > You can tell C compilers to > > > check all array accesses, but that is a performance issue. > > Runtime checking of arrays in D is a performance issue too, so it is > > selectable via a command line switch. > > Same as in C then. HAHAHAHAHAHA. Please, who do you try to convince here ? Except in the local scope, there is few differences between a foo* and a foo in C. > > But more importantly, > > 2) For dynamically sized arrays, the dimension of the array is carried > > with the array, so loops automatically loop the correct number of times. > > No runtime check is necessary, and it's easier for the code reviewer to > > visually check the code for correctness. > > But this introduces handy but, strictly speaking, unnecessary overhead > as well, meaning, in short; 'D is slower than C, but easier to write > code in'. That's BS. See the strbuf API I've been pushing recently ? It has simplified git's code a lot, because each time git had to deal with a growing string, it had to deal with at least three variables: the buffer pointer, the current occupied length, and its allocated size. That was three thing to have variable names for, and to pass to functions. Now instead, it's just one struct. D gives that gratis. There is no performance loss because you _need_ to do the same. How do you deal with dynamic arrays if you dont't store their lenght and size somewhere ? Or are you the kind of programmer that write: /* 640kb should be enough for everyone… */ some_type *array = malloc(640 << 10); > So in essence, it's a bit like Python, but a teensy bit faster and a > lot easier to shoot yourself in the foot with. > What was the niche you were going for when you thought up D? It can't > have been systems programming, because *any* extra baggage is baggage > one would like to get rid of. If it was application programming I fail > to see how one more language would help, as there will be portability > problems galore and it's still considerably slower to develop in than > fe Python, while at the same time being considerably easier to mess up > in. Right now I'm just laughing. There is for sure overheads in some places of D, but the example you take, and what you try to attack in D is definitely not where you lose any kind of performance. You could have attacked the GC instead (which is after all an easy classical target). Just to evaluate the silliness of your arguments: * http://www.digitalmars.com/d/comparison.html so that you can tell what the D features really are, * http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all so that you can know what the D performance really is about. Of course those are only micro benchmarks, but well, python is "just" 15 times slower than D, and D seems to be 10% slower. Well then I'm okay with D, I'm ready to buy 10% faster CPUs and avoid a lot of painful debugging time. In my world, 10% faster hardware is cheaper by many orders of magnitude than skilled programmers, but YMMV. -- ·O· Pierre Habouzit ··O firstname.lastname@example.org OOO http://www.madism.org [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-09-09 8:43 UTC|newest] Thread overview: 102+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-09-04 20:50 Lukas Sandström 2007-09-04 21:38 ` Alex Riesen 2007-09-04 23:01 ` Pierre Habouzit 2007-09-05 14:54 ` Kristian Høgsberg 2007-09-05 17:29 ` Matthieu Moy 2007-09-06 2:30 ` Miles Bader 2007-09-06 4:48 ` Dmitry Kakurin 2007-09-06 4:59 ` Shawn O. Pearce 2007-09-06 9:12 ` Andreas Ericsson 2007-09-06 9:35 ` Junio C Hamano 2007-09-06 10:21 ` Andreas Ericsson 2007-09-06 9:52 ` David Kastrup 2007-09-06 5:03 ` Miles Bader 2007-09-06 12:08 ` Johannes Schindelin 2007-09-06 17:50 ` Linus Torvalds 2007-09-07 0:21 ` Dmitry Kakurin 2007-09-07 0:38 ` Linus Torvalds 2007-09-07 1:08 ` Dmitry Kakurin 2007-09-07 1:27 ` Linus Torvalds 2007-09-07 3:09 ` Dmitry Kakurin 2007-09-07 5:48 ` David Symonds 2007-09-07 6:15 ` Theodore Tso 2007-09-20 14:06 ` Steven Burns 2007-09-20 14:56 ` Andreas Ericsson 2007-09-07 6:31 ` Andreas Ericsson 2007-09-07 22:17 ` Dmitry Kakurin 2007-09-07 22:28 ` David Kastrup 2007-09-08 0:37 ` Dmitry Kakurin 2007-09-08 6:25 ` David Kastrup 2007-09-09 0:29 ` Andreas Ericsson 2007-09-07 6:52 ` David Kastrup 2007-09-07 10:28 ` Johannes Schindelin 2007-09-07 10:26 ` Johannes Schindelin 2007-09-07 6:50 ` David Kastrup 2007-09-07 1:12 ` Linus Torvalds 2007-09-07 1:40 ` alan 2007-09-07 5:09 ` Walter Bright 2007-09-07 7:40 ` David Kastrup 2007-09-07 8:15 ` Walter Bright 2007-09-07 8:26 ` David Kastrup 2007-09-07 9:14 ` Walter Bright 2007-09-07 9:31 ` David Kastrup 2007-09-07 20:22 ` Walter Bright 2007-09-07 20:27 ` David Kastrup 2007-09-07 23:16 ` Walter Bright 2007-09-08 23:50 ` Andreas Ericsson 2007-09-09 0:37 ` Pierre Habouzit [this message] 2007-09-09 1:36 ` Andreas Ericsson 2007-09-07 11:36 ` Wincent Colaiuta 2007-09-07 9:41 ` Pierre Habouzit 2007-09-07 19:03 ` Walter Bright 2007-09-07 19:31 ` David Kastrup 2007-09-07 20:49 ` Walter Bright 2007-09-07 19:41 ` Pierre Habouzit 2007-09-07 19:51 ` David Kastrup 2007-09-07 19:59 ` Pierre Habouzit 2007-09-07 20:40 ` Walter Bright 2007-09-07 20:56 ` Pierre Habouzit 2007-09-07 22:54 ` Walter Bright 2007-09-08 0:56 ` John 'Z-Bo' Zabroski 2007-09-08 6:36 ` David Kastrup 2007-09-19 19:56 ` Steven Burns 2007-09-07 3:06 ` Wincent Colaiuta 2007-09-07 4:06 ` Paul Wankadia 2007-09-07 4:30 ` Nicolas Pitre 2007-09-07 9:19 ` Wincent Colaiuta 2007-09-07 6:25 ` Andreas Ericsson 2007-09-07 10:56 ` Johannes Schindelin 2007-09-07 11:54 ` Andreas Ericsson 2007-09-07 12:33 ` Wincent Colaiuta 2007-09-07 12:55 ` Karl Hasselström 2007-09-07 13:58 ` Andreas Ericsson 2007-09-07 14:13 ` Wincent Colaiuta 2007-09-09 0:09 ` Andreas Ericsson 2007-09-07 16:09 ` David Kastrup 2007-09-07 11:30 ` Wincent Colaiuta 2007-09-07 8:36 ` Walter Bright 2007-09-07 9:41 ` Andreas Ericsson 2007-09-07 19:23 ` Walter Bright 2007-09-07 19:40 ` David Kastrup 2007-09-09 0:25 ` Andreas Ericsson 2009-09-17 16:23 ` Bernd Jendrissek 2007-09-07 11:52 ` Wincent Colaiuta 2007-09-07 19:25 ` Walter Bright 2007-09-22 16:52 ` Steven Burns 2007-09-07 6:47 ` David Kastrup 2007-09-07 7:41 ` Andy Parkins 2007-09-07 8:08 ` David Kastrup 2007-09-07 10:21 ` Johannes Schindelin 2007-09-08 0:32 ` Dmitry Kakurin 2007-09-08 6:24 ` David Kastrup 2007-09-08 23:25 ` Alex Riesen 2007-09-24 13:41 ` figo 2007-09-24 13:57 ` David Kastrup 2007-09-25 19:19 ` Steven Burns 2007-09-25 19:55 ` David Kastrup 2012-05-22 18:30 ` Syed M Raihan 2010-06-10 19:12 ` Ian Molton 2010-06-11 12:23 ` Jakub Narebski 2010-06-11 13:33 ` Dario Rodriguez 2007-09-05 15:27 ` Kristian Høgsberg 2007-09-07 10:47 ` Lukas Sandström
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20070909003718.GE13385@artemis.corp \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).