Q: No planned Algol 68 ecosystem pitfall, I hope?

[Paul Wolneykien]

  Hi there!

  First of all, I want to say I'm very, very impressed to see the
consolidated effort to bring us the renewed version of the old
masterpiece, the Algol 68 language! Thank you all for doing this.

  However, making a programming language better means to attract
the developers. So, despite currently the amount of modern Algol 68
code is quite limited AFAIK, if things will go okay, the codebase
will grow. What fruit that growth can give? That depends at least
partly on applied "agriculture methods". Despite some can say
it's too early to plan anything at the moment, I think the earlier
the better.

  The main thing I personally hate all modern languages for
(such as Rust, Go, Node.js, even the modern Java) is their trend to
completely isolate the development of one program from all other
software. Their building and runtime systems designed in such a way
that makes each program a bundle of libraries it uses. What's wrong
there? The bundling approach serves well for commercial proprietary
software, but is a real disaster for Free Software as it overinflates
the project sources and makes you forget to care about compatibility
issues.

  Personally, I believe that separate compilation with dynamic linking
plays a very important role in building a Free operating system (and
Free Software in general) in cooperative manner. Separate compilation
and dynamic linking help to keep the codebase smaller. They also don't
let you forget about the fact that a particular version of your library
is shared by many programs and so the updates should be planned and
publicly announced. And as I have learned so far from the mailing list
archive and the docs, the separate compilation of modules is a
desired goal and a currently working draft. And that is great!

  However, what is your plan for module management, if any? Would it be
as simple, as /usr/lib/libmya68mod.so, i. e. all modules are placed
system-wide without any tricks? Or something more complex?
In particular, the docs mention the "-fmodules-map=" option that is to
be used in some scenarios I don't fully understand. Is it just a
development / debugging tool that makes it possible to compile and link
a program in a non-standard way (good)? Or is it rather a piece of a
planned everyday practice for those who will use ga68?

  Well, looking at ga68 as a part of the new GCC that also has
Autoconf support, I can hope that its module system would be
Free-Software-friendly, encouraging people to cooperate their efforts
in order to build something bigger and better than just another
"cool app".

    Sincerely,

      Paul.