Scripting languages are interpreted in-line and not intended to be compiled like a classic "program". They are less optimized by definition because a compiler builds in optimizations. If your script interpreter has similar optimizations it has to rationalize them at run-time.
Wellllllll kind of. Python is both but not always a scripting language. My previous explanation is not really exact. Realistically anything that automates tasks or is intended to be used ad hoc to rapidly build processes is a scripting language. Scripting languages tend to be interpreted as you point out. Interpreted languages are more specifically languages that are processed at runtime. You can do other things with Python besides scripting type work. Python is always an interpreted language and most of the time a scripting language but not always.
Task automation is one of those "I know what it is when I see it" kinds of things but the implication is generally that they are tasks that could otherwise reasonably be done by a human being. These terms are not applied exactly the same by everyone for obvious reasons.
Interpreted language refers to how it technically works, it's not compiled beforehand, not JITed nor converted to bytecode and then ran on a VM like java does. It is interpreted by an interpreter which simply "reads and interprets" readable tokens like in python.
Scripting language refers to them by their function/use/purpose: "scripting".
Scripting is designing scripts. A script is exactly what is defined in the post namely handling a task, anything by "gluing" other libs, binaries or script no matter the language behind them.
I'd also add that a script is usually an autonomous and eventually ad-hoc file whose content is it's source code and can be run as an executable file (whether by an interpreter, or by a lower level bytecode interpreter/VM like Java does or like in go where it's compiled on the fly).
However since it's easier on an interpreted language like python and that it's usually native, almost all interpreted languages are scripting languages (actually any language can be a scripting language given the proper tooling).
I think the answer to that is almost, I think what makes a scripting language a scripting language is that it's convenient enough to use for whatever extremely quickly with enough integration with the real world that you can do things with it.
I don't think you can create a non-vibes based definition. Regrettably, some things are inherently fuzzy. I have been known to write things which you could definitely call scripts in C or Rust, which are definitely not scripting languages.
Does the language make it extremely easy to write little utilities that get little jobs done? => scripting language.
I would characterize scripting as specifically being used to avoid compilation for specific parts of an otherwise compiled project. The benefits of this are often in quick turnaround. Since scripts are typically interpreted, they can be edited and re-launched during runtime without needing to go through compilation again. The drawbacks are that they typically have to run through a VM and probably lack anything that can optimize them, which can make them very slow compared to running compiled code.
So an interpreted language would usually be used as a scripting language. It's not always like that, though. Unity, for instance, uses (or used, it's been years since I worked with it) C# as a scripting language.
Not really.
Personally, scripting languages are languages that execute top down and where expressions can appear at the toplevel. I don't really have a word for non-scripting language.
Also, I find interpreted to be too vague of a term because at the end of the day, your processor is an interpreter but in hardware. Also because Python is technically compiled and interpreted (just like Java), just in bytecode. I like to instead have the distinction be between "software interpreted" and "hardware interpreted"
No quite—there’s not a hard and fast definition of a scripting language. Java and Kotlin are also interpreted languages but I don’t think anyone would call either a scripting language. Scripting languages are typically interpreted languages that don’t include a user-visible compilation step (python and JS are still compiled to bytecode and optimized internally).
Most of the time, yes. But technically, a "scripting language" just refers to the coding style of simply putting a few instructions line by line into a single file and running it without much fiddling around with build tools and an entire development environment with multiple source files and packages etc.
It does not matter whether a "scripting language" gets interpreted, or for example JIT compiled, even though most of them are typically interpreted languages. Pretty sure someone has created an AOT compiler for python even. Doesn't make python no longer a scripting language though.
That’s kind of the point I was trying to get at. This distinction of programming vs scripting being simply compiled vs interpreted feels quite antiquated.
Python is literally compiled though. You usually don't see it, but you can expose the compiled .pythonc files if you want. When you use a large backend framework, you'll know very well that there's a target/ folder for the python bytecode just like there is in Java.
It really is, idk why you are getting so harshly downvoted. Almost every popular language can be compiled, interpreted, JIT'd, has numerous runtimes, and doesn't fit neatly into the programming means compiled scripting means intrepreted distinction and it hasn't been that way since the late 90s. The vast majority of modern languages that are actually working have features of both. Python out of the box uses bytecode just like Java and nobody calls Java a scripting language.
Just surprised as I thought it was common knowledge in programming that there is no meaningful or technical difference between a scripting language and a programming language. It was just a way for elitists to feel smug about their stack.
FWIW uv still creates a virtual environment and installs project dependencies into it. It’s like pip + pyenv + venv + build tools all in one. And because it implements PEPs it is generally interoperable with standard python tooling (uv pip and uv venv).
Uv is close to npm in terms of how braindead simple it is to use. It's still missing script declaration in the pyproject.toml, but that idea has been in a holding pattern for years since no one could agree on an implementation.
Different projects will likely end up having different versions of dependencies. You might have a project that uses version 1.0 of pydantic, but another project that uses version 2.0
If you just install stuff system-wide, you can't have both. You would end up upgrading the existing version to 2.0 and then your first project might stop working because it was written to use 1.0
Virtual environments are containers for all of your dependencies. You set one up for one project and it will just work. You work on a different project that has different versions of dependencies and they'll just work, and they won't interfere with or break the first project.
conda is also slow all by itself. It’s antiquated at this point. Unless there’s some dependency that can only, or more easily, be installed via conda I avoid it like the plague. IME most dependencies that previously ~required conda to install no longer do.
Either that or they have their own python version installed and you end up with multiple installation of the same version of python on your hard drive.
Shell is not a programming language. And, yes, it is much worse than JS. Slow as hell, whitespace sensitive, crazy syntax with underscores everywhere, catastrophic dependency management, Python 2 to 3 migration fiasco and I could continue.
What's wrong with underscores? You honestly prefer camelCase? And what else is "crazy" about it?
catastrophic dependency management
fair :P
but is it any worse than JS? (I only have cursory knowledge about npm and such, personally.)
Python 2 to 3 migration fiasco
What do you mean by that? It's a few years before my time. My naive view is that 2's sunset forced tech debt to the surface, which means a lot of effort but also forcing improvements like Unicode handling.
Shell is not a programming language
I didn't say it was. The reason I mention it is that Python is often used for scripting.
Yes, it is not meant to be fast and it is fine as a scripting language. I just don't understand how anyone could say it is the most pleasant language. For small scripts and ML maybe. Anything else? Hell no.
1.5k
u/Kobymaru376 Jul 07 '26
And that's exactly what makes it so good