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).
I'm making what I believe to be a better one.
The elisp manual is not bad. Between shortdocs and that, using the scratch buffer or ielm, it's pretty fast to get going. I would save an elisp buffer to a file at first. Scratch is ephemeral by default. Like anything, reinforcement and consistent effort go farther than having the perfect approach.
It's pretty tiny compared to a lot of languages considering that most of what you use it for is working with Emacs, which has a small number of intrinsic types like buffers, windows, frames, text properties etc.
Compared to being the kind of person who reads use-package like JSON and treats it like a declaration language, you will be light years ahead at configuration if you just know lists, quoting, alists, plists, and writing functions. Users who don't go at least that far will be constantly shooting themselves in the foot and spending much more time with minor, novice level bugs that are completely obvious.
Elisp manual. Helpful. Completions for variables, functions. Apropos.
I'm starting work on a video series called for Speedrunning Emacs in the "I want to hack everything in Elisp" sense. Emacs is a programmable interface to a computer, so my interpretation is that using Emacs and using Elisp are inseparable.
https://www.youtube.com/watch?v=QU30EZiHNQw
It's super new, so I'm recording right now and mainly covering things incidental to setting up casting for now and going over packages I've already published. Excited to get dug out of that hole and cover some of the things I want to.
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.
The point is I like philosophy of Unix using like tmux + nvim + mutt .
Emacs is at least on the surface orthogonal to the Unix philosophy. It's a programmable interface to a computer. Instead of remixing a bunch of fixed tools using bash pipes and arguments, you do most of your lightweight automation and integrations in Emacs Lisp.
They're out of date, but it was a decent opinion before eat.
You want your primary interface to a computer to be a programmable programming environment, which provides extremely proficient interfaces for programming itself, as a force multiplier for automating things that require a varied composition of off-the-shelf and bootstrap-level integrations.
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.