Do we need a "Stevens" book?

Do we need a "Stevens" book?

[Olwe Melwasul]

I've not gotten very far with this idea; no one seems interested, but
I'll try it here anyway...

It seems to me that Emacs needs a W. Richard Stevens-style book. As
you may know, Stevens wrote the "Advanced Programming in the UNIX(R)
Environment" textbook that many of us used in college. Or maybe Emacs
needs something along the lines of the many "Linux gnarly/wooly
internals" books. Anyway, I would love to see a book that got into the
nitty-gritty of Emacs/elisp -- just like you see discussed here every
day on the help-gnu-emacs list.

Here's an example: comint. How do you effectively use comint? When
should you use comint? Okay, I can Google around and find one-off blog
discussions here and there about comint; I can read them all; I can
get confused; I can kludge something together ... and then find out
later that what I've done (as well as bloggers A, B, and C) is really
not "best practice" use of comint, i.e., that how I've used comint is
overkill or could have been done much simpler with <some other>.el.
Wouldn't it be nice to have one go-to source/book that thrashed out
comint usage once and for all?

Just skimming through all the elisp material (books, Internet, etc.),
it seems like a hodge-podge on a continuum between gems and junk just
waiting for a clear-speaking Richard Stevens to whip it all into
shape. Sure, the "official" texts will get you pretty far, but no way
are you ready to be a "best-practices" guru. The printed books seem
more like a "cookbook" than a real Stevens-style book. Maybe I'm all
wrong, but I think I like what the Racket/PLT people are doing. They
seem to be whipping the Scheme hodge-podge into a decent
best-practices, best-tools order.

Personally I've been admiring Emacs from afar for quite some time. I'm
really an Emacs/elisp newbie, but I've got a writing/technical writing
background. If what I'm saying strikes a chord, maybe I could be a
receiver/collector of a "best-practices-slash-wooly internals" sorta
book project. It would be a free/GNU sorta thing of course ... and
please don't say "I don't think there'd be enough interest in it."

Olwe

Re: Do we need a "Stevens" book?

[Pascal J. Bourguignon]

Olwe Melwasul <hercynianforest@gmail.com> writes:

> I've not gotten very far with this idea; no one seems interested, but
> I'll try it here anyway...
>
> It seems to me that Emacs needs a W. Richard Stevens-style book. As
> you may know, Stevens wrote the "Advanced Programming in the UNIX(R)
> Environment" textbook that many of us used in college. Or maybe Emacs
> needs something along the lines of the many "Linux gnarly/wooly
> internals" books. Anyway, I would love to see a book that got into the
> nitty-gritty of Emacs/elisp -- just like you see discussed here every
> day on the help-gnu-emacs list.
>
> Here's an example: comint. How do you effectively use comint? When
> should you use comint? Okay, I can Google around and find one-off blog
> discussions here and there about comint; I can read them all; I can
> get confused; I can kludge something together ... and then find out
> later that what I've done (as well as bloggers A, B, and C) is really
> not "best practice" use of comint, i.e., that how I've used comint is
> overkill or could have been done much simpler with <some other>.el.
> Wouldn't it be nice to have one go-to source/book that thrashed out
> comint usage once and for all?
>
> Just skimming through all the elisp material (books, Internet, etc.),
> it seems like a hodge-podge on a continuum between gems and junk just
> waiting for a clear-speaking Richard Stevens to whip it all into
> shape. Sure, the "official" texts will get you pretty far, but no way
> are you ready to be a "best-practices" guru. The printed books seem
> more like a "cookbook" than a real Stevens-style book. Maybe I'm all
> wrong, but I think I like what the Racket/PLT people are doing. They
> seem to be whipping the Scheme hodge-podge into a decent
> best-practices, best-tools order.
>
> Personally I've been admiring Emacs from afar for quite some time. I'm
> really an Emacs/elisp newbie, but I've got a writing/technical writing
> background. If what I'm saying strikes a chord, maybe I could be a
> receiver/collector of a "best-practices-slash-wooly internals" sorta
> book project. It would be a free/GNU sorta thing of course ... and
> please don't say "I don't think there'd be enough interest in it."


It could be an "Olwe Melwasul" book.  It would be interesting if you
could indeed make it pedagogical and compelling enough so that
more students want to use and learn emacs instead of vi.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

Re: Do we need a "Stevens" book?

[Andreas Röhler]

Am 28.07.2010 18:42, schrieb Olwe Melwasul:
> I've not gotten very far with this idea; no one seems interested, but
> I'll try it here anyway...
>
> It seems to me that Emacs needs a W. Richard Stevens-style book. As
> you may know, Stevens wrote the "Advanced Programming in the UNIX(R)
> Environment" textbook that many of us used in college. Or maybe Emacs
> needs something along the lines of the many "Linux gnarly/wooly
> internals" books. Anyway, I would love to see a book that got into the
> nitty-gritty of Emacs/elisp -- just like you see discussed here every
> day on the help-gnu-emacs list.
>
> Here's an example: comint. How do you effectively use comint? When
> should you use comint? Okay, I can Google around and find one-off blog
> discussions here and there about comint; I can read them all; I can
> get confused; I can kludge something together ... and then find out
> later that what I've done (as well as bloggers A, B, and C) is really
> not "best practice" use of comint, i.e., that how I've used comint is
> overkill or could have been done much simpler with<some other>.el.
> Wouldn't it be nice to have one go-to source/book that thrashed out
> comint usage once and for all?
>
> Just skimming through all the elisp material (books, Internet, etc.),
> it seems like a hodge-podge on a continuum between gems and junk just
> waiting for a clear-speaking Richard Stevens to whip it all into
> shape. Sure, the "official" texts will get you pretty far, but no way
> are you ready to be a "best-practices" guru. The printed books seem
> more like a "cookbook" than a real Stevens-style book. Maybe I'm all
> wrong, but I think I like what the Racket/PLT people are doing. They
> seem to be whipping the Scheme hodge-podge into a decent
> best-practices, best-tools order.
>
> Personally I've been admiring Emacs from afar for quite some time. I'm
> really an Emacs/elisp newbie, but I've got a writing/technical writing
> background. If what I'm saying strikes a chord, maybe I could be a
> receiver/collector of a "best-practices-slash-wooly internals" sorta
> book project. It would be a free/GNU sorta thing of course ... and
> please don't say "I don't think there'd be enough interest in it."
>
> Olwe
>
>


Hi,

would welcome such an effort.

However, some obstacles are in the way:

a basic of Emacs is it's extensibility also for
non-programmers.

Everyone is encouraged to read Robert Chassell's  Emacs Lisp Intro,
to try out something.

Thats a great pleasure and source of
inovation. Naturally, as many hackers are not
professional programmers, a kind of wilderness grows
out of these efforts.

Nothing wrong so far IMHO.

After that I'd welcome a kind of mutually code critic,
as far as it's not used to intimidate neebies.

BTW started a kind of bill-board collecting examples, best practises
here:

http://repo.or.cz/w/elbb.git


Best regards,


Andreas

--
https://code.launchpad.net/~a-roehler/python-mode
https://code.launchpad.net/s-x-emacs-werkstatt/

Re: Do we need a "Stevens" book?

[Richard Riley]

Olwe Melwasul <hercynianforest@gmail.com> writes:

> I've not gotten very far with this idea; no one seems interested, but
> I'll try it here anyway...
>
> It seems to me that Emacs needs a W. Richard Stevens-style book. As
> you may know, Stevens wrote the "Advanced Programming in the UNIX(R)
> Environment" textbook that many of us used in college. Or maybe Emacs
> needs something along the lines of the many "Linux gnarly/wooly
> internals" books. Anyway, I would love to see a book that got into the
> nitty-gritty of Emacs/elisp -- just like you see discussed here every
> day on the help-gnu-emacs list.
>
> Here's an example: comint. How do you effectively use comint? When
> should you use comint? Okay, I can Google around and find one-off blog
> discussions here and there about comint; I can read them all; I can
> get confused; I can kludge something together ... and then find out
> later that what I've done (as well as bloggers A, B, and C) is really
> not "best practice" use of comint, i.e., that how I've used comint is
> overkill or could have been done much simpler with <some other>.el.
> Wouldn't it be nice to have one go-to source/book that thrashed out
> comint usage once and for all?
>
> Just skimming through all the elisp material (books, Internet, etc.),
> it seems like a hodge-podge on a continuum between gems and junk just
> waiting for a clear-speaking Richard Stevens to whip it all into
> shape. Sure, the "official" texts will get you pretty far, but no way
> are you ready to be a "best-practices" guru. The printed books seem
> more like a "cookbook" than a real Stevens-style book. Maybe I'm all
> wrong, but I think I like what the Racket/PLT people are doing. They
> seem to be whipping the Scheme hodge-podge into a decent
> best-practices, best-tools order.
>
> Personally I've been admiring Emacs from afar for quite some time. I'm
> really an Emacs/elisp newbie, but I've got a writing/technical writing
> background. If what I'm saying strikes a chord, maybe I could be a
> receiver/collector of a "best-practices-slash-wooly internals" sorta
> book project. It would be a free/GNU sorta thing of course ... and
> please don't say "I don't think there'd be enough interest in it."
>
> Olwe

I believe Sacha Chua is/was writing something along those lines.

Re: Do we need a "Stevens" book?

[Stefan Monnier]

> Personally I've been admiring Emacs from afar for quite some time. I'm
> really an Emacs/elisp newbie, but I've got a writing/technical writing
> background. If what I'm saying strikes a chord, maybe I could be a
> receiver/collector of a "best-practices-slash-wooly internals" sorta
> book project. It would be a free/GNU sorta thing of course ... and
> please don't say "I don't think there'd be enough interest in it."

That would be welcome, yes (he said, after (and probably before as well)
years of cleaning up messy code).

Maybe a good way to do that is to try and get experienced Emacsers to do
the effort of recording all/some of the "cleanup" they perform (as
patches).  Then later on, someone can go through those patches and try
and extract principles from them.


        Stefan

Re: Do we need a "Stevens" book?

[Thien-Thi Nguyen]

() Olwe Melwasul <hercynianforest@gmail.com>
() Wed, 28 Jul 2010 11:42:14 -0500

   Okay, I can Google [...]

Why does the search start with Google (and continue with other
downstream, non-terminating, whirlpool-shaped, out of date, referenda)?
Why not go to the source?  The Emacs Lisp manual, the Emacs Lisp code,
the Emacs customization facility, the Emacs *scratch* buffer, the Emacs!

   Personally I've been admiring Emacs from afar for quite some time.

Pirsig sez: Quality is the moment of perception.
Afar dilutes this.  Stop it.

Re: Do we need a "Stevens" book?

[rustom]

On Jul 29, 11:40 am, Thien-Thi Nguyen <t...@gnuvola.org> wrote:
> () Olwe Melwasul <hercynianfor...@gmail.com>
> () Wed, 28 Jul 2010 11:42:14 -0500
>
>    Okay, I can Google [...]
>
> Why does the search start with Google (and continue with other
> downstream, non-terminating, whirlpool-shaped, out of date, referenda)?
> Why not go to the source?  The Emacs Lisp manual, the Emacs Lisp code,
> the Emacs customization facility, the Emacs *scratch* buffer, the Emacs!

Because google searches the world wide web faster and better (usually)
than me searching my info dir
Unfortunately 'usually' is not 'always' -- hence Olwe's wish is valid

>
>    Personally I've been admiring Emacs from afar for quite some time.
>
> Pirsig sez: Quality is the moment of perception.
> Afar dilutes this.  Stop it.

My comint.el reads at 3538 lines.
Also a
$ find ~/local/share/emacs/23.1/lisp -name '*.el.gz'  |  xargs zcat
|  wc -l
returns 1076048

Spelt out, thats a million lines of elisp only in the default emacs
install

Now what exactly were you saying?

Re: Do we need a "Stevens" book?

[Elena]

On Jul 29, 6:40 am, Thien-Thi Nguyen <t...@gnuvola.org> wrote:
> Why does the search start with Google (and continue with other
> downstream, non-terminating, whirlpool-shaped, out of date, referenda)?
> Why not go to the source?  The Emacs Lisp manual, the Emacs Lisp code,
> the Emacs customization facility, the Emacs *scratch* buffer, the Emacs!

Surprisingly enough - or not? - it seems few users do read the
manuals... I'm guilty of this too (and Emacs' manuals will be my
reading on my next vacations). Emacs is too much a complex (not
difficult) and powerful software to be used by intuition alone, unlike
many softwares we are used to.

RTFM! RTFM! RTFM! ...

Re: Do we need a "Stevens" book?

[Fren Zeee]

On Jul 29, 2:55 pm, Xah Lee <xah...@gmail.com> wrote:
> 2010-07-29
>
> On Jul 29, 3:02 am, Elena <egarr...@gmail.com> wrote:
>
> > On Jul 29, 6:40 am, Thien-Thi Nguyen <t...@gnuvola.org> wrote:
>
> > > Why does the search start with Google (and continue with other
> > > downstream, non-terminating, whirlpool-shaped, out of date, referenda)?
> > > Why not go to the source?  The Emacs Lisp manual, the Emacs Lisp code,
> > > the Emacs customization facility, the Emacs *scratch* buffer, the Emacs!
>
> > Surprisingly enough - or not? - it seems few users do read the
> > manuals... I'm guilty of this too (and Emacs' manuals will be my
> > reading on my next vacations).
>
> i always thought of doing this, but just never did. Not the emacs
> manual, nor the elisp manual. Over the past 12 years of using emacs
> daily, i probably have read only 1/2 of each, counted in a
> accumulative way.
>
> However, i have read cover to cover, word for word, systematically in
> a continued setting, several programing lang or software docs/books.
> For examples:
>
> --------------------
>
> • Microsoft Word manual i've basically read cover to cover in about
> 1992. (stopped using Microsoft Word completely in about 1999)
>
> --------------------
> • HP-28S Advanced Scientific Calculator manual. (2 books) I read cover
> to cover, i think twice, in about 1991. In fact this is how i learned
> programing, my first computer language, and the first i mastered.
>
> • HP-28S Advanced Scientific Calculator
>  http://xahlee.org/prog/hp28s/hp28s.html
>
> • Xah Lee's Computing Experience Bio
>  http://xahlee.org/PageTwo_dir/Personal_dir/xah_comp_exp.html
>
> --------------------
> • Mathematica manual (aka the Mathematica Book) i've read 3 times in
> separate years, from cover to cover. Note that Mathematica the
> software, the subject it deals with, is inherently a order of
> magnitude more complex than emacs. (the Mathematica book is over 1k
> pages.
> e.g.http://www.amazon.com/Mathematica-Book-Fourth-Stephen-Wolfram/dp/0521...
>
> since early 2000s, the software don't come with the book anymore, and
> am not sure if they still produce printed manual at all now... change
> with times...
> )
>
> --------------------
> • The Perl book/manual/“man pages”. I've read basically cover to cover
> in about 1998, 1999. (yes, i own the printed book. The printed book
> aka The Camel Book is edited version of the man pages. Actually i read
> all major perl books in late 2000s.
> See:
> • Pathetically Elational Regex Language (PERL)
>  http://xahlee.org/UnixResource_dir/perlr.html
> )
>
> > Emacs is too much a complex (not
> > difficult) and powerful software to be used by intuition alone, unlike
> > many softwares we are used to.
>
> This is simply not true.
>
> For example, from personal experience, Blender, Second Life both are
> more complex than emacs, both for learning it, as well in terms of
> effort or complexity of their implementation, as well as inherent
> complexity by the nature of what the software do.
>
> Second Life i've been using for about 3 years now. see:
>
> • A Photographic Tour of Life in Second Life
>  http://xahlee.org/sl/index.html
>
> Blender i started to learn this year... but really too complex...
>
> I'd say, Blender or Second Life, each, are a order magnitude more
> complex and rich than emacs, either you consider simple use aspect, or
> deep use aspect such as extension and programing them.
>
> Also, depending on what you mean by use... for example, if you go into
> the programing aspect, then programing Java, C, C++, all are far more
> difficult and complex than programing emacs lisp. If you are thinking
> of using emacs lisp to program major/minor emacs modes, manipulate
> font, creating clients, etc, than, OS GUI platforms such as Mac or
> Windows is a order far more complex as well powerful.
>
> am writing this because i want to dispel certain cult phenomen about
> emacs... on the net we often hear some god-like thing about emacs, but
> i think if you look at it seriously, usually much of it doesn't mean
> anything.
>
> since i kept thinking about this issue over the years, and in argument
> with many old-time emacs users, i thought about the question: if there
> is any way, or comment, about emacs that we can justify in claming,
> about its complexity, deepth, god-like quality, superiority etc.
>
> i think to that question we need to be specific. If some claim is made
> specific, then it can be easily judged on its veracity. For examples,
> the following i think can be reasonably claimed:
>
> Emacs is most suitable tool for text manipulation tasks that are
> complex and not-well-defined and requires interactive human watch.
> (See: • Why Emacs is Still so Useful Today  http://xahlee.org/emacs/emacs_power_story.html)
>
> Emacs is most flexible, customizable, user extensible text editor.
>
> Emacs is the most well known and widely used editor that has a
> embedded programing language for text editing.
>
> Emacs system (emacs+elisp) for text manipulation is probably the most
> versatile computer language for text processing. (• Text Processing:
> Elisp vs Perl  http://xahlee.org/emacs/elisp_text_processing_lang.html
> )
>
> the above claims are still not so precise, but are items i think can
> be reasonably justified. Or can be made more precise, so that the sum
> of them can makes sense to say that emacs is quite powerful and
> versatile.
>
> On the other hand, the following i think are in the category of myths:
>
> • emacs manual is one of the best manual.
>
> • emacs's keyboard system is most well designed, or most extensible,
> or most consistent.
>
> • emacs keyboard shortcuts and the way they are mapped to emacs's text
> manipulation commands, is a very efficient system. (e.g. ratio of
> number of commands to call over arbitary text manipulation tasks)
>
> ...
>
> there are a lot such myths going around different communities. In perl
> community, it's filled to the brim about how perl is this or that
> great. In the Common Lisp community, you hear fantastic things about
> lisp being the god of all programing languages, while people in this
> community almost never mention emacs lisp as a language, and if they
> do, it's all sneer and spits and attacks to no ends. In the Scheme
> community, likewise you hear how it is the most beautiful, the most
> powerful, of all, period. ( See:http://xahlee.org/UnixResource_dir/writ/scheme_fail.htmlhttp://xahlee.org/UnixResource_dir/writ/lang_purity_cult_deception.html
>  ) In unix community, usually hated by lispers of all walks of life,
> you hear how unix is the most versatile, it's “KISS” et al
> philosophy's greatness, etc. (see • The Nature of the Unix Philosophyhttp://xahlee.org/UnixResource_dir/writ/unix_phil.html) Likewise,
> there's also commercially generated myths, e.g. Java, about how it
> solves all cross-platform problems, and how OOP solves the world's
> programing problems, etc.
>
> all these spur from communities that developed certain cult following.
> Ultimately, it's more harmful than good.
>
> What i like to say, is that, yes i love emacs and you love emacs.
> However, when praising, be specific on what you like about it, and
> avoid cultivating some sense of greatness that's not based on fact or
> can't be very meaningful.
>
>   Xah
> ∑http://xahlee.org/
>
> ☄

If you say, and I take your word on face value, that emacs is so
simple - and that you spent so much effort on softwares that you later
abandoned like MS Word etc - explain here then, just the C code of
eval.c and eval.h and how to add a primitive.

A concrete example has to follow the very generalized claims.

Make a small demonstrative translation with a metacircular eval and
its translation to C side by side.
A small diagram to explain the garbage collector operation (Is he
using the mark and sweep or another algorithm?).

In addition, if Mathematica is Lisp in disguise with some additional
code for computer algebra, its not that much more complicated than
emacs.

Re: Do we need a "Stevens" book?

[Thien-Thi Nguyen]

() Thien-Thi Nguyen <ttn@gnuvola.org>
() Thu, 29 Jul 2010 08:40:46 +0200

   Afar dilutes this.  Stop it.

This was uncalled for.  I apologize for the tone.

WRT comint, the main message still stands, however.  Why don't you take
a look at comint.el and post specific questions about what you find?
Consider it a shared exercise in (re-)searching a future "Hacking Emacs"
book.  The discussion on this mailing list (apart from my chilipepper
pining headache induced vapidity) could be the start of something.

Re: Do we need a "Stevens" book?

[Ken Hori]

I am all for any emacs / elisp visualizer. Emacs, at least its
documentations, has been devoid of pictures historically. I would love
to see it reverted.

On Fri, Jul 30, 2010 at 5:28 AM, Thien-Thi Nguyen <ttn@gnuvola.org> wrote:
> () Thien-Thi Nguyen <ttn@gnuvola.org>
> () Thu, 29 Jul 2010 08:40:46 +0200
>
>   Afar dilutes this.  Stop it.
>
> This was uncalled for.  I apologize for the tone.
>
> WRT comint, the main message still stands, however.  Why don't you take
> a look at comint.el and post specific questions about what you find?
> Consider it a shared exercise in (re-)searching a future "Hacking Emacs"
> book.  The discussion on this mailing list (apart from my chilipepper
> pining headache induced vapidity) could be the start of something.
>
>

Re: Do we need a "Stevens" book?

[Joseph Brenner]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Personally I've been admiring Emacs from afar for quite some time. I'm
>> really an Emacs/elisp newbie, but I've got a writing/technical writing
>> background. If what I'm saying strikes a chord, maybe I could be a
>> receiver/collector of a "best-practices-slash-wooly internals" sorta
>> book project. It would be a free/GNU sorta thing of course ... and
>> please don't say "I don't think there'd be enough interest in it."
>
> That would be welcome, yes (he said, after (and probably before as well)
> years of cleaning up messy code).
>
> Maybe a good way to do that is to try and get experienced Emacsers to do
> the effort of recording all/some of the "cleanup" they perform (as
> patches).  Then later on, someone can go through those patches and try
> and extract principles from them.

Sounds good, of course.  A page at the emacswiki?

I can think of an even simpler step that would be useful:

Make a list of files in the code base that are already cleaned
up, that you feel are good examples of the best practice in coding.

Possibly this could just be a page up at the emacswiki, too.