#67 Our FMSLogo Developments for Education and Hobbyists

[Manfred Zindel]

I would like to address the question of the future of FMSLogo. Our working group, pbreport, in Borchen near Paderborn, Germany, has been collaborating with schools for over five years to extend FMSLogo for use by educational institutions.

We sometimes, but not always, refer to the result as a framework. Its key features are a standalone extension to Commander, the development of which we began years ago with David Costanzo, several small libraries, and a deployment concept modeled on Docker, dependent on the Windows operating system. In February 2026, we plan to present our FMSLogo extension in Paderborn with a special project tailored for schools. This project will highlight, but not exclusively, FMSLogo's asynchronous capabilities.

A bound project book will be published to accompany the presentation—initially in German. Translations into Spanish and then English are also in progress.

Years ago, we conducted a comparative study to determine which programming language would be the most educationally friendly. We arrived at the LISP family and, within that, FMSLogo. Recently, we've been encouraged to favor the other branch of the LISP family, based on Scheme and its successors, especially Racket. We find Racket's versatility and extensibility excellent, particularly with its macro system—but we're more convinced by FMSLogo's overall syntax, especially its clarity and minimal use of brackets. We've successfully distributed our framework, which we call KISS.lgo, as containers on small USB drives—both within and outside the classroom, and even over the network with some limitations.

My question today is: What are the chances of FMSLogo experiencing significant extensions - portability to other platforms, especially Linux; a Docker image; fast and versatile animations; optional lexical scoping, and with it, closures and function factories, first-class functions, and other features I can't think of right now? And, of course, some form of access to machine learning libraries. The result would be ideal for schools and training institutions, but also for creative people and – please don't forget – older children and hobbyists...

[David Costanzo]

There are many ways to answer that questions.

First is that FMSLogo is GPL, so anyone can pick up the program, extend it, and redistribute it without my permission. That's how I picked up MSWLogo when George Mills's life circumstances made it so that he couldn't work on it anymore. However, no one who has shown interest in doing the same for FMSLogo, now that my life circumstances make it so that I can't work on it anymore. Several people have compiled their own FMSLogo, and one even spent three weeks extending it to support Unicode, but no one has been willing to collaborate as developers. So I think this is unlikely.

Second is that George Mills added a DLLCALL API, which is a powerful extension point. Anyone can add new FMSLogo procedures that call into native-compiled 32-bit DLLs. This is the most straight-forward to integrate FMSLogo with machine learning libraries. I think this has been done, but you have never shown interest in pursing this when I suggest it. So I'll say that's unlikely for the things you want.

Third is what is my future involvement is likely to be. It's possible that my life circumstances change and I find time and motivation to work on FMSLogo again. I'd give this a 25% chance of happening in five years.

If all your hopes are on me, I should clarify that, even if I am able to work on FMSLogo again, it doesn't mean I'd do all the things you want to see done. I'm somewhat interested in finishing the GNU/Linux port, which is about half done. I'm not interested in a docker image, but I am interested in an "fmslogo" package for Fedora or Ubuntu. I'm interested in removing some weird limits, like the 256 character limit on most callback instruction lists. I'm interested in fixing bug in the current language without extending it. I'm not interested in lexical scoping, but I am somewhat interested in making functions a first class citizen (with no plan on how that would be done).

As for other thing you mention, like "fast and versatile animations", I don't know what that means but I'm not interested. I am also very reluctant to do anything that breaks backward compatibility. This includes adding new primitives that could conflict with procedures in peoples programs. I am also very reluctant to add new features that are half-baked and would increase the maintenance cost. There are many aspects of FMSLogo that I think were done poorly and I don't want to add more.