OK, here's a pretty niche blast from the past: the boo programming language. It ran on the CLR (.NET) and had syntax similar to python. I recall using it back around 2006 - 2008 because it offered scripting features for .NET on Windows.

https://boo-language.github.io/ "A scarily powerful language for .Net". I didn't use it for too long before switching to Iron Python.

I remember reading about the Boo language and IronPython some years ago. Do you still use IronPython?

I do not.

These days I would reach for a shell script for general scripting, filling in the gaps with maybe a C# console app or something in Common Lisp if I want/need some interactivity.

Something that happens pretty frequently is I'll take information I've written into an emacs org doc and run it through a CL function, whose output could be an org mode table which I can from there export to a different document format if necessary.

I would say "it establishes a protocol to support recognizing and propagating changes the way you would expect throughout an inheritance hierarchy if something related to a meta object in that hierarchy changes, even while working interactively in the REPL".

vim has 2 implementations of slime.

Lem is a new editor written in Common Lisp that has slime "built-in".

> vim has 2 implementations of slime.

Which are both buggy and one of them is abandoned.

> Lem is a new editor written in Common Lisp that has slime "built-in".

"Lem" is not (neo)vim, has Emacs RSI bindings and even if by some chance it included some "vi mode", it would simply be an emulation, not an actual vi editor. Same issue with Emacs using "evil mode".

> even if by some chance it included some "vi mode", it would simply be an emulation, not an actual vi editor

Lem supports vim key bindings, according to its README.

btw, I don't have any issues with emacs keybindings, but I chuckled at the "Emacs RSI bindings" :)

In fact, I think vim keybindings are superior for editing - you can't beat hitting "." to repeat an action - but after using emacs for ~5 years I find myself in it a lot more than I expected when I started using it. The whole thing with key bindings is that for whichever one(s) you use your muscle memory catches up.

> any system that relies on information that was typed into a REPL three-months ago and is now only stored in the binary state of that REPL and nowhere else

Implemenations like SBCL can produce executables. Source code is stored in files and can be versioned.

> The only person trying to fix this [is] Fukamachi

There are other ways to get dependencies, such as ultra lisp https://ultralisp.org/ and OCICL https://github.com/ocicl/ocicl.

Yes, of course, that's why I brought up Fukamachi's work to point out that things can be better. It is possible to forego the mechanisms of interactive-development that intersect with image-based development, but that requires lispers to change how they've done things for generations. Neither the ecosystem or culture is aligned to it.

Ultralisp + Roswell + qlot produces something resembling a modern development workflow, but it is swimming upstream. ASDF is totally inadequate as a build system, it makes CMake appear terse and elegant by comparison (why on God's green earth is the present working directory not searched for the package I'm trying to build, like every other build system to ever exist?). Documentation and tutorials assume you're pulling things down with quicklisp and evaluating in the REPL. /r/Common_Lisp posters wonder why you would even want to use dependencies at all when you could just use [incomprehensible, brittle, unhygienic macro].

It has become possible, in the last two years or so, to produce sane common lisp workflows that operate somewhat like other modern environments. I very, very rarely encounter that usage in the wild. I would like nothing more than for the Common Lisp infrastructure to produce environments and workflows as obvious, intuitive, and correct as what every undergrad using Python in VSCode has today. I do not think the broader language ecosystem is there yet.

> why on God's green earth is the present working directory not searched for the package I'm trying to build, like every other build system to ever exist?

What if you want to share packages (aka CL systems) between different CL systems / applications?

Do it the same way every language environment not named Common Lisp does?

All in the service of interactivity, a key feature of CL.

> there are languages with a relatively small number of distinct syllables, like Japanese

Japanese has around 50 syllabic symbols, depending on how you count - include both sets of kana? include more archaic kana? etc

What would be a more typical number of syllabic symbols? I tried googling it to get an idea, but couldn't find much useful information. I guess Arabic has 28?

I think they meant syllables specifically, not syllabic symbols. Meanings syllabic symbols might get confused for an alphabet if the language has a sufficiently small set of syllables. See https://linguistics.stackexchange.com/a/36909

Yeah, was aware of that possibility; I guess I should have made a point about the disctinction between symbols vs "possible sound combinations" (my words). And even "possible sound combinations" can be further limited to "actually used sound combinations" as mentioned in the answer on that SO link.

So, in terms of "possible sound combinations" I think Japanese would likely be on the lower side given that the number of sounds are also pretty low. Alright, thank you for that reply; the point in the original post I replied to makes more sense to me now.

Not sure it counts as "multicursors" but overwriting a rectangle using C-x r t (string-rectangle) is pretty handy in emacs.

With built-in emacs functionality you can do:

1. Place the cursor on the left parenthesis of the form (same as you wrote)

2. C-M-Space to select the form.

3. M-( to surrond with parenthesis.

4. type "if flag" (same as you wrote for #3)

One extra step, but no need for a plugin.

Also, I added a simple "insert-quotes" that I think I mostly copy-pasted from the built-in "insert-parentheses":

  (defun insert-quotes (&optional arg)
    (interactive "P")
    (insert-pair arg ?\" ?\"))

So I can replace my #3 above to wrap something with quotes instead of parentheses.

> So I can replace my #3 above to wrap something with quotes instead of parentheses.

That's M-" .

Interesting, I did not know that! But, the one I wrote mimics how insert-parentheses works, so I will probably stick to my version.

> Creating a language designed for being manipulated this way

AFAIK, Lisp wasn't created for structural editing, it was just a "happy accident" that it lends itself so well to the technique. Even without the paredit and parinfer plugins, emacs already has good support for structural editing built-in. It reminds me of VIM text objects, but geared directly for Lisp syntax, ie. symbolic expressions.

> a couple of famous Haskell folks.

Who?