9 ms·

Why can't the default be to write extensions in C/C++/Rust/zig/jai or any compiled language with which one can produce a .dll or.so? Why can't application deve

• majewsky 7y ago
  You need some sort of VimScript anyway because VimScript is the language for the command mode prompt.
  • coldtea 7y ago
    The language for the command mode prompt is "ed", no?
    • majewsky 7y ago
      VimScript is a descendent of ed, yes.
    • ncmncm 7y ago
      ex, really.
• kyberias 7y ago
  I think you know the answers to your questions. You just choose to ignore them.
• monsieurbanana 7y ago
  You can support .so extensions if you want, but it has to be secondary to a scripting language. Most extensions don't need raw performance, but an editor needs those extensions. An entry barrier as low as possible is needed to reach the critical mass of third-party extensions that turn an editor into something worthwhile.
  • leni536 7y ago
    Scripting layers could always be provided as .so extensions. The other way around is a bit more awkward.
• meain 7y ago
  There will still be a need for a non compiled language as we might have to change stuff on the fly.
  • NilsIRL 7y ago
    We could do that with a compiled language.
    • tzekid 7y ago
      Hmm ... how would you do that and keep the level of entry low? Julia would come close to that - script while prototyping and compile when done.
      • NilsIRL 7y ago
        I've never done it and have never heard of it being done but you could replace the code a bit like a JIT compiler does it.
      • PuercoPop 7y ago
        Several Common Lisp implementations do it, ej. SBCL. Why do you think interactivity is opposed to compilation? I'm not too familiar with Julia but afaik it compiles the forms entered in the REPL as well.
  • noch 7y ago
    Not true at all. See "Handmade Hero 021: Loading Game Code Dynamically" https://youtu.be/WMSBRk5WG58 https://youtu.be/WMSBRk5WG58
• zozbot234 7y ago
  Why provide a C API when you could just provide dbus endpoints to achieve the same scriptability via IPC?
  • NilsIRL 7y ago
    Latency
    • zozbot234 7y ago
      kdbus has pretty low latency, AIUI.
      • NilsIRL 7y ago
        I don't know what kdbus is but you're never going to have less latency than copying a value into your instruction register. And the fact you think a software bus is good enough is the reason so many things are so slow these days. It just depends on what your standard for latency is.
• NilsIRL 7y ago
  This would also work with scripting languages
• solidsnack9000 7y ago
  The scripting language is also the configuration. Does it make sense to have non-portable pre-compiled configuration, or configuration that requires a compiler invocation on startup?
• coldtea 7y ago
  >Why can't application developers abandon this strange habit of adding a slow "scripting" language? How is it strange? Your suggestion sounds even more bizarro. It's not like those developers don't know about shared libs and .so files. It's that: a) Programming in C/C++/Rust is more cumbersome (than in a dynamic/scripting/gc language), and throws off tons of potential extension developers. b) building extensions as .so even more so, adds different builds per OS/architecture, compilation steps, and tons of potential issues, both for setting up your extension building and for delivering it. c) encouraging extensions written as .so in different languages, means a smaller pool of common reusuable extension code (each extension will reinvent several wheels). Whereas people could easily develop libs in the editors extension language and share them for re-use in others' extensions. d) an issue in a C/C++/unsafe Rust etc extension will bring down the whole editor. In an embedded language that just calls API you can mitigate it easily. f) same for memory leaks and such. AAA game studios, which are hardcode C++ users with high performance / low latency needs, and have gone to using embedded scripting languages (with great success) and for some reason mere editor developers should abandon them and go pure C ABI?
  • noch 7y ago
    Tentative responses: a) I personally find using scripting languages more cumbersome in the medium to long term when I need to maintain, debug code, and optimise code. Every time I see a scripting/dynamic language, I'm turned off from extending the software that embeds it because debugability and performance will inevitably become a problem. b) I'm not convinced of the alleged "tons of potential issues" that arise from using a compiled language. The extension can be distributed as C code (or whatever compiled language the text editor's community has decided upon). Every platform has a C compiler. I'd argue that C is the most portable language available. Extensions that don't compile will simply fade away, as do extensions in any scripting language, when they don't work. (There is no need for a complex build process or autoconf or whatever other frustrating arcane/convoluted build systems we've somehow been convinced are necessary.) c) A dll is a shared library. By definition, that is reusable code. There's no necessity that "different languages" be encouraged, merely _a_ compiled language. Even if one extension were to be written in rust/zig and I choose to write an extension in C, is it really so hard for me to read the code I need from that extension and transcribe it for my purposes? I'm not convinced by the "reusable extension code" argument because I have not seen any statistics to justify it and I'm wary of anecdotes, including my own. How much of vim plugins or emacs extensions or vscode extensions are reused code from other extensions? Is it significant enough to raise this (that scripting language code is somehow more reusable) as an argument in defence of scripting languages as extension languages? d) Patently false I think. (Recall also that emacs didn't successfully mitigate this case for a long time and extensions in elisp could crash the editor.) It's just as easy, if not easier, to mitigate this kind of thing in C. A loaded dll or function can be run easily in a separate process or thread or whatever else one desires. (Didn't plan9 ACME implement communicating processes, an architecture that might be suitable as mitigation of the sort you describe?) (Also, reinventing the wheel is a bugbear that we should let go of. Attempting to reinvent a wheel is the only way by which one can truly understand how a wheel works. We shouldn't lose this ability or desire. The more we reinvent wheels, the better we get at examining fundamentals efficiently. If we don't reinvent wheels, we'll eventually lose the ability to make wheels.) f) Claiming "memory leaks and such" is a bit too abstract for me to understand what you mean. I've seen an emacs extension gobble up gigabytes of memory and crash the editor. I suspect I can write such an extension even today. The fault and responsibility would be mine, the extension writer's. I've seen python scripts consume all of a system's memory. There is no magic bullet that solves how much memory a program needs and when the program needs the memory. The programmer has to solve these things. I do not have any experience in AAA game studios. That said, I haven't heard of scripting languages being used extensively in recent years: A cursory glance at GDC presentations over the past 5 years doesn't reveal much emphasis on scripting languages or on the great successes you allude to. I gather from this that they've mostly been abandoned, excised from engines, or play a relatively insignificant role in the engines used for such games. I'm not convinced that compiled languages constitute a significant barrier to entry merely because they are compiled and have low level facilities. That would only be possible if programmers somehow didn't have a working understanding of how CPUs and memory work, could only function with a garbage collector, and were unable/unwilling to run compilers like gcc or debuggers like visual studio, but such a person wouldn't meet the definition of "programmer" anyway, I don't think. My assumption is that a text editor, in particular, is being written for programmers.