Have them show their IDE's scripting environment and how they can quickly prototype an automation for something annoying without even going the distance to write a full plugin and then bind that automation to a key.
Then open org or something and show how you can write a version of Lispy for org outlines based on some predicates like org-at-heading-p.
Emacs is a programmable interface to a computer. While it is frequently used to program itself to program other things, it is a foundational bootstrap tool.
IDE's seek to present a set of features that fills that domain of work. You hit a ceiling in that world. With Emacs, you continue molding it to things you get value out of years and decades later, after that IDE went away when its most popular language or framework went into decline.
In the upcoming landscape of AI's with more well-defined type interfaces and symbolic representations, tools like Emacs will be at the forefront of composing these tools into the long tail of cottage industries of what will amount to a revolution in IP, programming, and human-computer interfaces.
Xenodium's Github repo for the dynamic module needs more stars and links so more people find it
I'll be collecting dynamic modules while deciding how to make a template for elisp repo kit (Rust).
Is this about Elisp threading or Emacs using threads to implement rendering and executing Elisp etc?
General is a package that really illuminates the tension that occurs when the user wants to integrate two packages. :after is okay for a quick solution, but for packages like general, you would end up with one ensured package implicitly depending on everything.
It's much less bad that you end up loading everything and much worse that the use-package declaration feels anything but modular or independent, instead incorporating symbols from all over Emacs and implicitly depending on other use-package hunks.
What is still a much deeper problem in my opinion is the lack of being able to superimpose and compose configuration. This is the reason why adopting random hunks of use-package declarations is not safe and why almost no two users can easily re-use large units of configuration.
Long-term, lisp dynamic module -> NDK and you need some manifest permissions in the APK
Years ago I had some experience using a dynamic language with the JNI to introspect the Java interfaces and call them. Fun times.
I can probably scaffold up some work, but only if people show me that they want it.