unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Wei Weng <wweng@acedsl.com>
To: help-gnu-emacs@gnu.org
Subject: Re: learning Emacs Lisp
Date: Tue, 11 Nov 2008 01:49:37 -0500	[thread overview]
Message-ID: <1226386178.846337@nntp.acecape.com> (raw)
In-Reply-To: <87ljvrl2l0.fsf@gmail.com>

Niels Giesen wrote:
> Richard Riley <rileyrgdev@gmail.com> 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++'? 
> 
> 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.
> 
> 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.
> 
> 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.
> 
> The second however, how to make good use of lexical scoping, is
> interesting to learn, and should be explained by itself, as should be
> prototype based inheritance and functions as first-class things (two
> of which could - but should not - be explained by comparison with
> Lisp).
> 
> Comparisons with Java-style OOP however should not be in a basic
> textbook on learning JavaScript, and certainly no attempt should be
> made to mimic it -- for the very same reasons that comparisons with
> Lisp should not be made in a general textbook.

This is a very typical case of "Too many words, too few substances".

You spent all these time typing out all these words, I can summarize in 1 line:

Elisp is very different from C/C++/Java, and it is my (Niels) first language.


Thanks
Wei




  parent reply	other threads:[~2008-11-11  6:49 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-10 15:21 Grouping related buffers Corey Foote
2008-11-10 16:43 ` Tassilo Horn
2008-11-10 17:24   ` Corey Foote
2008-11-10 18:05     ` learning Emacs Lisp [was: Grouping related buffers] Drew Adams
     [not found]     ` <mailman.9.1226340315.26697.help-gnu-emacs@gnu.org>
2008-11-10 18:27       ` learning Emacs Lisp Richard Riley
2008-11-10 19:22         ` Tassilo Horn
2008-11-10 19:48           ` Drew Adams
     [not found]         ` <mailman.17.1226345002.26697.help-gnu-emacs@gnu.org>
2008-11-10 19:36           ` Richard Riley
2008-11-10 20:59             ` Niels Giesen
2008-11-10 21:24               ` Richard Riley
2008-11-11  4:07               ` Xah
2008-11-12  0:24                 ` B. T. Raven
2008-11-12  3:32                   ` Xah
2008-11-11  6:49               ` Wei Weng [this message]
2008-11-11 18:58                 ` Niels Giesen
2008-11-11  4:56             ` Andreas Politz
2008-11-11  8:48               ` Richard Riley
2008-11-11  9:57                 ` Andreas Politz
2008-11-11 10:14                 ` Lennart Borgman
     [not found]                 ` <mailman.58.1226398497.26697.help-gnu-emacs@gnu.org>
2008-11-11 10:34                   ` Richard Riley
2008-11-11 10:43                 ` Juanma Barranquero
2008-11-11 11:04                   ` Richard Riley
2008-11-11 11:17                     ` Juanma Barranquero
2008-11-10 18:26 ` Grouping related buffers Drew Adams
     [not found] ` <mailman.0.1226335408.26697.help-gnu-emacs@gnu.org>
2008-11-13 13:09   ` Stefan Kamphausen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1226386178.846337@nntp.acecape.com \
    --to=wweng@acedsl.com \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).