Ask HN: Why aren't text editors using Swift as an extension language?
This is especially puzzling given that Swift supports bidirectional C++ interoperability.
Also note that text editors really thrive on specialized string representations
https://cdacamar.github.io/data%20structures/algorithms/benc...
which is one reason why Stallman went with developing an Emacs Lisp that was specialized to implement a text editor in as opposed to writing a text editor in Common Lisp, Scheme or something like that.
no
https://www.swift.org/install/linux/#platforms
> Also note that text editors really thrive on specialized string representations
No, it needs specialized editor data structures.
The first Emacs was originally written in 1976 by Guy L Steele and David Moon on top of TECO, an early text editor with a cryptic macro language. Richard Stallman did most on the early work on it.
The second Emacs was written for the then new MIT Lisp Machine in Lisp, in 1978 by Daniel Weinreb and Mike McMahon. The Emacs was called EINE.
The third Emacs was Multics Emacs, which was written in Maclisp, in 1978 by Bernard Greenberg.
One can implement editor data structures in Lisp, as was shown already way back then.
Gosling Emacs was written in C with Mocklisp, 1981. Richard Stallman took it and rewrote it into GNU Emacs.
GNU Emacs is implemented on an Emacs Lisp engine written in C, with various low-level stuff implemented in C.
The main reasons to use C for low-level stuff:
C is already a low-level language, which makes integration with various operating systems simpler.
C can be compiled to native code and will generate fast executable code.
Emacs Lisp OTOH was implemented as an Lisp interpreter and a byte code engine (byte code interpreter in C and byte code compiler in Lisp). Writing portable code is easy, but without native code it is not that fast, when the code is actually written in Lisp. Slower Lisp code calling faster C code for the performance critical sections then usually works. Also the compact byte code made the implementations slightly smaller, compared to native code.
Other Lisp implementations (like Lisp Machine Lisp and Maclisp, both from the 70s) already had faster implementations. The Maclisp compiler was producing native code.
The other reason why Stallman implemented Emacs Lisp: he wanted a simpler Lisp, because GNU Emacs was supposed to be configured/extended by people who are not hardcore Lisp experts.
Why would one want to use a non-lisp language within emacs?
Zed[4] is fairly new.
Swift as wrapper/unix io cli pipe feed around sed for interactive editing or pre/post process input/output to sed without the need to use/understand c++ just requires an understanding of unix cli, swift and just enough sed.
Pretty easiy to add swift as an extension language to bashed[3].
Off the cuff guess: insufficient demand within main editor project for swift as language extension.
Demand/use for supported extension languages within framework/ IDE / office suite (open office) does require significant/continuous time/effort to be supported within the main editor project.
But why an extension language for text editor instead of using editor plugins / text transform dls? (where can insert call to swift program(s) to do transform work) aka non-swift lanuage examples: vim live server[0], likec4[1]. can use swift as pre/post process wrapper to neovim text editor[2]
Insufficent time/space for additional editor comments on swift support.
-----
[0] vim live server : https://github.com/wolandark/vim-live-server Note: other programs for non-html bindings -- latex, postscript, rich text format, etc. Does this qualify as a gREPL or GREPL? (where g/G is short for GUI)
[1] : likec4 : https://github.com/likec4/likec4?tab=readme-ov-file
[2] : swift gui : https://github.com/stackotter/swift-cross-ui
[3] : bashed : https://github.com/justinyaodu/bashed
[4] : zed : https://zed.dev/
Were I to add a scripting language into the editor I maintain, there are half a dozen candidates which quickly come to mind; if none proved suitable, I would probably end up designing a new language, tailored to my purpose, before it would occur to me to use some heavyweight, VM-driven beast like Swift (or C# or Java).
"REPL & Debugger: The LLDB debugger provides a rich REPL as well as the debugging environment for the Swift Language."
Yeah, OK. So we're gonna have to bolt the entire LLDB debugger into the editor, which will undoubtedly drag in the entire LLVM ecosystem, because that banana is held by a gorilla which is swinging from a tree, which requires the entire jungle.
This simply doesn't smell like an extension language.
[0] : http://www.swift.org/documentation/standard-library/
[1] : http://medium.com/fink-oslo/scripting-with-swift-c8b929d1a7a...