[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Quit [now definitely O/T]

From: David Kastrup
Subject: Re: Quit [now definitely O/T]
Date: Thu, 12 Nov 2009 19:47:43 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

Jesús Guillermo Andrade <address@hidden> writes:

> El 12/11/2009, a las 04:11 a.m., David Kastrup escribió:
>     Jan Nieuwenhuizen <address@hidden> writes:
>         As a new contributor/developer, by using a different, and a particular
>         unfriendly platform for free software development, you are faced with
>         tackling several difficult problems at once.
>     access to the Elisp data structures.  _If_ Emacs has the principal
>     capabilities for some task, you can code the whole task in Elisp.
>     This does not appear to be doable with Lilypond's Scheme.  At
>     least not to the degree where it is the preferred way of thinking
>     about new tasks.
> Lilypond's Scheme is GUILE's Scheme. And the fact you are pointing out
> is repeatedly found on hundreds of blogs around the internet ,
> whenever some Java/ C/C++ programmer is faced with Scheme/Lisp. They
> all have said the same thing: How come we have to use such and old
> language, when we have such great new (and modern!)  new ones that
> could handle everything easily?

Huh?  Did you understand at all what I have been trying to say?  My
complaint is not that I have to use Scheme.  Quite contrary.  My
complaint is that using Scheme is not sufficient and I have to use C++
as well.

And that's a nuisance.

> Fashionability is the keyword here.

No.  Limiting the required knowledge to actually do something is the

>     For a start from scratch, Lua would be a nice choice:
>     message-passing coroutines (very nice for translators keeping
>     context!), procedural syntax, very portable, fast.  And you can
>     learn everything worth knowing about it in few days.
> Why not Java? or Objective C for that matter?

Because the syntax diagram for Lua fits on one half-letter page.
Because it has a single data structure (the table).  Because in two days
you have learnt all that is relevant to learn about Lua, and can turn to
learning about Lilypond.

> ... Or Ada, or COBOL, or ALGOL or Fortran, or
> ... hmmm... gosh... there are so many. In the beggining (1958) there
> were only 2. And currently just Lisp stays strong and way ahead of all
> others in terms of flexibility, scalabilty and freedom to do whatever
> anybody might want.

Not really.  Emacs Lisp is a fossilized half-lexical abomination.  But
it does the job.  And most Lisp is designed as functional, and
programmed as procedural, with the fundamental data structure, the list,
being basically non-scope-local.

And that's the main point: does the job.  The one thing Emacs Lisp has
going over Common Lisp that it is a reasonably limited language to learn
in comparison.  Which is a nuisance to seasoned Lisp programmers, and
gets quite more people to meddle with it.

>     I can actually understand and work with the Lua coroutines.  In
>     contrast, I am not sure that trying to solve tasks with Scheme...
> That is a problem of perspective that is faced with all programmers
> that have ever read one line of scheme/lisp code. The problem has
> historical roots and has been documented elsewere. Notwithstanding,
> there are several ways to overcome this perpective limitation.

Oh come on, get down from your high horse.  I am maintaining Emacs Lisp
packages and have written a few.  I am familiar with the proceduralisms
of applied Lisp, but it does not mean I can't write something in a
functional style like

((lambda (f n) (f f n)) (lambda (f n) (if (> n 1) (* n (f f (- n 1))) 1)) 5)

>     Scheme might not be the nicest language for programming, but being
>     able to solve everything important in some application in _one_
>     language without need of recompiling (or heap management) or
>     language interfacing would be a good step towards recruiting new
>     programmers and solving tasks, partly in form of libraries or
>     packages which can be just used on-demand rather than needing to
>     be compiled in.
> Where can I vote? 

In the usual way, with patches on the list.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]