Re: learning Emacs Lisp

[Xah]

On Nov 10, 12:59 pm, Niels Giesen <niels.gie...@gmail.com> wrote:
> Richard Riley <rileyrg...@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++'?

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 “Python for Perl programers” or “Java for C+
+ programers”, “PHP for Perl programers”, “Haskell for Lispers”, 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
“Java API” Java™2 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:

«
    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.
»

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 “Perl: The Programmer's Companion” (1997) by
Nigel Chapman.

Similarly, unix docs (the “man pages”) 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:

• 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)

• survey of perl books
http://xahlee.org/UnixResource_dir/perlr.html

  Xah
∑ http://xahlee.org/

☄