all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Niels Giesen <niels.giesen@gmail.com>
To: help-gnu-emacs@gnu.org
Subject: Re: learning Emacs Lisp
Date: Mon, 10 Nov 2008 21:59:23 +0100	[thread overview]
Message-ID: <87ljvrl2l0.fsf@gmail.com> (raw)
In-Reply-To: gfa2ge$rev$1@registered.motzarella.org

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.


  reply	other threads:[~2008-11-10 20:59 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 [this message]
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
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

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

  git send-email \
    --in-reply-to=87ljvrl2l0.fsf@gmail.com \
    --to=niels.giesen@gmail.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.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.