From: tlaronde@polynum.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: Tue, 30 Oct 2012 09:07:07 +0100 [thread overview]
Message-ID: <20121030080707.GB548@polynum.com> (raw)
In-Reply-To: <20121029232652.5160BB827@mail.bitblocks.com>
On Mon, Oct 29, 2012 at 04:26:52PM -0700, Bakul Shah wrote:
>
> Best way to save developer time is to program in a HLL and not
> worry about bit fiddling. C is not a HLL.
The HLL will have to have a compiler. If the compiler is, finally,
machine instructions, how does one guarantee that it does exactly what
intended on different architectures. If the next level language, near
machine but high level is used---it's C---you are relying on what you
wanted to escape from...
The only mean to be sure is to have a HLL that allows only HL
instructions, like macroscopic, due to its complexity, escapes from the
uncertainty of quantics effects. This is to say, the language will not
allow you to do everything.
The practical solution is to have a language that is near the machine,
sufficiently abstracted from the machines that assembly is scarcely
needed, with some small set of primitives, a small manual, a clear
(once again: small) set of what is guaranteed and caveats about
what is not, and let the programmer decide without the compiler
"guessing" or improving---and a way of writting sources so that a
programmer can optimize his code on this level (this is litterate
programming). C was very near a perfect practical
solution; C89 was not bad; C99 has improved some things but added
too many things on the border (where there is already uncertainty
about what has to be done because "it depends").
--
Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
next prev parent reply other threads:[~2012-10-30 8:07 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
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 [this message]
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=20121030080707.GB548@polynum.com \
--to=tlaronde@polynum.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).