Re:Why is LISP superior?
on
RMS The Coder
·
· Score: 1
Maybe I should have mentioned: If anyone's interested in the project I was talking about check this site. I usually ran it in Emacs using LMUScheme, a small and fast GPL'd Scheme implementation that hardly anyone seems to know.
Re:Write a type assitant!
on
RMS The Coder
·
· Score: 1
Yep, that'd be a great thing. If I find the time to do it, one day..... Actually I was already thinking about a "type assistant" that can also do a lot more by attaching not only types but also properties (like: this number never gets greater than n) to variables and have some automated deduction system with some clever heuristics help you show that your code does what it's supposed to do. But I'll have to finish my PhD first...
Re:Why is LISP superior?
on
RMS The Coder
·
· Score: 2
I've worked in a research project implementing stuff in Scheme (the most beautiful LISP dialect, IMHO) for three years, so I'll try to answer your question FROM MY PERSPECTIVE (however, others will probably state other advantages of LISP when asked!): The thing I liked the most was how it allows you to manipulate code very easily in two ways: 1 - due to LISP being a functional language, any procedure is an object, which can be passed to other objects AND can be manipulated anytime, for example combining two procedures into a new one: (define (n-times f n) (if (= n 1) f (lambda (x) ((n-times f (- n 1)) (f x))))) defines the function "n-times" which takes a unary function f and a number n and gives back a new function which applies f n-times to its argument. Now, taken that the unary function "1+" adds one to its argument (define (+ m n) ((n-times 1+ m) n)) defines the function "+" with the obvious meaning (on integers), (define (* m n) ((n-times (lambda (x) (+ m x)) n) 0)) defines "*" and so on (OK, the example is artificial and the defined versions of + and * are horridly inefficient, but real-world examples would be too long, so all examples here will be artificial)
With this mechanism, you can build large customized procedures from atomic ones. What you can't do is a. always use certain language constructs like "if" efficiently: (if test (f x) (g x)) will only calculate either (f x) or (g x), which is what you'd expect, but if you define the function "choose" like this (define (choose m n) (if test m n)) and do (choose (f x) (g x)) then both (f x) and (g x) will be calculated before "test" is tested. This is not only inefficient, if f and g have side-effects, the behaviour will be different from the first version! b. look into an existing procedure and modify it...
2 - LISP source code itself is a data structure (i.e. a list) that can be arbitrarily generated, manipulated and executed VERY EASILY.
We use these mechanisms heavily in our project. To give you a taste of LISP at work, I'll try to sketch what we were able to do with them: We've implemented so-called normalization for a subset of the SCHEME language itself. Normalization could also be called partial evaluation or execution: You calculate everything you can and leave the rest untouched. For example, the normalized version of (lambda (x) ((n-times f 3) x)) would be (lambda (x) (f (f (f x)))) (get it?)
For this to work, all the functions and objects used in the code have to be defined in a special way. If they are, you simply do an "eval" on the program which you want to normalize (that is, you EXECUTE the program) and, as a result, the program gives you back the normalized version of itself! (Normalization includes ordinary execution: if the type of the program executed is integer and all free variables are instantiated, then the normalized program will be... an integer)
As I have said, the functions and objects have to be written in a special way. But this is no problem, because we pre-defined certain functions (like recursors) with which you can program almost anything you want without having to worry about these complicated mechanisms hidden in the pre-defined functions. And if that's not enough, I've also written a (pretty short) program which lets you write programs in a special form (as Term Rewrite Systems, if anyone knows what that is) and translates that into code that will work with the normalization mechanism. And if all that doesn't make your head buzz yet, here's how we USE the normalization technique: We represent mathematical proofs as such normalizable programs. Then we execute them and automatically get a normalized version of the proof, in which all detours are removed. And then, we can calculate from this proof another program which does what the proof shows it is possible to do. And that program cannot possibly contain a bug because it stems from a mathematical proof.....
Now you will say: OKOKOK, LISP has some nice features, but who, apart from some freaked-out researchers, needs them? Well, at first glance, hardly anyone. But only at first glance. Once you got used to working with these mechanisms, you find lots of places where they would be terribly useful as well (although not indispensable as in our case).
One more thing: RMS mentions another advantage, namely the fact that LISP is untyped (or, more precisely, dynamically typed), so that everything is a list (basically). Well, this is an advantage in flexibility, but also a disadvantage in debugging. When you've worked with LISP for a long time and then do C++, for example, you notice that type-checking sometimes is terribly useful. I don't know much about ML, but AFAIK it is very similar to LISP, but typed. All I know is that we couldn't easily port our stuff to ML, because its type system (although it's more powerful than the one of most other languages) is too strict for us, that is, we can't express, for example, the types of our recursors in ML. So, in this case the untyped nature of LISP is an advantage, but sometimes I really miss type-checking when doing LISP.
RedHat doesn't say "Hey, WE've developed that shiny new OS named Linux". RedHat does give back to the community. They support GPL'ed projects (Corel Office isn't GPL'ed and I suppose Corel wants to make money with it - so you can't say that's giving anything back to the community; still, Corel is helping the WINE people, THAT is giving back to the community). RedHat is taking the GPL more seriously than other distributors (IMHO). Finally, the money they got from their IPO is NOT profit, it's money lended to them by investors who think that RedHat will make money in the future... with support, which RedHat DOES provide...
I really don't understand why so many people get pissed off with RedHat just because they got some money (which they now use to support GPL'ed projects!).
I think you're right. One of the major problems of WinCE is its GUI: it looks crap on grayscale displays and color displays are expensive and power-consuming. And we shouldn't make the same mistakes. But I think we don't have to worry about this: Linux features dozens of different GUIs (Window managers, KDE, Gnome). Many of them are themeable. Whilst all of this (well, especially the themeability) didn't have any technical advantages up to now (it just gave users the possibility to make their desktop look neat), it will have in the future: There will be a dedicated WM (possibly developed from the codebase of some existing WM) with a small footprint for Palmsize computers with special themes for lo-res b&w displays, hi-res grayscale displays, hi-res color displays and so on. (And, like it or not, one day there will also be Palms running KDE or Gnome with a special Palmtheme). We'll show them how much more flexible Linux is!
Is it? For what reason? I haven't done much GUI programming, only a tiny little bit of AWT and a tiny little bit of Qt. In my perception so far, the general design of all such toolkits seems pretty similar, one main difference I could find was type-checking of callbacks. Here Qt does have an advantage over other GUI toolkits. Yet, since I haven't done much GUI programming, my view is a pretty theoretical one. So, from your perspective, what are the main differences between Qt and GTK+ and why is the latter easier for beginners?
Well, if you ARE looking for them, you might find that not covering Qt/KDE might be worth criticizing as much as not covering GTK+/GNOME (in the last edition) - GNOME might be YOUR preference, but as an editor you should IMHO try to be impartial. Then again, I don't want to advocate "political correctness", so just bang on!
It's from an episode of "Monty Pthon's flying circus". It was about a hungarian phrasebook translating (if I recall it correctly) a hungarian phrase with the meaning "How can I get to the train station" to "My hovercraft is full of eels" (and other such nonsense).
Of course the seq's themselves can't be patented. Otherwise anyone holding such a patent would be (AFAIK) entitled to control the reproduction of the sequences, that is, since we are contantly reproducing them in our bodies he could charge us for letting us live... Now, this would make patent law a satire just too obviously. Still, (again, AFAIK, correct me, if I'm wrong) patents on gene sequences (that is, their applications) have a new quality: They do not cover applications that the patent holder has thought of, they cover all applications that become possible only if you know that gene sequence. If I remember it correctly, there are already cases where companies hold patents on certain proteins in our bodies (again, not the proteins themselves but any of their applications) and you are not allowed to TEST for these substances without paying them license fees, even if you're using a completely new testing method you developed on your own.
This is a great article! I think in fact it's a must-read for anyone who's interested in doing some serious Open Source hacking (OTOH must serious Open Source hackers probably know almost everything in this article already) or just generally interested in the miracles of Open Source and the advantages of its development process. Recently I have talked about Open Source with lots of people, mostly non-programmers who wanted to know about that new thing called Linux everyone is talking about. Their first reaction to my explanations of the meaning of the word free (speech, not just beer!) in this context was: "Oh, but you'll get a lot of code forking then..." (well, they didn't state it this way but what they meant was exactly that), so I carried on to explain to them (1) why this is happening so seldomly and (2) how, at the same time, the POSSIBILITY of code forking was a good thing. Basically what I told them was just a subset of this article. I was really amazed at finding *EVERY* bit I told them in this article and the article having the same structure as those monologues I gave to my friends (first some examples, then the "analysis" with the 2 main conclusions I mentioned above). Only that the article is much more complete and convincing than everything I ever came up with. Thank you Rick! After reading it I am more-than-ever convinced that we do not have to fear code forking! It can happen, it will happen, but the new branch will survive if AND ONLY IF the advantages outweigh the disadvantages.
Slashdot Mirror
Maybe I should have mentioned:
If anyone's interested in the project I was talking about check this site.
I usually ran it in Emacs using LMUScheme, a small and fast GPL'd Scheme implementation that hardly anyone seems to know.
Yep, that'd be a great thing. If I find the time to do it, one day.....
Actually I was already thinking about a "type assistant" that can also do a lot more by attaching not only types but also properties (like: this number never gets greater than n) to variables and have some automated deduction system with some clever heuristics help you show that your code does what it's supposed to do.
But I'll have to finish my PhD first...
I've worked in a research project implementing stuff in Scheme
(the most beautiful LISP dialect, IMHO) for three years,
so I'll try to answer your question FROM MY PERSPECTIVE (however,
others will probably state other advantages of LISP when asked!):
The thing I liked the most was how it allows you to manipulate code
very easily in two ways:
1 - due to LISP being a functional language, any procedure is an object,
which can be passed to other objects AND can be manipulated anytime,
for example combining two procedures into a new one:
(define (n-times f n)
(if (= n 1)
f
(lambda (x) ((n-times f (- n 1)) (f x)))))
defines the function "n-times" which takes a unary function f and a number
n and gives back a new function which applies f n-times to its argument.
Now, taken that the unary function "1+" adds one to its argument
(define (+ m n) ((n-times 1+ m) n))
defines the function "+" with the obvious meaning (on integers),
(define (* m n) ((n-times (lambda (x) (+ m x)) n) 0))
defines "*" and so on
(OK, the example is artificial and the defined versions of + and * are
horridly inefficient, but real-world examples would be too long, so all
examples here will be artificial)
With this mechanism, you can build large customized procedures from atomic
ones. What you can't do is
a. always use certain language constructs like "if" efficiently:
(if test (f x) (g x))
will only calculate either (f x) or (g x), which is what you'd expect,
but if you define the function "choose" like this
(define (choose m n) (if test m n))
and do
(choose (f x) (g x))
then both (f x) and (g x) will be calculated before "test" is tested.
This is not only inefficient, if f and g have side-effects, the behaviour
will be different from the first version!
b. look into an existing procedure and modify it...
2 - LISP source code itself is a data structure (i.e. a list) that can be
arbitrarily generated, manipulated and executed VERY EASILY.
We use these mechanisms heavily in our project. To give you a taste of
LISP at work, I'll try to sketch what we were able to do with them:
We've implemented so-called normalization for a subset of the SCHEME
language itself. Normalization could also be called partial evaluation or
execution: You calculate everything you can and leave the rest untouched.
For example, the normalized version of
(lambda (x) ((n-times f 3) x))
would be
(lambda (x) (f (f (f x))))
(get it?)
For this to work, all the functions and objects used in the code have to
be defined in a special way. If they are, you simply do an "eval" on
the program which you want to normalize (that is, you EXECUTE the program)
and, as a result, the program gives you back the normalized version of itself!
(Normalization includes ordinary execution: if the type of the program
executed is integer and all free variables are instantiated, then the
normalized program will be... an integer)
As I have said, the functions and objects have to be written in a special
way. But this is no problem, because we pre-defined certain functions
(like recursors) with which you can program almost anything you want
without having to worry about these complicated mechanisms hidden in the
pre-defined functions.
And if that's not enough, I've also written a (pretty short) program which
lets you write programs in a special form (as Term Rewrite Systems, if anyone
knows what that is) and translates that into code that will work with the
normalization mechanism.
And if all that doesn't make your head buzz yet, here's how we USE the normalization
technique: We represent mathematical proofs as such normalizable programs.
Then we execute them and automatically get a normalized version of the proof,
in which all detours are removed. And then, we can calculate from this proof
another program which does what the proof shows it is possible to do.
And that program cannot possibly contain a bug because it stems from a
mathematical proof.....
Now you will say: OKOKOK, LISP has some nice features, but who, apart from
some freaked-out researchers, needs them?
Well, at first glance, hardly anyone. But only at first glance. Once you
got used to working with these mechanisms, you find lots of places where
they would be terribly useful as well (although not indispensable
as in our case).
One more thing: RMS mentions another advantage, namely the fact that LISP
is untyped (or, more precisely, dynamically typed), so that everything is
a list (basically). Well, this is an advantage in flexibility, but also a
disadvantage in debugging. When you've worked with LISP for a long time
and then do C++, for example, you notice that type-checking sometimes is
terribly useful.
I don't know much about ML, but AFAIK it is very similar to LISP, but typed.
All I know is that we couldn't easily port our stuff to ML, because its
type system (although it's more powerful than the one of most other languages)
is too strict for us, that is, we can't express, for example, the types of
our recursors in ML. So, in this case the untyped nature of LISP is
an advantage, but sometimes I really miss type-checking when doing LISP.
RedHat doesn't say "Hey, WE've developed that shiny new OS named Linux".
RedHat does give back to the community. They support GPL'ed projects (Corel Office isn't GPL'ed and I suppose Corel wants to make money with it - so you can't say that's giving anything back to the community; still, Corel is helping the WINE people, THAT is giving back to the community).
RedHat is taking the GPL more seriously than other distributors (IMHO).
Finally, the money they got from their IPO is NOT profit, it's money lended to them by investors who think that RedHat will make money in the future...
with support, which RedHat DOES provide...
I really don't understand why so many people get pissed off with RedHat just because they got some money (which they now use to support GPL'ed projects!).
I think you're right. One of the major problems of WinCE is its GUI: it looks crap on grayscale displays and color displays are expensive and power-consuming. And we shouldn't make the same mistakes.
But I think we don't have to worry about this: Linux features dozens of different GUIs (Window managers, KDE, Gnome). Many of them are themeable. Whilst all of this (well, especially the themeability) didn't have any technical advantages up to now (it just gave users the possibility to make their desktop look neat), it will have in the future: There will be a dedicated WM (possibly developed from the codebase of some existing WM) with a small footprint for Palmsize computers with special themes for lo-res b&w displays, hi-res grayscale displays, hi-res color displays and so on. (And, like it or not, one day there will also be Palms running KDE or Gnome with a special Palmtheme).
We'll show them how much more flexible Linux is!
Is it? For what reason?
I haven't done much GUI programming, only a tiny little bit of AWT and a tiny little bit of Qt. In my perception so far, the general design of all such toolkits seems pretty similar, one main difference I could find was type-checking of callbacks. Here Qt does have an advantage over other GUI toolkits.
Yet, since I haven't done much GUI programming,
my view is a pretty theoretical one.
So, from your perspective, what are the main
differences between Qt and GTK+ and why is the latter easier for beginners?
Well, if you ARE looking for them, you might find
that not covering Qt/KDE might be worth
criticizing as much as not covering GTK+/GNOME
(in the last edition) - GNOME might be YOUR
preference, but as an editor you should IMHO
try to be impartial.
Then again, I don't want to advocate "political
correctness", so just bang on!
It's from an episode of "Monty Pthon's flying
circus". It was about a hungarian phrasebook
translating (if I recall it correctly) a
hungarian phrase with the meaning "How can I
get to the train station" to "My hovercraft
is full of eels" (and other such nonsense).
Of course the seq's themselves can't be patented.
Otherwise anyone holding such a patent would be
(AFAIK) entitled to control the reproduction of
the sequences, that is, since we are contantly
reproducing them in our bodies he could charge
us for letting us live...
Now, this would make patent law a satire just too obviously.
Still, (again, AFAIK, correct me, if I'm wrong)
patents on gene sequences (that is, their
applications) have a new quality: They do not
cover applications that the patent holder has
thought of, they cover all applications that
become possible only if you know that gene
sequence.
If I remember it correctly, there are already
cases where companies hold patents on certain
proteins in our bodies (again, not the proteins
themselves but any of their applications) and
you are not allowed to TEST for these substances
without paying them license fees, even if you're
using a completely new testing method you developed on your own.
This is a great article! I think in fact it's a must-read for anyone who's
interested in doing some serious Open Source hacking (OTOH must serious Open
Source hackers probably know almost everything in this article already) or
just generally interested in the miracles of Open Source and the advantages of
its development process.
Recently I have talked about Open Source with lots of people, mostly
non-programmers who wanted to know about that new thing called Linux everyone
is talking about.
Their first reaction to my explanations of the meaning of the word free
(speech, not just beer!) in this context was: "Oh, but you'll get a lot of
code forking then..." (well, they didn't state it this way but what they meant
was exactly that), so I carried on to explain to them (1) why this is happening
so seldomly and (2) how, at the same time, the POSSIBILITY of code forking
was a good thing.
Basically what I told them was just a subset of this article. I was really
amazed at finding *EVERY* bit I told them in this article and the article
having the same structure as those monologues I gave to my friends (first some
examples, then the "analysis" with the 2 main conclusions I mentioned above).
Only that the article is much more complete and convincing than everything I
ever came up with.
Thank you Rick!
After reading it I am more-than-ever convinced that we do not have to fear
code forking! It can happen, it will happen, but the new branch will
survive if AND ONLY IF the advantages outweigh the disadvantages.