4 ms·

For me it's when it's useful for writing adhoc utility tools distributed as source, and directly runnable from source code in the terminal and without requiring

For me it's when it's useful for writing adhoc utility tools distributed as source, and directly runnable from source code in the terminal and without requiring a manual compilation step (but maybe requiring installing a runtime). E.g. Python, JS/TS with node.js/deno, Lua, Bash, Powershell qualify as scripting language, but C, C++, Rust are not. Of course there's a grey area of compilers which allow compiling and running a "script" via shebang.

teo_zero 3y ago
Sorry, but I strongly disagree with your explanation. It seems to categorize languages on the basis of what tools are available or widely used. That's not a property of languages. A language can be designed once and then interpreters and compilers (and transpilers) can be made available for it. Python is a classic example: it's most commonly interpreted, but can be compiled when performance matters. C is usually compiled, but tcc offers the option to directly run it from source (-run). History has given us both compilers and interpreters for various dialects of BASIC since the 80s. Honestly I can't imagine why a language designer should decide upfront if the result of their study will be interpreted or compiled. And I have no idea what choices should they make to characterize it as a "scripting" language.
- mek6800d2 3y ago
  Slight correction: TCC is not interpreting the source file - it compiles and links the program and then runs it.
- naasking 3y ago
  > A language can be designed once and then interpreters and compilers (and transpilers) can be made available for it. While strictly true, some language features are awkward or unsuitable for scripting purposes. For instance, C++ templates and Haskell's type classes with extensions that make overload resolution Turing complete. You can do this, but it seems like a poor choice where the language ostensibly has runtime evaluation and type information available, and so you don't need to so strictly stratify the types and values. This collapses effectively two programming language levels into one, and considerably simplifies quite a bit of the runtime, compiler/interpreter, and the programs that can be expressed in the language

teo_zero 3y ago

Sorry, but I strongly disagree with your explanation. It seems to categorize languages on the basis of what tools are available or widely used. That's not a property of languages. A language can be designed once and then interpreters and compilers (and transpilers) can be made available for it. Python is a classic example: it's most commonly interpreted, but can be compiled when performance matters. C is usually compiled, but tcc offers the option to directly run it from source (-run). History has given us both compilers and interpreters for various dialects of BASIC since the 80s. Honestly I can't imagine why a language designer should decide upfront if the result of their study will be interpreted or compiled. And I have no idea what choices should they make to characterize it as a "scripting" language.

mek6800d2 3y ago
Slight correction: TCC is not interpreting the source file - it compiles and links the program and then runs it.
naasking 3y ago
> A language can be designed once and then interpreters and compilers (and transpilers) can be made available for it. While strictly true, some language features are awkward or unsuitable for scripting purposes. For instance, C++ templates and Haskell's type classes with extensions that make overload resolution Turing complete. You can do this, but it seems like a poor choice where the language ostensibly has runtime evaluation and type information available, and so you don't need to so strictly stratify the types and values. This collapses effectively two programming language levels into one, and considerably simplifies quite a bit of the runtime, compiler/interpreter, and the programs that can be expressed in the language