Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.
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 super_bisq...@yahoo.com 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 billi...@gmail.com wrote: From: Thomas de Grivel billi...@gmail.com Subject: Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems. To: misc@openbsd.org misc@openbsd.org 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.
Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.
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/
Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.
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.
Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.
+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.
Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.
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.
Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.
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.
Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.
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 billi...@gmail.com wrote: From: Thomas de Grivel billi...@gmail.com Subject: Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems. To: misc@openbsd.org misc@openbsd.org 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.
OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.
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.
Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.
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
Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.
On 7 June 2011 07:08, Thomas de Grivel billi...@gmail.com 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.
Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.
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
Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.
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.
Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.
On Jun 7, 2011, at 19:46, Nicholas Marriott nicholas.marri...@gmail.com 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.
Re: OT: Re: Seems OpenBSD isn't absolutely alone in it's quest, atleast on embedded systems.
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.
