RMS The Coder

Andrew G. Feinberg writes "Here is a article on the LinuxCare website. " This is a cool interview just because its not dealing with the usual GNU/Open Source/Free Software stuff, but more with code, coding, and lots of other stuff that frankly just isn't political. Enjoy it.

Comments

RMS wrote too much code :-)

[trance9]

I forget who said it, but I recall once some OSS advocate saying he wished he could just ignore RMS and the GNU project and write them off as the radical wing, but that unfortuntely RMS had written far too much code to be ignored.

I think that's a great statement about how in the OSS/FS world your code does wind up being very much where your mouth is. The more code you write, the bigger say you get.

Personally I love the GNU project, and I am very glad that RMS has written so much code that he can't be ignored.

Re:RMS wrote too much code :-)

[MattMann]

I don't think RMS is as famous for writing code as he is for advocating and giving away free and open source. He advocated for it through the Dark Ages, and now that he his ideas have proved to be the pre-eminent ideas for this age, it is his time in the sun.

Prior to that, K & R were famous, and prior to them, Knuth. Yep, they all wrote code and in some senses gave it away, but it was the ideas embodied in the code that they were giving away that make them famous. Linus is famous for the "just do it/can do" nature of his work, unlike all the bigger named, more experienced coders and architects who didn't deliver their kernel work to the mass of people who had x86s sitting in front of them.

Why is LISP superior?

[Utter]

I have still failed to see the greatness of LISP. Since I prefer Emacs as editor I can do very simple things, such as editing my .emacs but not much more.

OK, someone with experience with LISP and e.g. ML (or any other functional language), explain why RMS and others call LISP a superior language? When I studied CS we learned ML and I thought that was a brilliant language. Perl on the other hand is superior when it comes to manipulating text.

Funny, RMS came up with the POSIX name. :)

Re:Why is LISP superior?

[mellon]

Some reasons I can think of off the top of my head:

• LISP has a completely regular syntax (well, let's say Scheme, since there are some disgusting hacks in Common Lisp). PERL has a syntax from Hell.
• LISP does stupid stuff for you - for example, you don't have to keep track of garbage, as you do with C. Perl doesn't garbage collect either (AFAIK), but it does at least have automatic memory allocation.
• LISP has a very different typing model from either PERL or C - every object has the potential to have any possible type. Lists are first-class objects, so you don't have to write yet another stupid list traversal routine every time you want to make a list of things, and you can build trees out of lists. This turns out to be very powerful once you understand it, but it's a little hard to wrap your brain around at first.

Unfortunately, in order to really appreciate the power (and the shortcomings) of LISP, you have to learn it - I can't really make a point-for-point comparison here that would convince you of anything. And anybody who claims LISP is a panacea is wrong - it just makes a very different set of tradeoffs than PERL or C.

I would suggest actuallty trying to write some code in raw Scheme, not emacs LISP, that does some sort of interesting data structure manipulation, preferably recursively. Maybe pick up a copy of SICP, The Little Schemer or The Seasoned Schemer.

Re:Why is LISP superior?

[Kaufmann]

Generally speaking, Lisp is superior because it's made out of lists. This is much more important than it looks. Why?

(WARNING: here there be dragons! Below I simplify extremely for the sake of understanding. Please don't bash! Also, note that everything I say about Lisp interpreters also applies to Lisp compilers.)

Take Perl, for example. In Perl, programs are basically one-dimensional character strings, usually read from a file. What the Perl compiler does (either when called to run a program, or an eval() or a s///e) is take that string and parse it into a syntax tree, which is then 'flattened out' into bytecode, which is, in turn, executed by the bytecode interpreter.

In Lisp, on the other hand, programs and data are naturally represented as lists; the strings that you type into the Lisp top-level are parsed into lists as soon as possible (an extremely simple thing to do, by the way), and from that point on the entire environment can use a homoiconic set of primitives (car, cdr, cons, eval, etc.) to handle any data that you may pass to it.

Exempli gratia, let's look at two functionally equivalent programs (defining a program as a representation in computationally concrete form of an abstract mathematical algorithm):


# Perl
map { $_->[0] }
sort { $a->[1] $b->[1] }
map { [$_, $f->($_)] } @ARGV;

; bastardized Scheme
(map (lambda (l) (car l))
(sort (lambda (a b) ( (cdr a) (cdr b)))
(map (lambda (e) (cons e (f e))))
*argv*))


You may have recognized the Perl program as a variation of the famous Schwartzian transform, wherein $f can be any key-producing function; with $f = \&-s it becomes a program that orders the filenames passed as arguments by size. The below program is not quite valid R5RS Scheme; the *argv* list, equivalent to @ARGV, is not standard, and the form can be easily defined in terms of the comparison operators:


(define ( a b)
(cond
((> a b) 1)
((= a b) 0)
((

Likewise, with a bit of creativity, the sort form can also be implemented.

Anyway, how does all this matter? Simple. As data, the Perl program is a 74-element character array; it has all kinds of special symbols and tokens, and turns out to be horribly complex to parse. On the other hand, as data, the Scheme program is very simple: it's a linked list with three elements, one of which is the symbol 'map, and two of which are sub-lists. /What/ this linked list represents doesn't matter except to the interpreter; it's a list like any other. Applying the car operation to this list would yield the symbol 'map; the cadr (first rest) operation would yield the list '(lambda (l) (car l)).

It's important to note here that the interpreter is a function like any other; as such, it deals with lists like the ones above. The reader - which parses text into lists - is a separate system.

Originally, the fact that all Lisp programs are lists was considered a huge disadvantage (even by John McCarthy himself), and for years there were attempts to introduce a new Algol-like syntax (called M-expressions) to supersede the list representation (called S-expressions). But, as it turned out, this turned out to be a huge advantage, and Lisp programmers almost universally appreciate SEXP.

Of course, there are many other reasons why Lisp is a superior language, although many of those are implementation-dependent and may also be present in other languages. But having a homoiconic representation for programs and data is by far the greatest advantage.

Note: While we're on the topic of languages with homoiconic representations, I thought I should mention Funges, a family of languages in which programs are represented as n-dimensional, potentially infinite cell-spaces to be traversed by an instruction pointer; each instruction occupies one cell. The written representation of Funge programs follows this; for instance, in Befunge (the 2-dimensional Funge), a typical program might look like


v
>v"Hello world!"0

or even better,


9::*\2*+00p0v"."0310p0"," >"llaw eht no "v >#v_ ^
^_210p0"--:" v ,
: v " of beer" "selttob"00g.^ 00g1-#^_$" elttob erom enO" ^
>00g#^_$" selttob erom oN" ^
^_110p0",dnuora ti ssap ,nwod eno ekaT"^
^:-1_010p00g1-00pvv:-1g01_@#g00,*25

(The Befunge programs above are not /quite/ correct, thanks to Slashdot's mishandling of PRE tags... look at the source code to see the real thing.)

Re:Why is LISP superior?

[OOPChugALug]

After coding in C++ for the last 12 years ( and still as a necessary part of my work) I have switched to Lisp for all my personal work. Once I got over the parentheses, I have found that Lisp is probably the most radically consistent and advanced language I have ever used.

Everything is a list. Program code and data is a list. All commands (like compiling ) is issued in the form of a list.

So, you can do something like writing code, which when executed, generates code.


Additionally, lisp is typeless. A variable can contain lists, nested in lists etc etc... which can be code.. .which can contain commands to compile itself, and run itself, attach itself to other lists, etc. It's flexible, malleable, dna like stuff.

I programmed a Qt signal/slot system in 2 pages of code. Although syntax appears difficult when coming from the C++ world, I guarantee that template and pointer syntax is MUCH more difficult.

Here is some code, that when executes, generates a
method on the fly, which can then be executed in the future. ( i.e. C++ does NOT give us the ability to change the basic structure a class (add or take away methods or data members at run time)..lisp does.

Additionally, Lisp or CLOS has no problem dealing with multiple inheritance. Methods are not owned by a class like in C++ or Java. For example, a method (or in lisp, a generic function) can be specialized to run with more than one object (multimethods). i.e. method( class1 type, class2 type ..etc)

Methods can even be specialized to run with a particular INSTANCE of a class. i.e.
here are 2 methods

method( instantiated object 1 of class A only ).
method( instantiated object 2 of class A only)

here is a method which when executed, creates a method which only works with a specific instance of an object. Of course this function is a list, and could be transmitted across a network, and executed !!


(defmethod map-signal((_container container) mapped-signal-name
(_transmitter transmitter-reciever) _transmitter-signal-name)
(let ((y (gensym)))
(eval`(defmethod ,y((_container (eql ,_container)) data )
(broadcast _container ',mapped-signal-name data )))
(connect _transmitter _transmitter-signal-name _container y)))


Modern lisps (like Franz) are compiled into machine code, and can be VERY fast. Not as fast as raw C or C++, but the bottom line is programs that are 100 pages of code in C/C++ may be 1/10th
the size in Lisp, and exceedingly hard to do - or next to impossible - without writing a lisp -like system. So you can prototype huge systems VERY quickly, and then if you'd like, write some of the lisp code in C for speed improvements.

Dave

Re:Why is LISP superior?

[MattMann]

How is LISP powerful?

Think of C: it has ints, floats, chars, structs, and vectors of those things, and pointers to any of those things (maybe I left out a few, but you get the idea). Then, totally separately, it has code for manipulating those "data" things.

C++ came along and it added some ways to connect your data to the appropriate code so you wouldn't mistakenly point the wrong code at the wrong data. But getting everyone to switch to C++ was a grueling 10 years because of all the training, and reprogramming it took, and it didn't really resulting in a more satisfying coding experience.

Turns out folks weren't satisfied, though, and now we've got Java, which restricted a lot of things you could do toward the end of making some other things easier. We've just started the grueling 10 years for this one, and I suspect some of the stuff that got restricted (essentially, they grabbed the ++ and chucked out the C) is stuff that a lot of folks want to keep doing...

Anyway, back to LISP: it was said earlier that LISP syntax was regular, but while true, that didn't capture what else is true: the textual representation of LISP is simple and regular, yes, but after it gets parsed it is also stored in memory in a simple and regular way: LISP looks at the world as "things" (like C's ints or floats) and lists of things, including other lists. Your program is just a list of things, and your program is "visible" to you as data, very simple data.

In C, it would be as if the entry point to your program was main(argc, argv, argp) where "argp" was a pointer to your program itself: "main(argc, argv, argp)..." Not a string that starts "main(...", but something more like an array of all of your tokens. The variables in your program would be references to your actualvariables (haven't you ever wished in a C program to have access to the symbol table that the compiler created and threw away? in LISP you do) But even beyond this, if you went deeper into your program, when you get to the token "for" (at the beginning of your for-loop), you could look up the code that implements "for" and see what its code does. Don't like what it does? Write your own version that behaves differently... that's been done many times in LISP so that today, loops are really functional.

Now, I'm not saying that everybody should rewrite how "for" works, or that all programs should manipulate code. But, one way to see how powerful LISP is is to see that LISP in its lifetime (since 1960) has made transitions similar to C to C++ to Java, but those transistions were made within the language itself, by people experimenting with new ideas to see which caught on. LISP erases the distinction between code and data in a really meaningful and powerful way.

So, that's just one powerful thing about LISP. I guess the other major one I'd mention is that the programming tricks and idioms that you learn (just like you learned to "for(p=x;*p;p++)" your way through C arrays) remain more universal and stable in LISP. "Walking" the LISP trees of data has remained the same from 1960 your first day learning the language to now. The "toolkit in your mind" that you carry with you does not have to constantly learn a zillion new things. It's as if you went to look at the implementation of a Java class and thought, "oh I see, it does something simple" rather than, "oh, looks like I need to go digest a bunch of other classes that this one has inherited from."

Hope this is useful... and I didn't even get to tail-recursion which is so cool that it blows all of this stuff away.

Re:Why is LISP superior?

[V.]

I'll have to agree with the other poster that
LISP is one of things you have to experience
to appreciate. My first reaction was "This
language wasn't invented...it was found crashed
in some dessert in New Mexico." ;) But the more
familiar you get with LISP the more you start
to appreciate it. It's a pretty radical departure
from Algol-like lgs. tho.

As for learning how to use emacs...the route
most people recommend is to run the tutorial.
Frankly, I think that is the worst approach. You
have a chicken or the egg problem because you
have to know some emacs to even navigate the
tutorial. My advice is to buy the printed Emacs
manual from FSF. I read a few chapters of the book
before sitting down at the 'puter to get
finger memory. It was much easier to learn this
way. The keystrokes in emacs are actually pretty
well thought out(IMO) but most people don't take
the time to get the ideas. They just sit down and
want to immediately start using it. Doesn't work
that way. Once you learn tho...emacs is just
great.

Re:Why is LISP superior?

[Roundeye]

Anybody have any examples of problems that can be solved in LISP and no other language? Or is this just standard RMS hyperbole?

Your question is based upon false presumptions -- that such problems exist. Since one can write a lisp interpreter in a number of languages: C, C++, Perl, Pascal, numerous variants of assembly, etc.; it must be true that any problem solvable in Lisp can be solvable in these other languages (if it seems that you have an instance where this is not true then write your LISP solution, and feed it into a LISP interpreter written in the other language).

This, however, does little to address issues of usability and suitedness of languages to problems. Just as C++ is an arguable improvement over C (and that is an ongoing argument at that), but C can do everything that C++ can do (think about what it takes to write a C++ compiler in C; while not trivial, with name-mangling things get easy quickly). Still there are many who can develop large systems more quickly in C++ than they could while writing in C, due primarily to the types of abstractions made available.

I read RMS as saying that the fact that programs in LISP are represented not as character strings but native list data structures which preserve program structure as data while remaining executable is one reason to conclude that LISP is a "more powerful" language than the others. It is more powerful in that it enables skilled LISP programmers to do things "better" than skilled programmers of other languages. I take this to mean that LISP is a "more beautiful" language -- i.e., that makes sense, is complete, and self-reflective.

Take that for what you will. I do the majority of my programming in C/C++/Perl with odds-and-ends languages for special tasks. But, I spent a few years doing a lot of LISP and it is a beautiful language. Ever see a LISP interpreter written in LISP? Takes about a page of type for a full-featured interpreter. In my Principles of Programming Languages class in graduate school one of the problems on our final examination was "given the LISP interpreter written in LISP on the previous page, modify the interpreter to support call by reference argument passing semantics." The solution was a couple of lines of code. There's a certain Zen to LISP programming that you don't find anywhere else.

Unfortunately, there isn't much call for LISP programs out there in the business world or the OSS world, and the art languishes. [ IMHO one of the reasons is that the average programmer can't find the Zen between the parentheses -- not a problem with a language, but a problem with the average programmer ]. LISP is arguably a "more powerful" language than the others in wide use, but unfortunately the programmers in wide use are not as powerful as RMS.

YMMV. My $.02. Do not taunt happy fun LISP. Please keep hands inside vehicle. Not for olfactory use. Keep away from eyes. etc.

Standards

[Bitscape]

We support standards in the ways that are useful to users, and we depart from them when that becomes more useful to users.

Alright, I like RMS and his teachings as much as anyone, and even agree with the sentiment of this statement. If standards aren't serving users in the best way possible, what good are they?

But if it were someone from Microsoft making this statement, let's admit it. We would be jumping all over their throats and making accusations about "embrace and extend". Obviously, since GNU makes free software, there's less worry about them subverting the standards process, but where do you draw the line?

BTW, the POSIX_ME_HARDER part was hilarious. Made my morning. :)

Re:Standards

[kuro5hin]

but where do you draw the line

I think you draw the line exactly at the question: "Is the 'extension' closed and proprietary?" That is, when M$ extends a standard, you are not allowed to see what they did. If M$ adds extensions to HTML, they do it because it distinguishes their browser from Netscape. Now, maybe the extension is useful and good, but the fact that it may only be implemented by M$ browsers is, overall, bad for users.

On the other hand, when an author of OSS extends a standard, the code is open, and others may see and reimplement exatly the same functionality in their code as well. Assuming this extension is also good for users, then everyone can implement it, and the net result is a big win, rather than a hideous swamp of incompatibility (like present-day HTML).

"Get away from my house you freak!"
-Neal Stephenson

Interview spoiled #prgma joke. Here it is:

[DavidOster]

The LinuxCare interview spoiled RMS's #pragma joke. The interview said:

Richard: the C specification which said #pragma was supposed to do something about implementation design.

I'm sure this is a misquote. I'm sure that what he actuially said was: the C specification said #pragma was supposed to do something that was implementation defined.

What that version of the C compiler did was, if it processed a #pragma, it did something implementation defined all right: it exec()ed Rogue.

Imagine: you're compiling an innocent C program, that happens to have a #pragma line on it, and suddenly the compile is gone, and your screen is running Rogue!

Re:Security

[Jonas �berg]

The Incompatible Time-sharing System (ITS) that RMS hacked on and which was used at MIT for many years did not have much security. Security always comes to the cost of convenience, and security builds walls to divide people, much like proprietary software does. RMS's favourite umask is 000 and the information given to new people who gets accounts on a gnu.org machine recommends this umask, iirc. On one of the machines that RMS uses, he says that it's fine for people to read his email, but that he wishes they would do it with `more' and not with a mailreader so there's no risk of loosing mail. Until only a few years ago he had the password 'rms'. He doesn't use much of the gnu.org computers for this reason. His own computer doesn't have security.

I support RMS in this. I wish people would understand that security isn't always important.

YART - Yet Another RMS Triumph

[mihalis]

Another thing that RMS did that was really incredibly cool was he worked out how Ada could behave itself just like other computer languages rather than being really quite fierce and hostile. When he helped a bit in the initial design of GNAT (the GNU Ada compiler) RMS worked out that the Ada "library" that is required by the standard could in fact be a lightweight definition consisting of little more than the source code with attached timestamps, and some little supplementary text files, rather than the previous system. In this way GNAT was made a true first class language front-end for GCC without making GCC jump through any hoops or do anything really pointless.

Before GNAT, Ada "libraries" were these monstrous opaque creations that made compilation incredibly slow - the compiler would have to open each library and read the (huge, expanded) semantic information associated with each separate unit mentioned in the current compilation from disk, rather than just going and getting the source code. By the early 90s the old Ada library approach was total junk, as GNAT easily blew away all previous Ada technologies using a combination of a) one of the worlds fastest language parsers (I would guess, certainly the fastest Ada parser ever seen) b) bountiful cpu power and RAM, and c) RMS's new lightweight library design.

These days there is a small but happy free Ada software crowd building up around GNAT, and I believe the GNAT team has been able to contribute a fair amount of value back to the GCC core. RMS helped to make this all possible and vastly improved the lot of a number of underpaid overworked Ada programmers (defence, telecoms, transport infrastructure etc).

Re:Security

[randombit]

I wish people would understand that security isn't always important.

If you wish to disregard security, that's fine with me, as long as it's your home machine. On a multi-user machine, it seems very inconsiderate to other users, since maybe they don't want people reading their mail, and once a cracker has one account, he most likely has them all. Not to mention the people who administrate the machine - we have enough to deal with without getting broken into because one of our users used their login name for a password.

Kind of odd that RMS says "security sucks" (not a direct quote, of course, but that's what he seems to be saying), then actively promotes crypto and GnuPG. I guess his thinking is that people have the right to choose between privacy and openness, which seems reasonable.