From: Xah Lee <xahlee@gmail.com>
To: help-gnu-emacs@gnu.org
Subject: Re: About Emacs Modernisation Project
Date: Tue, 1 Jun 2010 23:17:56 -0700 (PDT) [thread overview]
Message-ID: <dd36291d-b994-4415-bdf6-6db75c60fa10@q39g2000prh.googlegroups.com> (raw)
In-Reply-To: 87iq63wsvt.fsf@kuiper.lan.informatimago.com
On May 31, 4:31 pm, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> Alessandro Piras <lay...@gmail.com> writes:
> > LanX <lanx.p...@googlemail.com> writes:
>
> >> Hi
>
> >> I doubt that Python would be a good choice, Perl for instance has much
> >> more in common with LISP.
>
> >> And I doubt that eLISP is the reason why many people have problems
> >> with emacs, it's more that many "modern" GUI mechanisms and
> >> terminologies are not default in emacs, which frustrates newbies.
>
> >> IMHO an alternative (but compatible ) eLISP-dialect simply allowing to
> >> swap parens and functionnames and to write "message(...)" instead of
> >> "(message...)" would increase the acceptance immidiately.
>
> > Sounds Like M-expressions. It has been tried in the past in the Lisp world,
> > without much success. Most programmers realize after few time the
> > sweetness of S-expressions and macros. I think it would just lead to a
> > small amount of M-expressions code that would be soon refactored as
> > S-expressions.. Not worth the effort I suspect.
>
> This is important to understand.
>
> Asking to write function(argument) in lisp, is like asking to write:
>
> int a[]=1{2,3,4};
>
> in C.
>
> Yes, 1{2,3,4} instead of {1,2,3,4} is totally silly in C. Why would
> you want to put the first element of a list of values outside of the
> list?
>
> It just happen that code is data and there is no more any point in
> putting the first element of a function application outside of the
> list.
>
> f(a,b,c) goes in most languages, because they make an artificial
> distinction between code and data, and the implication of this is that
> they need big parsers, and cannot mix compilation time with run time.
>
> But in lisp, since we write (f a b c) like we write (1 2 3 4), the
> parser becomes trivial, and the code can be processed as easily as any
> other data, therefore we can write macros (which are compiler hooks)
> and use the compiler at run-time.
>
> This feature is called "homoiconicity".
The above opinion is biased and basically bullshit.
The throwing in of the jargon homoiconicity is just to a sales pitch.
if you read Wikipedia:
http://en.wikipedia.org/wiki/Homoiconicity
you see this paragraph:
---------------
Languages which are considered to be homoiconic include members of the
Lisp family, Nemerle, Curl, REBOL, SNOBOL, XSLT, XQuery, TRAC, Tcl,
Io, Ioke, Joy, Factor, Pico, PostScript, Prolog, R, Mathematica, V
and Clojure.[citation needed]
In Von Neumann architecture systems (including the vast majority of
general purpose computers today), raw machine code also has this
property, the data type being bytes in memory.
----------------
So, this “homoiconicity” has little to do with lisp's syntax or
whatever it is supposed to be relevant.
also, note that XML also has lisp's advantage of regular syntax, and
there are computing langs based on xml syntax today. Note that lisp
syntax is not strictly regular. For a more regular syntax, there's XML
and Mathematica.
also, the oft quoted concept of “code is data” is seldom ever defined.
When asked a lisp, each has different take. Basically, it means
nothing more than a strictly uniform and regular syntax, which lisp's
isn't the better example among languages.
another thing lisp lovers inevitable love to cite is macros. Note
that, a whole class of languages that are based on pattern matching,
is a order of magnitude more powerful than classic lisps.
For detail, see:
• Fundamental Problems of Lisp
http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
Xah
∑ http://xahlee.org/
☄
next prev parent reply other threads:[~2010-06-02 6:17 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <143c6d28-4423-4e43-9fc5-c0fb3340043b@c11g2000vbe.googlegroups.com>
2010-05-31 15:44 ` About Emacs Modernisation Project Pascal J. Bourguignon
[not found] ` <0e994fe3-6dde-449f-879d-6701c7a195a9@e28g2000vbd.googlegroups.com>
2010-05-31 19:41 ` Alessandro Piras
[not found] ` <87iq63wsvt.fsf@kuiper.lan.informatimago.com>
2010-06-01 0:06 ` LanX
2010-06-01 8:44 ` Pascal J. Bourguignon
2010-06-01 11:19 ` LanX
2010-06-01 12:56 ` Pascal J. Bourguignon
2010-06-02 6:17 ` Xah Lee [this message]
[not found] ` <c41c63c0-b934-442d-8385-1abff6ab9b0b@s41g2000vba.googlegroups.com>
2010-06-01 0:40 ` Alessandro Piras
2010-06-02 6:07 ` Xah Lee
[not found] ` <87ljazofkn.fsf@rapttech.com.au>
2010-05-31 23:33 ` LanX
[not found] ` <87r5krh3e0.fsf@unm.edu>
2010-06-01 8:40 ` Pascal J. Bourguignon
2010-06-01 17:34 ` rustom
2010-06-02 12:47 ` B. T. Raven
2010-06-02 17:20 ` rustom
2010-06-01 19:50 ` Stefan Monnier
2010-06-01 23:22 ` LanX
[not found] ` <slrni0b8nm.9k6.bergv@u00.math.uiuc.edu>
2010-06-02 11:39 ` Pascal J. Bourguignon
[not found] ` <e73e123d-3f0c-4a6f-bbac-b91fb71bf07d@f14g2000vbn.googlegroups.com>
2010-06-03 9:26 ` Emulating namespaces Pascal J. Bourguignon
2010-06-03 15:33 ` LanX
2010-06-03 17:41 ` Pascal J. Bourguignon
[not found] ` <87mxvegz12.fsf@unm.edu>
2010-06-01 23:36 ` About Emacs Modernisation Project Pascal J. Bourguignon
2010-06-02 5:58 ` Evans Winner
2010-06-01 10:28 ` Helmut Eller
2010-06-01 11:27 ` LanX
2010-06-01 12:29 ` Helmut Eller
2010-06-01 12:55 ` LanX
2010-06-01 12:59 ` Pascal J. Bourguignon
2010-06-01 12:59 ` Pascal J. Bourguignon
2010-06-02 17:05 ` Xah Lee
2010-06-02 17:50 ` Helmut Eller
2010-06-04 18:33 ` Joseph Brenner
2010-06-05 2:55 ` Tim X
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=dd36291d-b994-4415-bdf6-6db75c60fa10@q39g2000prh.googlegroups.com \
--to=xahlee@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.