+1

--- On Wed, 6/8/11, Theo de Raadt <dera...@cvs.openbsd.org> wrote:

From: Theo de Raadt <dera...@cvs.openbsd.org>
Subject: Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest,
atleast on embedded systems.
To: "Nicholas Marriott" <nicholas.marri...@gmail.com>
Cc: "Thomas de Grivel" <billi...@gmail.com>, "Christiano F. Haesbaert"
<haesba...@haesbaert.org>, "misc@openbsd.org" <misc@openbsd.org>
Date: Wednesday, June 8, 2011, 3:10 AM

> You are either trolling or just very mixed up, the important thing is
> not how quickly machines can parse it or how quickly you can write a
> lexer but how quickly humans can parse it and what they can do with
> it. C is not the best here but it is way ahead of any kind of useless
> functional language.

Indeed.

People write in languages they can understand, just like we are
emailing in a language we can all understand.  English sucks, yet we
all use it.  Why are you not trying to miscommunicate with us in
dutch, Mr. de Grivel?  Because it would fail (though you probably
speak the perfect langauge of gmail).  You fail anyways since you come
off as a salesman of a perfection mythos.

When we start writing something in C or any other language, we are
writing a chunks of interface code and chunks of data management code.
We layer the code using "interfaces" we decide on very early so that
it is easier to determine where the bugs are, at least early on.
However almost every time the interface decisions made early on carry
on far into the future and eventually screw us.  We fix all the data
management bugs, and then the interface layers end up being flawed.
Subtly, but flawed.  They are our next problem.  Then when we try to
fix them, we introduce new subtle problems.  However here is where you
are entirely wrong: C is not different.  All the languages are like
that.

That is because we write in the way that we think, and the way we
think is biased towards the way we remember.  Why the way we remember?
That is so that when we see the code again, we can remember what we
were thinking.  When we make changes in any of them to fix a
structural problem, we start to forget layers of our previous
thoughts.  It becomes less recognizeable.

No language or programming system designed to this day is flexible
enough so that we can remember the steps of our thought process, and
yet also be flexible enough that it allows us to change the interfaces
(without us not remembering it next time; the process is highly
iterative).

And then some details make it even gets worse.  We are trying to
develop userland programs, and libraries, and the portable include
infrastructable managing the variation chaos between 32 bit and 64 bit
and signed char vs unsigned char and whatnot layers of variaion; and
we are trying to writing boot code, and we are writing kernels to run
all this.  Add in the bullshit we support it the ports subsystem, and
it is no wonder our brains are struggling.

When someone tells anyone that there is an answer and some cohesive
language will solve this is problem... they are flat out deluded and
that delusion comes out of blind stupidity.  You obviously have zero
experience.  The only thing you have experience in is trolling mailing
lists acting as if you are some expert.

The real experts are the people struggling with these systems, not the
pulpit heros.

Reply via email to