• Does Logo need a refresh?

    From Michael Daumling@21:1/5 to All on Wed Feb 3 09:05:59 2021
    Let me introduce myself. I am the author of Terrapin Logo (since 1993, actually). Terrapin Logo is still used to teach young students all over the world, and I continue to see feedback and provide support.

    I have all kinds of feedback at Terrapin, mostly from teachers who want to teach Logo, and I think that Logo shows its age. What I would like to do is to define and create an updated version of the Logo programming language which should be more children-
    friendly in terms of syntax, and easier to compile.

    Here are a few random thoughts:

    - Get away with the colon notation for variables. Kids and teachers struggle a lot with this feature.
    - Simpler strings (with two single or double quotes) to make it more compatible with other languages and to allow multiline strrings and embedded variables in a {NAME} syntax.
    - Variables are either local or global, but no scope chain across the call stack (what you would call lexically scoped). Accidentally accessing a variable that a grand-grandparent caller introduced is not helpful.
    - Remove DEFINE and TEXT; PRINOUT could print a procedure, but it may look differently due to optimizations - makes it easier to compile Logo.
    - A centralized definition of a standard library.

    I’d set up a Github repo, and start producing documentation that we could work on together. When the dust settles, we could add a reference implementation in Javascript (Terrapin Logo is written in Javascript, and it is pretty darn fast, able to drive
    up to 1000 turtles).

    Thoughts and comments are most welcome.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bruce Axtens@21:1/5 to Michael Daumling on Mon Feb 8 15:12:57 2021
    On 4/02/2021 1:05 am, Michael Daumling wrote:
    Let me introduce myself. I am the author of Terrapin Logo (since 1993, actually). Terrapin Logo is still used to teach young students all over the world, and I continue to see feedback and provide support.

    I am a lurker on this and a number of other lists. I am also a librarian
    for <https://hopl.info>. I haven't used Logo for a number of years
    though did collaborate briefly with the makers of Lhogho.

    - Get away with the colon notation for variables. Kids and teachers struggle a lot with this feature.

    It is a notational peculiarity of Logo. It reminds me of the "."
    notation of BLISS. You probably still need a notation to differentiate
    between the variable and what it contains. Forth uses "@" and other
    scripting languages like Perl use "$". Certainly, many languages allow
    context to define behaviour, e.g. C family. Depends on the pedagogy, I
    suppose.

    - Simpler strings (with two single or double quotes) to make it more compatible with other languages and to allow multiline strrings and embedded variables in a {NAME} syntax.

    Yes.

    - Variables are either local or global, but no scope chain across the call stack (what you would call lexically scoped). Accidentally accessing a variable that a grand-grandparent caller introduced is not helpful.

    Yes to that too. I wasn't aware that that could happen.

    - Remove DEFINE and TEXT; PRINOUT could print a procedure, but it may look differently due to optimizations - makes it easier to compile Logo.

    No comment (can't show my ignorance too much now, can I?)

    - A centralized definition of a standard library.

    Definitely.

    I’d set up a Github repo, and start producing documentation that we could work on together. When the dust settles, we could add a reference implementation in Javascript (Terrapin Logo is written in Javascript, and it is pretty darn fast, able to
    drive up to 1000 turtles).

    I doubt I'd be much help with that. But I'm open to participating at
    some level or other.

    One hopes that the list comprehension and other LISP-like powers of Logo
    are not going to be compromised by a rewrite. That is, this better not
    be a dumbing down of Logo to reach a wider audience and leave them as
    dumb as where they started. A revised Logo would want to be a language sufficient to be a track on <https://exercism.io> and be a mind-strecher.

    Just my twenty cents.

    Bruce/bugmagnet

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bruce Axtens@21:1/5 to All on Mon Feb 8 15:23:38 2021
    P.S. My browser is complaining that <https://www.terrapinlogo.com/>
    isn't secure.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Daumling@21:1/5 to All on Fri Feb 12 03:32:44 2021
    Bruce, thank you for your input! At least someone in this group who is interested in the development of Logo.

    I have set up a Github repo at https://github.com/daumling/logo. Currently, there is one file specs/discussion.md, where I explain my ideas. The repo has a "Discussions" tab, where you can add your input and start discussions. Please also feel free to
    clone the repo and add your own text. Let me know, then I can add you as contributors so you don't have to generate pull requests to have your text integrated.

    I hope that this will be a good starting point to revive the Logo language. Please take some time to review my ideas and leave your comments!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Qitam Nova@21:1/5 to daum...@gmail.com on Sat Feb 13 02:41:58 2021
    Hi Mike,

    I'm thinking for quite some time about a refresh of Logo. It was my programming language back in the 80 and always felt that there are still dark corners that need to be lightened. Over the last years I saw all implementations ageing and vanishing. So I
    sat down and made a list what would be important for me:

    - UCBLogo (BerkeleyLogo) primitive set (for it is the most complete I know)
    - App to be used offline
    - Open Source, well documented, programmed in a language available on all platforms
    - Reference implementation for all common platforms (Linux, macOS, Windows, ...)
    - Especially the editor window has to be up to modern standards (prim highlighting)
    - Not sure if a multi-window or one window with fixed regions environment serves best
    - Beside a reference book there should be a book with ideas for enthusiasts
    - There also has to be a book for students and accompanying a teachers book

    You see that my approach comes from another angle which adds to yours. Still these are just my ideas open for discussion.

    Have a great day

    Qitam


    On Wednesday, 3 February 2021 at 18:06:00 UTC+1, daum...@gmail.com wrote:

    Let me introduce myself. I am the author of Terrapin Logo (since 1993, actually). Terrapin Logo is still used to teach young students all over the world, and I continue to see feedback and provide support.

    I have all kinds of feedback at Terrapin, mostly from teachers who want to teach Logo, and I think that Logo shows its age. What I would like to do is to define and create an updated version of the Logo programming language which should be more
    children-friendly in terms of syntax, and easier to compile.

    Here are a few random thoughts:

    - Get away with the colon notation for variables. Kids and teachers struggle a lot with this feature.
    - Simpler strings (with two single or double quotes) to make it more compatible with other languages and to allow multiline strrings and embedded variables in a {NAME} syntax.
    - Variables are either local or global, but no scope chain across the call stack (what you would call lexically scoped). Accidentally accessing a variable that a grand-grandparent caller introduced is not helpful.
    - Remove DEFINE and TEXT; PRINOUT could print a procedure, but it may look differently due to optimizations - makes it easier to compile Logo.
    - A centralized definition of a standard library.

    I’d set up a Github repo, and start producing documentation that we could work on together. When the dust settles, we could add a reference implementation in Javascript (Terrapin Logo is written in Javascript, and it is pretty darn fast, able to
    drive up to 1000 turtles).

    Thoughts and comments are most welcome.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Daumling@21:1/5 to All on Sat Feb 13 06:54:04 2021
    Hi Qitam,

    Thank you for your ideas. Here is my take:

    - UCBLogo: I think that this is a valid starting point. Daniel Ajoy pointed out that it may not be a good idea to break backwards compatibility, and I have posted a few ideas about this in the discussion forum at https://github.com/daumling/logo/
    discussions/ (sorry to have set up yet another discussion thread - I’ll try to keep these threads in sync). In short, the dilemma of breaking syntax changes could be solved by metadata embedded at the start of a Logo file - just another idea.

    - Implementation: I have written the latest version of Terrapin Logo in Javascript to make it browser based. This makes it run on almost every device including iPads and (important for schools) Chromebooks. There are severe limitations when you want to
    load and save data thanks to the sandboxing nature of browsers, but there is an app framework called Electron, which bundles node.js together with a Chromium browser, creating a traditional binary executable; with that app, Terrapin Logo also runs
    offline with full disk access. I think that this approach would also be helpful for the reference implementation, expecially because it enables on-the-fly updates.

    - Editor: This is not a big issue actually. In the JS world, we have, for example, CodeMirror that does a splendid job at highlighting together with a simple Logo parser.

    - Windows: I believe that a combo would be ideal. Terrapin Logo offers a windowed system, which most people do not use. Some use it to pre-arrange listener, graphics, editor etc, but not many. I guess that a traditional listener/graphics split view
    combined with an overlaying editor window would be ideal. In a browser-based environment, this could even be separate browser tabs talking to each other.

    - Books: Agreed. Terrapin offers free supporting materials for licensed users, which people often use. Buth that would be another topic.

    Regards, Michael

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bruce Axtens@21:1/5 to Michael Daumling on Mon Feb 15 10:47:17 2021
    On 4/02/2021 1:05 am, Michael Daumling wrote:

    Thoughts and comments are most welcome.

    You may want to get in touch with Pavel Boytchev who was developing
    Lhogho
    <https://pavel.it.fmi.uni-sofia.bg/projects/lhogho/lhogho.php?lang=en>.
    He appears to have moved on to other things but he did try to build a
    Logo compiler so getting his input may be helpful.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From yewsiedu@gmail.com@21:1/5 to daum. on Fri Jun 4 11:50:22 2021
    On Wednesday, February 3, 2021 at 9:06:00 AM UTC-8, daum. wrote:
    Let me introduce myself. I am the author of Terrapin Logo (since 1993, actually). Terrapin Logo is still used to teach young students all over the world, and I continue to see feedback and provide support.


    Nice to meet you! I co-develop turtleSpaces Logo

    I have all kinds of feedback at Terrapin, mostly from teachers who want to teach Logo, and I think that Logo shows its age. What I would like to do is to define and create an updated version of the Logo programming language which should be more
    children-friendly in terms of syntax, and easier to compile.

    Here are a few random thoughts:

    - Get away with the colon notation for variables. Kids and teachers struggle a lot with this feature.

    We considered this, but the only clean way to do that was to make each variable effectively a function, which would mean all primitive names would be effectively restricted...

    - Simpler strings (with two single or double quotes) to make it more compatible with other languages and to allow multiline strrings and embedded variables in a {NAME} syntax.

    We use pipes to denote a string or 'long word', eg make "string |The Quick Brown Fox Jumps Over The Lazy Dog...|

    - Variables are either local or global, but no scope chain across the call stack (what you would call lexically scoped). Accidentally accessing a variable that a grand-grandparent caller introduced is not helpful.

    We also have private vars, that are tied to procedures

    - Remove DEFINE and TEXT; PRINOUT could print a procedure, but it may look differently due to optimizations - makes it easier to compile Logo.

    Compile Logo...? As in the interpreter? Or compiling Logo procedures...?

    Cheers,
    Melody

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)