From: Bakul Shah <bakul@bitblocks.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] caveat... optimizer? the `zero and forget' thread on HN
Date: Mon, 29 Oct 2012 17:52:48 -0700 [thread overview]
Message-ID: <20121030005248.65C58B827@mail.bitblocks.com> (raw)
In-Reply-To: Your message of "Mon, 29 Oct 2012 23:58:23 -0000." <CAOw7k5hiQtCi=A8q5GL7-c_g1ZurVm2BMxbVE2kxXsFMxec5XQ@mail.gmail.com>
On Mon, 29 Oct 2012 23:58:23 -0000 Charles Forsyth <charles.forsyth@gmail.com> wrote:
>
> "But my point was that a programmer should understand the standard"
>
> But suppose the standard does not evidently aim to be understood, in the
> generally understood meaning of "understood",
> or there are more words in the standard than will ever appear in the
> programmer's own programs?
The C standard is not too hard to understand. For something
worse try one of those ITU standards! Try IEEE 802 standards!
I have had to read the Bridging standard many many more times
(compared to the C standard) to make sense of it. The
standards *shouldn't* be so horrible but they are. And one
does what is needed to get the job done.
> Worse! "Standard" doesn't imply a fixed point ("oh, that syntax/semantics
> is so last year!").
> I think looking into memset and deciding it's not worthwhile calling is
> perhaps overly enthusiastic.
I ask again. Who decides where the line is drawn? I think that
in a competitive environment the only thing that can restrain
people is the standard. Unfortunately.
> Actually, it's wrong, because it overlooks the side-effect, and an
> optimiser for a language with side-effects
> should take that into account.
They put in "volatile" to ensure side-effects happen. Hasn't
worked too well.
next prev parent reply other threads:[~2012-10-30 0:52 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-29 9:45 dexen deVries
2012-10-29 10:12 ` tlaronde
2012-10-29 13:43 ` erik quanstrom
2012-10-29 13:35 ` erik quanstrom
2012-10-29 22:35 ` Bakul Shah
2012-10-29 22:47 ` Charles Forsyth
2012-10-29 23:05 ` Bakul Shah
2012-10-29 23:07 ` erik quanstrom
2012-10-29 23:15 ` David Leimbach
2012-10-29 23:20 ` erik quanstrom
2012-10-29 23:53 ` andrey mirtchovski
2012-10-29 23:59 ` Kurt H Maier
2012-10-29 23:10 ` erik quanstrom
2012-10-29 23:26 ` Bakul Shah
2012-10-29 23:31 ` Bakul Shah
2012-10-29 23:36 ` erik quanstrom
2012-10-29 23:58 ` Charles Forsyth
2012-10-30 0:52 ` Bakul Shah [this message]
2012-10-30 1:01 ` erik quanstrom
2012-10-30 7:55 ` tlaronde
2012-10-30 0:35 ` Bakul Shah
2012-10-30 1:10 ` erik quanstrom
2012-10-30 3:06 ` Bakul Shah
2012-10-30 3:16 ` Corey Thomasson
2012-10-30 13:08 ` erik quanstrom
2012-10-30 15:15 ` arnold
2012-10-30 1:46 ` cinap_lenrek
2012-10-30 1:21 ` Kurt H Maier
2012-10-30 8:07 ` tlaronde
2012-10-30 10:26 ` Richard Miller
2012-10-30 10:39 ` dexen deVries
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121030005248.65C58B827@mail.bitblocks.com \
--to=bakul@bitblocks.com \
--cc=9fans@9fans.net \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 NNTP newsgroup(s).