From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Pascal J. Bourguignon" Newsgroups: gmane.emacs.help Subject: Re: becoming a lisp developer Date: Tue, 26 Jun 2012 14:29:31 +0200 Organization: Informatimago Message-ID: <87wr2uqms4.fsf_-_@kuiper.lan.informatimago.com> References: <87bokbb4zw.fsf@gnu.org> <4FE67DF4.1010903@mousecar.com> <8262af46dv.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1340713815 3502 80.91.229.3 (26 Jun 2012 12:30:15 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 26 Jun 2012 12:30:15 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Jun 26 14:30:12 2012 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SjUuK-0007vB-6Y for geh-help-gnu-emacs@m.gmane.org; Tue, 26 Jun 2012 14:30:12 +0200 Original-Received: from localhost ([::1]:58905 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SjUuJ-0001Qk-Qq for geh-help-gnu-emacs@m.gmane.org; Tue, 26 Jun 2012 08:30:11 -0400 Original-Path: usenet.stanford.edu!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 154 Original-X-Trace: individual.net 75e9I0LxPTtWoR3uXosAYwGLNEthmExkfAWzD3nehWpP7o3HNgQFmL+p+2eqEW5vDj Cancel-Lock: sha1:ZDcyNzNhOWFiYTEwMWI1ZDU2ZjU0OGQzMjkxMzk3ODEzZWNkODM0YQ== sha1:05JiL/qlWz9w3LvauR1pEFYny/s= Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA oElEQVR4nK3OsRHCMAwF0O8YQufUNIQRGIAja9CxSA55AxZgFO4coMgYrEDDQZWPIlNAjwq9 033pbOBPtbXuB6PKNBn5gZkhGa86Z4x2wE67O+06WxGD/HCOGR0deY3f9Ijwwt7rNGNf6Oac l/GuZTF1wFGKiYYHKSFAkjIo1b6sCYS1sVmFhhhahKQssRjRT90ITWUk6vvK3RsPGs+M1RuR mV+hO/VvFAAAAABJRU5ErkJggg== X-Accept-Language: fr, es, en User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Original-Xref: usenet.stanford.edu gnu.emacs.help:193083 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:85478 Archived-At: ken writes: > People familiar with C say it's a difficult language. But I guess > they never tried it. You can pick up a book on it and if you give it > a little bit of time every day, you can learn enough in a week to > write interesting and working programs. And it's fun. Shell > programming like bash and ksh are easy and fun too. C++ too, but to a > lesser degree. But elisp.... I tried repeatedly over more than ten > years to learn it, bought and read a couple books on it, did some > tutorials, of course spent a lot of time in the docs, but it wasn't > until just a few years ago (and with a lot of help from this list) > that I was able to write my first elisp program. I started a second > one last year and I'm still plodding really slow through it (but not > often). It takes so long to get things to work that I'm discouraged > from spending time on it. Half the time I'm trying to figure out the > code and moan to myself that, if I could write this function in C, I > would have had it written in one-tenth the time... or less. Then, > after I've written some working elisp code and look at, I see it's not > that difficult. So how is it that it took so long to figure out? The fact is, there are big categories of languages. C and Pascal are the same. C or C++ are almost the same (compare Homo Sapiens Sapiens with Homo Neandertalis). All the common languages fall into the Algol category of languages; basically, when you know one, you know all of them: the semantics are fundamentally the same, only the unimportant syntax changes. But beside the Algol category, there are: - the logical programming category (Prolog, etc), - the lisp category (eg. Common Lisp, Emacs Lisp, Scheme, and a lot of older lisps) - the functional programming category (Haskell, ML, Ocaml, etc). and a lot of others. http://en.wikipedia.org/wiki/List_of_programming_languages_by_type When you change of language category, the syntax may change or not, but importantly, it's the semantics that change. That's where you may be misled and have to spend more learning time. For example, syntactically, adding two numbers is written: { int a=1; int b=1111111112; int c=1111111113; a=b+c; } in C, and: (let ((a 1) (b 1111111112) (c 1111111113)) (setf a (+ b c))) in lisp. But the syntac is irrelevant. You can easily write a pre-processor to convert one into the other. (See for example: http://paste.lisp.org/display/25134) What's more important to understand the meaning of those programs, is their semantics. In a 32-bit C, (ie. a C where int has a 32-bit two-complement representation), the result would be -2072745071 with some compiler. (In some other C compilers, it could signal a run-time error, the C standard doesn't specify what must happen). In a 64-bit C, (ie. a C where int has a 64-bit two-complement representation), the result would be 2222222225. In a 32-bit emacs, which has no bignums and where fixnums are limited to 29-bit two-complement the result would be 74738577. In a 64-bit emacs, which has still no bignums, but where fixnums are limited to 61-bit two-complement, the result would be 2222222225. In a Common Lisp implementation, which therefore has bignums, whatever the size of the fixnums, the results would be 2222222225. So you can see that the meaning of a simple operation such as a=b+c or (setf a (+ b c)): 1- is NOT specified entirely by most programming languages. 2- is specified entirely in some programming languages. 3- when it's specified (be it by the language or by an implementation), MAY or MAY NOT mean the same thing (ie. give the same results). The semantical differences are therefore: In Common Lisp, + for integers implements the mathematical integer addition (up to the available memory). In emacs lisp, + for integers implements the addition modulo 29 or 61 depending on the machine word size. In C, + for int may implement the addition modulo 32 or 64, or something else (including signaling a run-time error, or a compilation-time error). And this is only for the simpliest of the operation. In the code sample above, there are other semantic differences, like the fact that in lisp there are no statement, therefore all expression returns a value. setf returns the last value assigned. let returns the result of the last expression in its body, so the let form actually returns the result of the addition, and if you evaluate it in a REPL (read eval print loop), then this result will be printed too. On the other hand, {} is a statement in C, which has no result value and nothing is ever returned or printed by that code sample. The let form is a valid lisp expression as it is. The {} however does not stand alone: you need to wrap it in a C program to make it really meaningful. There's the fact that in C, types are a property of the variables, while in Lisp types are property of the values. The fact that setf is actually a macro, that while it's provided by the language, could be written by the user if it was missing, like any other macros, vs. the fact that = is a hard wired C operator and the user can't add new operators (it's possible for some of them in C++, but with vastly different mechanisms and semantics than lisp macros). Etc. The conclusion is that to learn a programming language in a different category of what you know already, you must forget what you know, and just learn it from the beginning. And the existance of those different broad categories is also the reason why you are told to learn different programming languages. But learning C and C++ doesn't count. You must pick one language in each category! Since you already know C, you should learn at least Prolog, one lisp (but it's also useful to learn elisp, scheme and Common Lisp), Haskell, APL and Smalltalk. > Maybe, if I live to be three hundred, I'll write an elisp book myself. Usually it comes much fater. -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.