Re: Discuss signature for new function \annotate (new version)

[David Kastrup]

Urs Liska <address@hidden> writes:

> On 06/12/2013 02:50 PM, Tim Slattery wrote:
>> Thomas Morley <address@hidden> wrote:
>>
>>> Once I did a first step into C++
>>> The common "hello world"
>>> I had to _compile_ it to make it work.
>>> That makes a great difference for usability in LilyPond.
>> I've been programming for over forty years, so I know something about
>> it. Yes, you had to compile your C++ code to make a standalone
>> program. If you made a standalone program with Scheme you'd probably
>> have to do the same.

Not really.  Scheme interpreters abound.  Including GUILE.  And since
one of the main point of the LISP family is being able to directly work
with programs and their representation themselves and creating code on
the fly, a purely compiling environment is missing the point of the
language for quite a number of applications.

>> So called "scripting languages" like Perl, Ruby, Python, etc have to
>> be run through their interpreters. That is, you can't just have the
>> Perl program on your machine, you also have to have the Perl
>> interpreter. Your compiled C++ program can be run on a computer that
>> does not have a C++ compiler installed.

Short of linking statically, you still need a C++ runtime.

>> Both approaches have advantages and disadvantages.
>>
> That's what I'm feeling too from a different perspective.
> LISP is being characterized here as being a superior language because
> it is a natural way to give instructions to the computer.

No, that's quite a mischaracterization of what I have been writing.
There is no such thing as a "superior language": computer languages
always involve tradeoffs.  I have been explaining the tradeoffs behind
Scheme against catcalls of the "Scheme is different out of shere malice,
and there is no sense in it being different" sort, and how these
tradeoffs are to a reasonable degree a fit to the goals for an extension
language for LilyPond.

> No added layer of complexity added to bother the interpreter.
> That is because the burden of modeling the world and boiling it down
> to executable steps is shifted toward the programmer.

Again, you fancy yourself in creative misinterpretation.  The "modeling
of the world" of Scheme is pretty much on par with all dynamically typed
languages: it would be reasonably doable to create a common bytecode
machine for several of them (there are various interpreters written in
GUILE already, like for Lua, JavaScript and others).

The difference is not one of "modeling" but rather one of accessing the
world.  Scheme does not decorate its code.  When you have items in a
row, they are separated with whitespace.  In C, you separate summands
with "+", function parameters with ",", sequentially executed
expressions with "," (but you can't use them as function parameters
without additional parens), statements with ";", alternative execution
paths with "else", case label and statements with ":", alternative
clauses with shortcircuit evaluation with "||" and so forth and so on.

This sort of interpunction use is something humans can deal well with,
in natural language and in semigraphical languages like math, absorbing
the additional information on the fly.

But in all cases, we are talking about items in a row.

Leaving off the decoration does not change the model of the world.  It
just refrains from prestructuring it into patterns that are not actually
present in the world.

> But (depending on the task) it is equally valid to think of a
> programming language as a medium that should be a natural way for the
> programmer to express what the computer is supposed to do. Breaking
> down these tasks to executable steps is then the duty of the
> interpreter/compiler.

But in the end, it is the computer which needs to do the job.  And in
the case of LilyPond, we are talking about an extension language: we are
expressing different aspects of our desires in two different languages,
and not having competing ways to structure the world is an advantage for
integrating both.

> Of course such a language is more complex, and of course it is less
> efficient because the machine will do that in a more schematic way
> than a human could (but not necessarily does).

Compilers don't take a lot of time compared to writing code: letting
computers do as much as possible makes sense.  Writing programs in
Scheme does not really make things significantly easier for the
computer.  While bringing up a simple LISP or FORTH interpreter from
scratch on a weekend is a nice challenge for a programmer while writing
a C++ compiler takes man-years, the actual task of running the compiler
is reasonably fast.

But in the case of LilyPond, the task is not finished with having some
language.  We still need to tie the result into LilyPond.  And we don't
have man-years to spend on it.

> Compared to writing Scheme writing Python almost feels like writing
> plain English.

   I was a Flower of the mountain yes when I put the rose in my hair
   like the Andalusian girls used or shall I wear a red yes and how he
   kissed me under the Moorish wall and I thought well as well him as
   another and then I asked him with my eyes to ask again yes and then
   he asked me would I yes to say yes my mountain flower and first I put
   my arms around him yes and drew him down to me so he could feel my
   breasts all perfume yes and his heart was going like mad and yes I
   said yes I will Yes.

That actually predates Scheme.

> Scheme is simple because it's nearly atomic.  Understanding Scheme is
> difficult because one has to build the world from these atoms oneself.

But others use the same atoms, so one discovers patterns after all.

What I am less than enthused about is that with regard to mediocre
coding styles, the LilyPond code base is not really educational.  The
.ly code is least annoying in that regard, the Scheme code is of quite
mixed quality, the C++ stinks.  Some of that is because the world
according to LilyPond and the world according to C++ have not been
matched with the tools of C++, and it does not help that the LilyPond
concepts are mapped closer to bad C++ than to Scheme.  "Bad C++" because
C macros have been used to substitute for matching the type and template
system of C++ to the tasks to be solved in LilyPond.

> And you have to think like the calculator you're instructing.

Not at all.  You have to think along the lines of the task, not along
the lines of the calculator.

For example, for computers many tasks are solved iteratively.  In
contrast, a lot of Scheme code works by writing things in terms of
recursion, and that tends to map reasonably well to many problem spaces.

With iterative approaches, you tend to break a problem down into steps
that solve parts of the problem.

With recursive approaches, you tend to map a problem into
computationally smaller problems of the same conceptual class, which
does not really seem to achieve anything
<URL:http://en.wikipedia.org/wiki/Turtles_all_the_way_down>.

> This is much further from the way humans think than other languages.
> IMHO that's the reason why so many people stand puzzled before
> Scheme. You have to learn two interdependent things at once.

I'd argue that the machine language of most modern processors is closer
to the C language than to Scheme.

Scheme is not really closer to the computer architecture than C or C++
are.  It is really more that it structures the "computing space" in a
different manner which ends up to be much more hands-on on the
underlying interpreter and computing model than with most other language
families.

If you want to get raw no-nonsense access to both interpreter and
underlying computer, FORTH is more hands-on on today's computers.  But
the abstractions on which Scheme is built, both syntactically as well as
conceptually, are less low-level.  As one result, FORTH systems (like C)
will tend to crash a lot more fatally than Scheme systems.

At one point of time, there were specific computer architectures for
working with LISP-like code (the Symbolics machines running the original
Emacs, for example).

But nowadays, Scheme is not really a way to get chummy with the
processor.  It _is_ a way to get chummy with the interpreter.

> That said: From David's first longer explanation I can see what it is
> good for, and why it is a natural choice for integrating with
> LilyPond.

Well, there were certainly other valid choices (and nowadays there are
more).  But LilyPond and GUILE are by now integrated quite tightly, and
some of the expectations regarding the possibilities for their
interaction are not easily replaced with other approaches.

-- 
David Kastrup