On 1/12/23 6:11, Craig Johnson wrote:

Thanks. It looks interesting indeed. So much that, what was a short
answer became a long reflection on minimal environments that provide
support for diverse learners (beyond developers or computer scientists)
via data storytelling and computational notebook. Here it comes.

======

I have been using Nim integrated with Pharo/GT when I need go to the
console, performance optimizations  or use a library/functionality not
yet in Pharo, and I would like a better shell and external programs
story in Pharo/GT (I know the second is build on the first, despite
having different agendas, but that's the combination I use and for me,
GT's power provides from being done in Pharo).

I would like something fast and self contained / portable that can be
run from the terminal, but it is also able bootstrap a more complex
environment and GUI as needs require it, as I'm interested in data
storytelling for diverse learners (mainly non-developers) and
computational notebooks, that run in restricted/bureaucratic
institutional environments with low/restricted/intermittent connectivity
(for example university labs).

I will compare what is available AFAIK in the Pharo ecosystem, with what
I have found recently Pluto.jl[1][1a] (and others), which brings this
kind of bootstrappable computational notebook experience, thinking in
how Pharoers, could benefit from a bootstrapable experience from shell
at the end.

1. Pluto can run from a portable program that doesn't require admin
   permission to install: just uncompress and run (like Pharo).
   2. Pluto provides an interactive programming Julia shell where you can
   load more packages and launch the WUI (Web UI). In Pharo's case, there
   are Coral[2] and Scale[2a], with the second pretty close to a shell +
   loadable graphical interface, but both seem unmaintained.
   3. Pluto provides an interactive notebook interface (like GT), but it is
   reactive, non-blocking and stores a computational graph of related
   variables/expressions.
2. Pluto stores its notebooks as human/diff friendly plain text and, in
   fact, they're just Julia scripts[3] (like Clojure's Clerk[3a][3b]). As I
   told in ESUG 2023, we have been porting some lessons from Grafoscopio to
   Lepiter about having human/diff friendly formats to store computational
   notebooks using Markdeep[4], which is similar to the approach taken by
   Elixir's LiveBook[3c]. See for example this documents, and their source
   code, on building modular parsers with PetitParser[4a] (ported from the
   chapter in Pharo books) or on migrating from WordPress to
   TiddlyWiki[4b]. Such formats are in contrast with long nested diff/human
   unfriendly JSON documents of Jupyter or Lepiter, and pretty readable
   outside Pluto, Clerk, LiveBook or Lepiter, just with a plain text editor
   or a web browser (in Markdeep's case).

So, how could we to have a pretty minimal Smalltalk/Pharo powered shell
language/mini-image that can execute .st scripts (like with Coral and
Scale) and launch a notebook, being it native (like Lepiter, with its
wonderful one single rendering tree, but more minimalist and with async
snippets/code execution by default) or web UI (still to be created,
maybe with HTMX)? My approach, for the moment, is to develop MiniDocs[4]
to provide support for minimalist documentation tools (starting with
Markdeep and some Pandoc support) and some notebook web rendering (via
Zinc) and export. Pandoc's Markdown export with metadata to make
notebooks collaborative (as we are doing with Markdeep) is yet to be
done (but soon in the radar). Also Brea[5] will be (slowly) used/revied
to explore building web sites/interfaces (now that HTMX is available to
avoid JS)

Still, the question of how minimal Pharo or GT can be made to run from
shell or integrate with external software ecosystems is an open question
for me. Seems that the best approach would be to revive Scale (or Coral)
and to see which minimal elements of a computational notebook experience
can be bootstrapped from there and which lessons from more (b)loaded
environments can we port to such minimal systems, while still interop
with the wider Pharo ecosystem or even with other languages (like Nim or
Julia). Maybe PharoIoT or other minimalist images could be a starting
point also (but pharoiot.org seems also unmaintained).

I'll keep the community posted on the experiments sketched above.

Cheers, happy new year and thanks for the Pharo community, ecosystem and
all the hard work and good vibe behind.

Offray

== Links

[1] https://plutojl.org/
[1a] https://www.youtube.com/watch?v=Rg3r3gG4nQo
[2] https://speakerdeck.com/cdlm/coral-esug-2011?slide=2
[2a] https://github.com/guillep/Scale
[3] https://featured.plutojl.org/
[3a] https://clerk.vision/
[3b] https://book.clerk.vision/
[3c] https://livebook.dev/
[4] https://code.sustrato.red/Offray/MiniDocs/
[4a]
http://mutabit.com/repos.fossil/mutabit/doc/trunk/wiki/en/petitparser-building-modular-parsers--ac8zq.md.html
[4b]
https://mutabit.com/repos.fossil/gig/doc/trunk/wiki/en/gig-portable-wiki--1apbv.md.html
[5] https://code.sustrato.red/Offray/Brea
[5a] https://mutabit.com/repos.fossil/indieweb/
[5b] https://mutabit.com/repos.fossil/brea/

Does anyone else remember F-Script?  A "Smalltalk-inspired scripting
language" for MacOS X,
providing full interoperation with Objective C and the whole Cocoa
frameworks system.
The last update was 5 years ago, which is a pity, because

1. It was so well integrated with MacOS X (as it was then) that it
   needs rebuilding wih each macOS release.
2. It was so well integrated with MacOS X that it was restricted to
   MacOS X; there wasn't anything to port to Windows or Unix.
3. It was Smalltalk - inspired but not Smalltalk, so there was no
   flow of ideas or code between Smalltalk and F-Script.
   For example, there never was an SUnit for F-Script.

Does anyone else remember Susie?  (Scripting using a Smalltalk
Interpreter engine.)  I've been meaning to fix the problem with a
64-bit build but wondering who to tell.  It seems as if reviving Susie
or GST ought to pay off more sooner than starting from scratch.

If you want a "class-less" language inspired by Smalltalk with
minimalist syntax, you really MUST look at Self.
I used to use XLisp/Stat a lot, and while I loved it, I can't say that
not having classes struck me as a strength.
Curly braces trace back to BCPL -- which I once set out to write a
compiler for.  They were and are a bad idea.
If you want a scripting language inspired by JavaScript, with braces
and sans classes,
may I suggest JavaScript?  It satisfies 8 out of your criteria
out-of-the-box, and node.js with a vast library of stuff to script
with, including testing frameworks, already exists.  I'm not sure if
it satisfies criterion 6 or not, but then I'm not sure what criterion
6 means or why you would care.

There are programming languages I dislike as languages but use for
the sake of the libraries they give me access to,
S, for example, ticks quite a few of your boxes.  As a language, it's
pretty awful.  (In large part because it ticks those boxes.)
BUT the packages!  Oh gosh, the packages !
All the work I don't have to do!  All the work I COULDN'T have done!

So, one approach is to build your new teenage mutant ninja scripting
language on top of something like node.js.  Go nuts with your syntax,
but make the data structures fully JavaScript-compatible so that you
can use existing npm packages from your language.

I wish GNU Smalltalk were still maintained.  One day I must try to
figure out why printing floats crashes.

On Sat, 2 Dec 2023 at 00:11, Craig Johnson craig@hivemind.net wrote: