[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Quit [now definitely O/T]
Re: Quit [now definitely O/T]
Thu, 12 Nov 2009 19:47:43 +0100
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++
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.
Re: Quit [now definitely O/T], David Kastrup, 2009/11/12
Re: Quit [now definitely O/T], Chris Snyder, 2009/11/12
Re: Quit [now definitely O/T], Frédéric Bron, 2009/11/12
Re: Quit [now definitely O/T], Patrick McCarty, 2009/11/12