Urs Liska <[email protected]> writes: > On 06/12/2013 02:50 PM, Tim Slattery wrote: >> Thomas Morley <[email protected]> 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 _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
