Hacker News Reader

Comment by chrisseaton | Hacker News Reader

> Since they're essentially just scripts

What do you think is the essential difference between a 'script' and a 'program'?

> What do you think is the essential difference between a 'script' and a 'program'?

I never said "program". I contrasted a script vs. a "binary" by which I meant a compiled executable. What I meant to highlight was the difference between the JS toolchain which is delivered as an artifact which needs an installed JS interpreter to evaluate. I've had issues my node/npm version to what the script expects, as well as managing different expectations by different scripts. In contrast, executables which are compiled for your architecture in advance and can be executed on their own without further dependencies are much simpler to use. Just download and run. Yes, there's static vs dynamic linking, but I mean to highlight how nice the (typical) Go workflow is which tends to statically include everything, moreso than rust, but rust isn't far behind.

This is a difficult question (and I think you're right in a technical sense in your implication that there isn't a true difference). Colloquially, I think of "scripts" as programs distributed as ASCII or UTF-mumble (or other widely-used string formats) source code that have to be evaluated by different programs installed on your computer, e.g. most JS, Ruby, Python programs.

It's a murky distinction, because it's very common to preprocess programs before distribution to the extent that the original code is hardly discernable; for example, using Uglify or transpiling ES2017 to ES3. And you can package programs in both Python and Node such that they actually don't depend on your system having a Node or Python interpreter installed. And I doubt people would refer to C programs as scripts, even if they're distributed in a BSD ports- or Gentoo-style packaging system that defaults to distributing source code rather than precompiled binaries.

But I think a decent rule of thumb is that if you can run the original source code file(s) directly by adding the right shebang to the top, it's a script.

one big differnce is that compiled binaries start much faster. but on a modern computer we are talking milliseconds. you have to take all trade offs into account though, people complain that apps made in JS needs a runtime. and that dowloading that runtime is a waste of space, but they forget that a statically linked binary can also get rather big.

Scripts are a subset of program focusing. The primary characteristic being they rely on another program to interpret the source at run time. Scripts also tend to be a problematic subset since libraries written in scripting languages tend to have poorly defined interfaces.

I kinda think of libraries vs scripts:

the library implements how to do the lower level -- which things you can do, and takes care of doing it

and the script deals with which things you want to do and when

some examples:

I made some opencv bindings for JS, and the library changes did the heavy image processing algorthims, and the JS script chose which ones to use with what parameters

for some video game or another, there was a library for what an NPC can do, and scripts for how they act within the world, including things that are more like movie scripts detailing whow says what adn where they walk

So if I wrote a Java program that uses OpenCV that program would be a Java-Script?

Not op but I think one difference between scripts and programs is some level of formal verification, as opposed to simple interpretation.

In this sense, JavaScript has advanced far beyond a "scripting language". TypeScript and Flow both allow plenty of formal verification with a type system that's quite a bit more expressive than many popular compiled languages have. It is indeed distributed as JS source code, but "simple interpretation" is an unfair description of what modern JS engines do. The JS is compiled to machine code, then introspected at runtime to look for optimization opportunities based on the real-world way that each function is used.

Scripts are usually flat. Just bunch of steps. No architecture. No advanced logic. No complex loops. Etc.

A script can’t execute itself?

You could implement a 'script' that implements an interpreter and then run that script on itself.

But you still need some interpreter to execute the initial script.

You could compile the script to native code if you wanted to.

A CPU is an interpreter.

Only if designed with microcode interpreter/JIT instead of pure hardware gates.

No. Even without those, the CPU interprets machine language.

It is a hardware interpreter.

Care to refer to any good CS/EE book that asserts your opinion?

You may want to re-read the definition of Turing equivalence. You should find it in any good CS/EE book.

You could bake a JS interpreter in silico. There are actual hardawre implementations of the JVM. You can also run machine language in emulators.

CPUs are just hardware interpreters for their respective machine language.

Reply since the edit window is closed.

I guess you could argue that an interpreter is specifically a piece of software, in which case my point wouldn't stand.

The interpreter would then be a standard program?

Metacircular interpreter is a pretty standard project in the lisp/Scheme world.

Reply on news.ycombinator.com