OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.

Thomas de Grivel-2
Before even thinking of "fixing it" i'm trying to see if i'm alone in my
quest. I like code correctness and feel what's done in OpenBSD is epic given
the shitty language all the devs are dealing with. I love this much epic.

Now if you want to know what code I'm writing, first I'm writing english
because as you can see when a bring s-exp i'm answered "asm" and
"brainfuck". Seriously did you even google the thing ?

And i never criticized the semantics of the code. Just that it's a 1 month
project to build a fudgy C lexer, when parsing s-exp is more powerful and
takes 2 days while watching pr0n, and 2 hours without.

This is clearly off topic, and don't mean to rewrite an OS but there clearly
is a need for cleaner programming languages in this world. I used to love C
and i'm still quite proficient at it but when i had a glimpse of Lisp i
realized how narrow was my vision of programming. And how much i trusted the
languages i used to mean something.

Reply | Threaded
Open this post in threaded view
|

Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.

Ariane van der Steldt
On Tue, Jun 07, 2011 at 12:08:26PM +0200, Thomas de Grivel wrote:
> Before even thinking of "fixing it" i'm trying to see if i'm alone in my
> quest. I like code correctness and feel what's done in OpenBSD is epic given
> the shitty language all the devs are dealing with. I love this much epic.

I don't consider C to be a shitty language... It's very suitable for
writing code that does what I expect from it and to maintain that code.
That's what I want from a language.

> Now if you want to know what code I'm writing, first I'm writing english
> because as you can see when a bring s-exp i'm answered "asm" and
> "brainfuck". Seriously did you even google the thing ?

What wikipedia turns up is lisp. It reads awful.
The purpose of a programming language is to enable reading and writing
of code. It's hard enough to understand what code does without having to
build a full parser in my brain.

I can see how S-expressions are nice to use in a proof. However it's
useless to me, since I'm trying to get work done. If I need to proof
something, it's the code I wrote. If I require a big conversion from
written code to something completely different, I am likely to introduce
mistakes thereby invalidating any proofs.
Likewise, when I want to deduct an algorithm, I prefer to write it in a
langauge as close to the implementation language as possible. Again to
minimize errors in the conversion between proof and real code.

If you wish to proof code, either do it directly or use a language that
closely resembles the imlementation language.

> And i never criticized the semantics of the code. Just that it's a 1 month
> project to build a fudgy C lexer, when parsing s-exp is more powerful and
> takes 2 days while watching pr0n, and 2 hours without.

And this is where the beauty of programming really shines: that C parser
has been written a long time ago and works. We don't reimplement a new C
parser every release. :)

> This is clearly off topic, and don't mean to rewrite an OS but there clearly
> is a need for cleaner programming languages in this world. I used to love C
> and i'm still quite proficient at it but when i had a glimpse of Lisp i
> realized how narrow was my vision of programming. And how much i trusted the
> languages i used to mean something.

Language is a vehicle to translate the ideas in my head to something the
computer understands. For kernel and userland programming, C is not just
adequate, it fulfills alot of our needs.

Especially for kernel work, we want to be able to predict memory and
runtime characteristics. Since C is very close to the underlying
assembler, those characteristics are easily deducted.


I have a question for you. You like S-expressions, because they
are easy to proof. But how often have you actually proven the code you
wrote?

In the real world, code is rarely proven. It's a lot of work, therefore
expensive. And the proof depends on underlying functions (libraries,
like the C library and systems calls, for instance) to be correct, your
assumptions about how they function to be correct and to not change
in a way as to invalidate your earlier assumptions.

What we try instead is to provide an environment where a bug will be
triggered early, often and resulting in a crash. This is important to
fix bugs: bugs only get hunted down and fixed when a failure hints at
them. When we talk about providing a hostile environment to code, this
is what we mean: making the environment as hostile as possible to bugs.


In this thread, I see complaints that C is hard to parse and prove, but
that's bollocks. C is a list of statements, which can be converted to
whatever that proof checker needs. The problem with proof checkers, is
that they need assistence. And you can't give that assistence without
doing the steps that the program is designed to do for you.

Example: the uvm_map_entry_link macro from sys/uvm/uvm_map.c before vmmap:
        (map)->nentries++;
        (entry)->prev = (after_where);
        (entry)->next = (after_where)->next;
        (entry)->prev->next = (entry);
        (entry)->next->prev = (entry);
This is C, but it's easy to transform to GCL, if you want something that
has proof rules defined.
        map->nentries := map->nentries + 1;
        entry->prev := after_where;
        entry->next := after_where->next;
        entry->prev->next := entry;
        entry->next->prev := entry;
But if you want to prove this is correct, you first need to define the
pre condition
        { map->nentries = (#x : x in map->entries) and
          (all x : x in map->entries :
              (x->next != NULL -> x->next->prev = x) and
              (x->prev != NULL -> x->prev->next = x)) and
          entry not in map->entries
        }
and the post condition
        { map->nentries = (#x : x in map->entries) and
          (all x : x in map->entries :
              (x->next != NULL -> x->next->prev = x) and
              (x->prev != NULL -> x->prev->next = x)) and
          entry in map->entries
        }
You can't deduct the pre and post condition, because they are what is to
be proven.
Now you need to apply each statement, updating the condition and verify
that pre condition + all mutations reaches the post condition.

This is a very trivial piece of code and it's easy to spot that this is
a manually implemented doubly linked list. But only writing down the
pre and post condition costs me more space than the snippet itself.
Not to mention that the time spent thinking them up cost me more time
than writing the original code.

Note that the proof checker cannot use this, since it has no idea how to
traverse the map->entries collection (which does not exist, since it
depends on map->header being the first and last element in that
collection instead).
--
Ariane

Reply | Threaded
Open this post in threaded view
|

Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.

Christiano F. Haesbaert
In reply to this post by Thomas de Grivel-2
On 7 June 2011 07:08, Thomas de Grivel <[hidden email]> wrote:
> Before even thinking of "fixing it" i'm trying to see if i'm alone in my
> quest. I like code correctness and feel what's done in OpenBSD is epic given
> the shitty language all the devs are dealing with. I love this much epic.
>

Please, C is very far from shitty, C is wonderful, although not
perfect and not "easily-parseable".

> Now if you want to know what code I'm writing, first I'm writing english
> because as you can see when a bring s-exp i'm answered "asm" and
> "brainfuck". Seriously did you even google the thing ?
>

Check your facts again, and see who said what, I'm quite fond of scheme.

> And i never criticized the semantics of the code. Just that it's a 1 month
> project to build a fudgy C lexer, when parsing s-exp is more powerful and
> takes 2 days while watching pr0n, and 2 hours without.
>
> This is clearly off topic, and don't mean to rewrite an OS but there clearly
> is a need for cleaner programming languages in this world. I used to love C
> and i'm still quite proficient at it but when i had a glimpse of Lisp i
> realized how narrow was my vision of programming. And how much i trusted the
> languages i used to mean something.

You're just passing though a *phase*, that's ok, it happens to all of
us when we learn lisp.
I'd advice getting back to reality now.

Now, think again, parsing a language is nice, but it's almost never
the most important thing.
You also should not try to convert old school unix hackers into
lispers, there may be rape.

Reply | Threaded
Open this post in threaded view
|

Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.

Gilles Chehade-7
On Tue, Jun 07, 2011 at 11:19:11AM -0300, Christiano F. Haesbaert wrote:
>
> [...]
>
> Now, think again, parsing a language is nice, but it's almost never
> the most important thing.
> You also should not try to convert old school unix hackers into
> lispers, there may be rape.
>

s/may be/will be/

--
Gilles Chehade
http://www.poolp.org

Reply | Threaded
Open this post in threaded view
|

Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.

Nicholas Marriott-2
In reply to this post by Thomas de Grivel-2
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.


On Tue, Jun 07, 2011 at 12:08:26PM +0200, Thomas de Grivel wrote:

> Before even thinking of "fixing it" i'm trying to see if i'm alone in my
> quest. I like code correctness and feel what's done in OpenBSD is epic given
> the shitty language all the devs are dealing with. I love this much epic.
>
> Now if you want to know what code I'm writing, first I'm writing english
> because as you can see when a bring s-exp i'm answered "asm" and
> "brainfuck". Seriously did you even google the thing ?
>
> And i never criticized the semantics of the code. Just that it's a 1 month
> project to build a fudgy C lexer, when parsing s-exp is more powerful and
> takes 2 days while watching pr0n, and 2 hours without.
>
> This is clearly off topic, and don't mean to rewrite an OS but there clearly
> is a need for cleaner programming languages in this world. I used to love C
> and i'm still quite proficient at it but when i had a glimpse of Lisp i
> realized how narrow was my vision of programming. And how much i trusted the
> languages i used to mean something.

Reply | Threaded
Open this post in threaded view
|

Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.

Marco Peereboom
On Jun 7, 2011, at 19:46, Nicholas Marriott <[hidden email]>
wrote:

> 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.
>

C is superior; get used to it.

All languages invented after pretty much suck.  CS has been done a long time
ago. Most new shit is just that, new shit. Shiny and mostly worthless.

What the fuck ever about $language-du-jour.


>
> On Tue, Jun 07, 2011 at 12:08:26PM +0200, Thomas de Grivel wrote:
>> Before even thinking of "fixing it" i'm trying to see if i'm alone in my
>> quest. I like code correctness and feel what's done in OpenBSD is epic
given

>> the shitty language all the devs are dealing with. I love this much epic.
>>
>> Now if you want to know what code I'm writing, first I'm writing english
>> because as you can see when a bring s-exp i'm answered "asm" and
>> "brainfuck". Seriously did you even google the thing ?
>>
>> And i never criticized the semantics of the code. Just that it's a 1 month
>> project to build a fudgy C lexer, when parsing s-exp is more powerful and
>> takes 2 days while watching pr0n, and 2 hours without.
>>
>> This is clearly off topic, and don't mean to rewrite an OS but there
clearly
>> is a need for cleaner programming languages in this world. I used to love
C
>> and i'm still quite proficient at it but when i had a glimpse of Lisp i
>> realized how narrow was my vision of programming. And how much i trusted
the
>> languages i used to mean something.

Reply | Threaded
Open this post in threaded view
|

Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.

Theo de Raadt
In reply to this post by Nicholas Marriott-2
> 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 | Threaded
Open this post in threaded view
|

Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.

Super Biscuit
+1

--- On Wed, 6/8/11, Theo de Raadt <[hidden email]> wrote:

From: Theo de Raadt <[hidden email]>
Subject: Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest,
atleast on embedded systems.
To: "Nicholas Marriott" <[hidden email]>
Cc: "Thomas de Grivel" <[hidden email]>, "Christiano F. Haesbaert"
<[hidden email]>, "[hidden email]" <[hidden email]>
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 | Threaded
Open this post in threaded view
|

Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.

Thomas de Grivel-2
In reply to this post by Theo de Raadt
I'm not really selling anything. I'm seeing a deeply rooted bug in our
way of thinking programming languages. Struggling is not necessary
unless you want to punish yourself.

My experience, and I feel I have enough in C to speak untroubled, is
that not all languages are like C when it comes to laying out your
thoughts. I used to think so, all my mind was trapped in this. The
language is very well defined, but cannot understand itself. Cannot be
worked itself like we work other data, except with a gigantic piece of
software.

If the code does not reflect the layers of thoughts, of course it cannot
scale, or very slowly. You need good abstractions to solve complex
problems. And good data structure, C has that better than any other
language.

In CL I can speak my mind in terms of layers and these layers fit nice,
or are easy to fix because there is no duplicate code. This also means
very short code. This is not because of the semantics of the language, C
is much better defined at precise memory handling, but precisely because
part of the art of programming in s-exp is partly in generating the
uninteresting part of the code, or reading it with a function, checking
for some bug patterns.

I could try to explain it another way : we are compilers. We have ideas
we need to translate into C, knowing that in turn C will be compiled
into some behaviour of the system. That pipeline is broken when your
layers do not fit well into the language. To fix this we'd need macros
to generate code, but C macros generate not code but text ! How's that
in any way useful ?

Other hint debunks :
- CL is much much older than C. Again not talking about the semantics,
but at the time it was out, C compiler technology was really not state
of the art. Though it had much more focused semantics, which made it win
most system code.
- CL is not functional, it is procedural like C and can generate native
code.
- You can encode any language in s-exp. Actually this is done at AST
level though we cannot access it with these bulky C compilers.

The good features of lisp are just from symbolic expressions. What Theo
said remains true to all programming. How the language is processed is
what I'm talking about.

Any hacker not knowing a couple of Lisp macros is a waste of mind.

--
Thomas de Grivel

"I must plunge into the water of doubt again and again."

Reply | Threaded
Open this post in threaded view
|

Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.

Marc Espie-2
Like I said before, there is amply enough work in the ports tree for lisp
hackers.

Go work on porting clisp to other OpenBSD architectures. Give us something
concrete.  

Talk is very, very cheap.

Reply | Threaded
Open this post in threaded view
|

Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.

Super Biscuit
In reply to this post by Thomas de Grivel-2
I know neither C(++), or LISP, or PERL, or python or any other language.

I've worked on VirtualBox porting to FreeBSD.
I am working on GNOME3 on FreeBSD for ppc and sparc64 in my spare time.

No lisp, no c, no other language . This is just from being able to read and understand code.

I know how far emacspeak can be compiled on OpenBSD PPC and what is needed.

Many people can do what I do; but, I don't consider them a "waste of mind" as you do.
Your head is so far up your ass that you have a ring of shit for a necklace.






--- On Wed, 6/8/11, Thomas de Grivel <[hidden email]> wrote:

From: Thomas de Grivel <[hidden email]>
Subject: Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.
To: "[hidden email]" <[hidden email]>
Date: Wednesday, June 8, 2011, 10:23 AM

[Other shit removed to concentrate on the ignorance of the last line.]

Any hacker not knowing a couple of Lisp macros is a waste of mind.

-- Thomas de Grivel

"I must plunge into the water of doubt again and again."

Reply | Threaded
Open this post in threaded view
|

Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.

ramrunner
It was well said that when we learn lisp we all start thinking things
like that. ;)
As to what theo said about interfaces, of course it is correct, but on the other
hand (as a design tool) doesn't Hal Abelman on the SICP lectures say,
that it is
a powerfull techinique to be able to create interfaces that you forget
everything
about them afterwards? He goes on to demonstrate...

In my mind the thing boils down to this:
in the PC as it is structured (HW-wise) you can't impose functional programming
(at least in an elegant/meaningfull way). But if you consider as specially built
arch for executing LISP code as the Connection Machine (from thinking machines)
then it could get interesting ;)

and yes sorry for talking and not working on clisp :(

DsP

On Thu, Jun 9, 2011 at 6:38 AM, Super Biscuit <[hidden email]> wrote:

> I know neither C(++), or LISP, or PERL, or python or any other language.
>
> I've worked on VirtualBox porting to FreeBSD.
> I am working on GNOME3 on FreeBSD for ppc and sparc64 in my spare time.
>
> No lisp, no c, no other language . This is just from being able to read and understand code.
>
> I know how far emacspeak can be compiled on OpenBSD PPC and what is needed.
>
> Many people can do what I do; but, I don't consider them a "waste of mind" as you do.
> Your head is so far up your ass that you have a ring of shit for a necklace.
>
>
>
>
>
>
> --- On Wed, 6/8/11, Thomas de Grivel <[hidden email]> wrote:
>
> From: Thomas de Grivel <[hidden email]>
> Subject: Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.
> To: "[hidden email]" <[hidden email]>
> Date: Wednesday, June 8, 2011, 10:23 AM
>
> [Other shit removed to concentrate on the ignorance of the last line.]
>
> Any hacker not knowing a couple of Lisp macros is a waste of mind.
>
> -- Thomas de Grivel
>
> "I must plunge into the water of doubt again and again."

Reply | Threaded
Open this post in threaded view
|

Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.

Thomas de Grivel-2
I believe SICP has much culture but not always so great style.

I'm not "learning lisp".

Who are you to know of all lisp learners ?

Why are you associating lisp with functional programming ? CL in itself is
not really functional, but being a metalanguage you can make it so. You
could also make it sort perforated cards. Is it a perforated cards
programming language ? Lisp is not important, the way we can program it is
important, and it just comes from its syntax.

Lisp machines are long dead, there are excellent compilers available for
more current archs.

Looks to me like you are still "learning lisp".

--
 Thomas de Grivel
 http://b.lowh.net/billitch/

Reply | Threaded
Open this post in threaded view
|

Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.

Rod Whitworth-3
On Fri, 10 Jun 2011 03:58:40 +0200, Thomas de Grivel wrote:

>I believe SICP has much culture but not always so great style.
>
>I'm not "learning lisp".
>
>Who are you to know of all lisp learners ?
>
>Why are you associating lisp with functional programming ? CL in itself is
>not really functional, but being a metalanguage you can make it so. You
>could also make it sort perforated cards. Is it a perforated cards
>programming language ? Lisp is not important, the way we can program it is
>important, and it just comes from its syntax.
>
>Lisp machines are long dead, there are excellent compilers available for
>more current archs.
>
>Looks to me like you are still "learning lisp".
>
>--
> Thomas de Grivel
> http://b.lowh.net/billitch/
>

Get rid of your Lisp - it can be done.
See the movie now!
"The King's Speech"
The King's Speech won the Academy Award for Best Picture, Best Director
(Hooper), Best Actor (Firth), and Best Original Screenplay (Seidler).

Also won seven British Academy Awards.

Then you can stop trolling around here where you are about as welcome
as a fart in a crowded elevator stuck between floors.



*** NOTE *** Please DO NOT CC me. I <am> subscribed to the list.
Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou.

Rod/
---
This life is not the real thing.
It is not even in Beta.
If it was, then OpenBSD would already have a man page for it.