Comment by da39a3ee | Hacker News Reader

Comment by da39a3ee | Hacker News Reader

> Wren is a scripting language.

As far as I know "scripting language" doesn't have a widely-agreed upon definition and we should all stop using it.

If anyone were to ask me, I'd say that a "script" is a program that contains a sequence of commands. It executes transiently for some side effect, as opposed to creating a persistent process responding to events.

So for example, bash is clearly a scripting language, and if one is being rude about the appropriate uses for perl, then perl would be too. Python can be use for "scripting" but certainly isn't in general a scripting language by this definition. And I don't really think "scripting language" is a helpful term for Javascript, since it's most important role by far is in as an event-driven persistent process. However, some people (especially old-school C-programmer types) use "scripting language" to mean an interpreted language, I think.

I think for Wren, maybe it's referring to a usage of "scripting" that C programmers associate with Lua?? None of the things it mentions are things that I personally associate with the word "scripting":

> Wren is intended for embedding in applications. It has no dependencies, a small standard library, and an easy-to-use C API. It compiles cleanly as C99, C++98 or anything later.

Or is the idea that both Lua (and thus Wren) and Javascript are "scripting" languages in the sense that they augment an executable written in a "proper" language with additional run-time functionality? If so, then that's interesting but I don't think many people get it (it only occurred to me while writing this) and we should clarify the terminology.

I understand about avoiding unclear terms, but I think "scripting language" actually does serve a useful purpose as an umbrella term for all those kinds of languages. It's not technically precise, but if you describe a language as "a scripting language", it does clear away a large part of the design space (not Haskell, C, Forth, or J) and tells you that this is meant to be user-friendly as opposed to performant, terse, high-assurance, etc. That's worth something. Of course if someone is still interested, then you want to get more precise pretty quickly. I think Wren does well enough at that on its landing page.

> user-friendly as opposed to performant, terse, high-assurance, etc.

Strange, I really don't see that as an axis worth recognizing with that, or any, terminology (but whenever I bring this up I get voted down, so I guess more people agree with you.)

I think the core of my disagreement is that, just because a language is user-friendly, that does not mean that it is not a "professional" or "high-assurance" language. I'm not saying that you are using it in this fashion, but I believe that with the terminological strategy you are suggesting, the term becomes a pejorative, wielded by those who use (C/C++/Rust/Java/Haskell/etc) as a subtle put-down to people who are using more user-friendly languages.

Related, I think it's a rather confusing axis that doesn't fit the space of programming languages well:

Go is user-friendly (I gather) and verbose, but performant and high-assurance.

Python is user-friendly and terse, but non-performant and low-assurance (I'm a python programmer, but the run-time bugs put it in that category if we're comparing to statically typed languages). A lot of website HTTP handlers are written in Python, so "scripting" language seems like a very poor description for what it's doing there.

IMO reasonable axes that are worth recognizing with terminology include interpreted vs compiled, statically vs dynamically typed, weakly vs strongly typed, but do not include {user-friendly} vs {performant, terse, high-assurance}.

It might make more sense if you think of "scripting language" as being a statement of intent than a technical classification. I have seen it used as a perjorative, which I agree is stupid.

More generally, performance, ease of programming, correctness, etc are goals, whereas typing systems and compilation strategies are techniques that can be used to reach those goals. "Axes" is probably overthinking it, as none of these criteria or properties are linear, but terms for all of them can be worthwhile if used to answer the right questions.

Since goals have a strong influence on technical properties, it's not completely crazy to summarize a language's technical features in terms of its goals. "Scripting language" makes sense as a description for languages that emphasize ease of programming (with overtones of interacting with a larger system) over other features. You also have a clue about a language called "high performance": probably not interpreted or dynamically typed (although exceptions include kdb, arguably Java and Julia).

Finally, not every term needs a rigorous definition in terms of more primitive terms. Sometimes you just need a name for a category that everyone kind of knows is there. This is probably the more realistic origin of the term, though I do think the underlying reason for that category existing is mostly the goal-driven one described in my previous paragraph.

Note: In the bit you quoted, I certainly didn't mean to say that "user friendly" was necessarily opposed to all those other goal properties. I was just trying to give examples of other things you might want to prioritize in a design.

I think the best colloquial definition at this point is "a higher-level language that delegates to lower-level code for core logic". Usually that higher-level language is interpreted and dynamic, but it doesn't have to be. I read a post once that suggested using Haskell as a "scripting language" for Rust.

This definition is most precisely used in games, where the dichotomy is particularly common due to their high requirements for both performance and creative expressivity. But it also nicely encompasses bash scripts delegating to C utilities, JavaScript delegating to the web browser, and Python delegating to NumPy. It's also generally the goal with embedded languages like the one in the OP.

Thanks, yes that's very helpful. In my experience (scientific and web backend programming, no games and no industry compiled) there's a large number of people who are not aware of this definition of scripting. For them, a "script" is a program written in a procedural style that runs and does some stuff and exits.

So, for example, web backend python programmers might "write a script to run on prod to fix the messed up data", but they would not refer to their flask/django HTTP handler code as scripts (whether they defer to numpy or anything else).

In research labs, scripts (sensu me) are often the only category of code that is written. They fit the definition you gave in that they probably delegate to things, and the one I gave in that they are typically procedural and linear.

My definition for scripting language is even more basic than the other commenters here - a scripting language is one where the user executes the source file (the script).

Of course the system is free to do whatever it wants under the hood (e.g. Python generates .pyc files) etc, but as a user if you can double click the main source file/feed it to a program and have the full program run, then it's a scripting language.

I think of it, very generally, as: scripting language = writing a 10 line program isn't a chore; non-scripting language: writing a 1000 line program isn't a chore

OK, so according to that criterion, where would you classify

Python

Ruby

Javascript

?

Reply on news.ycombinator.com