3 ms·

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 optimis

by 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.

coldtea 7y ago
(a) I don't think we can agree in the end starting from this though. In general, scripting languages are extremely popular and just fine for most people, and editors with tons of quality extensions (Emacs, Vim, Sublime Text, VS Code) all have them written in those. Even if your argument was valid about building a large system, here we're talking editor extensions. (b) If you're accustomed to compiled languages (e.g. seasoned C/C++ programmer), then sure you are not. But setting up the correct environment, debugging, etc is more difficult for C/C++ than for any scripting language, and a big barrier to entry. (c) The necessity arises from wanting to get more extensions, and thus attract more coders. If you only allow C extensions, you'll get much less extensions (and not necessarily higher quality either). So you either give a scripting extension language (low barrier, easy access, lots can start using it), or many scripting langauges (even better), or you allow for many compiled languages though an API/ABI (higher barrier, but at least not limited to a single one). I hardly believe this is a controversial point. Literally almost any app that ever wanted to get more extensions from users went that route. They didn't tell them: "just set up GCC, get the headers, and be on your way", because they knew the majority of potential users (extension authors) would be put off. In fact, even hardcore C++ AAA game developers add a scripting engine, not for end users, but to make it easier and faster for themselves to develop the logic, behaviors, etc, of the game, exactly for the same reason: outside of the critical paths C++ is overkill, and slows down momentum. (d) So, not exactly patently false, but only "patently false if you also make a special architecture choice for it" (off-process, messaging, etc). > f) Claiming "memory leaks and such" is a bit too abstract for me to understand what you mean. (f) A scripting GC makes it from less easy to impossible to have memory leaks in your extension that e.g. C. 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. >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. Nope. They've never went away.

by noch 7y ago

coldtea 7y ago

(a) I don't think we can agree in the end starting from this though. In general, scripting languages are extremely popular and just fine for most people, and editors with tons of quality extensions (Emacs, Vim, Sublime Text, VS Code) all have them written in those. Even if your argument was valid about building a large system, here we're talking editor extensions. (b) If you're accustomed to compiled languages (e.g. seasoned C/C++ programmer), then sure you are not. But setting up the correct environment, debugging, etc is more difficult for C/C++ than for any scripting language, and a big barrier to entry. (c) The necessity arises from wanting to get more extensions, and thus attract more coders. If you only allow C extensions, you'll get much less extensions (and not necessarily higher quality either). So you either give a scripting extension language (low barrier, easy access, lots can start using it), or many scripting langauges (even better), or you allow for many compiled languages though an API/ABI (higher barrier, but at least not limited to a single one). I hardly believe this is a controversial point. Literally almost any app that ever wanted to get more extensions from users went that route. They didn't tell them: "just set up GCC, get the headers, and be on your way", because they knew the majority of potential users (extension authors) would be put off. In fact, even hardcore C++ AAA game developers add a scripting engine, not for end users, but to make it easier and faster for themselves to develop the logic, behaviors, etc, of the game, exactly for the same reason: outside of the critical paths C++ is overkill, and slows down momentum. (d) So, not exactly patently false, but only "patently false if you also make a special architecture choice for it" (off-process, messaging, etc). > f) Claiming "memory leaks and such" is a bit too abstract for me to understand what you mean. (f) A scripting GC makes it from less easy to impossible to have memory leaks in your extension that e.g. C. 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. >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. Nope. They've never went away.