From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Xah Newsgroups: gmane.emacs.help Subject: Re: learning Emacs Lisp Date: Mon, 10 Nov 2008 20:07:26 -0800 (PST) Organization: http://groups.google.com Message-ID: <3dc09d96-f4cd-43ef-b327-a5e43dfa7022@g17g2000prg.googlegroups.com> References: <87k5bbjzvo.fsf@thinkpad.tsdh.de> <87ljvrl2l0.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1226386289 24130 80.91.229.12 (11 Nov 2008 06:51:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Nov 2008 06:51:29 +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 Nov 11 07:52:27 2008 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Kzn6v-0004BH-5z for geh-help-gnu-emacs@m.gmane.org; Tue, 11 Nov 2008 07:52:25 +0100 Original-Received: from localhost ([127.0.0.1]:57013 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kzn5n-0005t2-8u for geh-help-gnu-emacs@m.gmane.org; Tue, 11 Nov 2008 01:51:15 -0500 Original-Path: news.stanford.edu!newsfeed.stanford.edu!postnews.google.com!g17g2000prg.googlegroups.com!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 186 Original-NNTP-Posting-Host: 24.6.185.159 Original-X-Trace: posting.google.com 1226376446 1920 127.0.0.1 (11 Nov 2008 04:07:26 GMT) Original-X-Complaints-To: groups-abuse@google.com Original-NNTP-Posting-Date: Tue, 11 Nov 2008 04:07:26 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: g17g2000prg.googlegroups.com; posting-host=24.6.185.159; posting-account=bRPKjQoAAACxZsR8_VPXCX27T2YcsyMA User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_4_11; en) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.2 Safari/525.22, gzip(gfe), gzip(gfe) Original-Xref: news.stanford.edu gnu.emacs.help:164309 X-Mailman-Approved-At: Tue, 11 Nov 2008 01:50:54 -0500 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:59645 Archived-At: On Nov 10, 12:59 pm, Niels Giesen wrote: > Richard Riley writes: > > [...] > > > Of course. But eLisp is special in that its almost unreadable to the > > typical procedural programmer fluent in C/C++ etc until you know a lot > > if it already. Or that was my experience. And we all have different > > experiences so it does no harm to remain open as to what suits other > > people. > > Where is there any evidence that the original OP is a `typical > procedural programmer fluent in C/C++'? Vast majority of programers coming to emacs is familiar with procedural languages, such as C, C++, Java, perl, php, visual basic. The original poster may be a exception, but it is reasonable to make a general assumption when giving tips. > It annoys me to pieces that so many textbooks assume that everyone out > there is a C/C++/Java programmer. For me, Lisp was my first > programming language (thanks to Emacs, which I started using to write > law papers in), and I do not need textbooks to explain for instance > Ruby to me in Lisp (which is perfectly feasible) but I even less need > comparisons with Java or C. Even worse, doing so is a major > distraction from the real object of learning. > > Consider teaching Dutch to someone from Morocco but using English > during the lessons: that's just plain silly and simply leads to > unnecessary confusion. Using analogies from Slovak to teach Polish > however may be insightful, but only when the student already has > knowledge of a Slavic language. Same goes with programming languages: > do not assume. it is relevant to consider something vast majority of readers are already familiar of. Vast majority of programers, are familiar with one of procedural lang such as C, Java, C++, perl, visual basic. These are roughly maybe 95% of all programers. So, when teaching a new programing language, mentioning tips related to procedural lang is fruitful and effective. Similarly, when teaching a foreign lang, it makes sense to mention tips contrasting to the lang English. > When teaching something, teach it by itself; people willing to learn a > new language are most likely not stupid, and if they are somewhat > smart, they will find out for themselves what differences and > similarities there are between languages known already. you are of course just bitching. Of course, most tutorials do try to teach the lang itself, and very few are entirely based on transition from another lang, such as =E2=80=9CPython for Perl programers=E2=80=9D or = =E2=80=9CJava for C+ + programers=E2=80=9D, =E2=80=9CPHP for Perl programers=E2=80=9D, =E2=80=9C= Haskell for Lispers=E2=80=9D, etc. > For me, it would have been nice when learning JavaScript if the books > had warned me that not everything is an expression (invalid left-hand > assignment anyone?), that you have to explicitly return something, > that there are things such as keywords, and it would be nice if > textbooks explain how to take advantage of closures instead of trying > to get rid of them, hide them, and how to build an ugly half-assed > Class system. > > The first few of those would cause people coming from C or Java at > least to frown but most probably to get irritated ("Why would I care > about all these strange incomprehensible things from some dead > language with too many parens, when all I want to do is simply to > learn JavaScript?????"). Therefore, I would not recommend such in a > learning text on JavaScript. You were complaining about books giving tips of procedural lang tips. But now you are using a example of giving tips about lisp to illustrate how silly it is. Note that the books we are discussing, do not give tips about lisp, because it is a lang very few people know. However, books about functional langs do sometimes give relevant info for programers familiar with lisp. The principle is the same, namely, that for a significant portion of the readership, they are familiar with lang x, so the book give tips for lang x programers. For example, the official elisp reference gives many tips and warnings to those familiar with Common Lisp, and about C too. (to me, it is entirely distracting because i do not have working familiarity with Common Lisp or C, nor do i care about them. However, i'm the world's top expert in Mathematica, but vast majority of potential readers of elisp doc are not familiar with Mathematica.) Similarly, Perl doc or books often contain tips, warnings, about C, awk, unix shell. Books on regex will often give tips or mention about Perl lang's regex. All in all, these tips mentioning another lang is useful. They are useful because learning is faster when we can borrow knowledge from somethnig we already know. In summary, when a programing lang x book gives tips for lang y programers, it is because a significant portion of its potential readers are familiar with lang y, therefore the tips is effective. ----------------- There are other extremes. For example, some books do not mention any other lang for tips or comparison at all. Examples include Mathematica's doc (The Mathematica Book), Java Doc (so-called the =E2=80=9CJava API=E2=80=9D Java=E2=84=A22 Platform Standard Edition 5.0 API= Specification), Java Lang Spec, Scheme's r4rs. Typically, these are lang spec or official reference. On the other extreme, some books gets abusive in mentioning lots other langs instead of a proper description of the lang itself, often to the degree of making the doc itself unclear, confusing, or less useful. Example of this is Perl's doc (perldoc), Python doc. Typically, tutorial type of books tends to mention other langs, and some of them to a degree that's more damaging then helpful. As a example of the abusive use of mentioning other lang, here's a excerpt from Python doc on it's chapter about Python's class. It start thus: =C2=AB Python's class mechanism adds classes to the language with a minimum of new syntax and semantics. It is a mixture of the class mechanisms found in C++ and Modula-3. As is true for modules, classes in Python do not put an absolute barrier between definition and user, but rather rely on the politeness of the user not to ``break into the definition.'' The most important features of classes are retained with full power, however: the class inheritance mechanism allows multiple base classes, a derived class can override any methods of its base class or classes, a method can call the method of a base class with the same name. Objects can contain an arbitrary amount of private data. In C++ terminology, all class members (including the data members) are public, and all member functions are virtual. There are no special constructors or destructors. As in Modula-3, there are no shorthands for referencing the object's members from its methods: the method function is declared with an explicit first argument representing the object, which is provided implicitly by the call. As in Smalltalk, classes themselves are objects, albeit in the wider sense of the word: in Python, all data types are objects. This provides semantics for importing and renaming. Unlike C++ and Modula-3, built-in types can be used as base classes for extension by the user. Also, like in C++ but unlike in Modula-3, most built-in operators with special syntax (arithmetic operators, subscripting etc.) can be redefined for class instances. =C2=BB It is a form of author masterbation. In the case of Perl's official doc (perldoc), the workings of unix shell, awk, C is frequently mentioned in the doc as a way of explanation, just about every page on every function, instead of proper documentation independent of other langs. (partly for this reason, learning perl is difficult for those not from the unix/c background) The only perl book that properly discuss perl without borrowing other langs is =E2=80=9CPerl: The Programmer's Companion=E2=80=9D= (1997) by Nigel Chapman. Similarly, unix docs (the =E2=80=9Cman pages=E2=80=9D) are also like like. = Instead of proper spec of what a function or tool do, it is written in a way that assumes you know C and much of the workings of unix, and mentions them throughout in a confusing way. For much more discussion about documentation, see: =E2=80=A2 Python Documentation Problems http://xahlee.org/perl-python/python_doc_index.html (collection of 11 essays on python documentation problems, and on documentation in general) =E2=80=A2 survey of perl books http://xahlee.org/UnixResource_dir/perlr.html Xah =E2=88=91 http://xahlee.org/ =E2=98=84