On Tue, Aug 3, 2021 at 11:29 AM Patrik Schindler <poc@xxxxxxxxxx> wrote:
Am 03.08.2021 um 15:50 schrieb John Yeung <gallium.arsenide@xxxxxxxxx>:
Depends on how you use the word "script". For many people, a script has to be interpreted, or at least *feel* interpreted (hard to draw the line between compiled and interpreted these days).
The line for an "user" is easy to draw: If I need to first call a compiler, it's explicitly compiled. Otherwise it's interpreted (optionally by a just-in-time compiler). :-)
But "need" is itself a kind of fuzzy concept these days. Many language
implementations have a standard command-line command which amounts to
"run" that calls what is technically an ahead-of-time compiler if the
compiled object doesn't already exist, and then executes the compiled
object. And even if the prepackaged implementation of a language
doesn't have that, today's editors and IDEs often do. Press a key, and
the program runs, including any necessary build steps. It often
happens so fast you can't tell, without knowing the mechanics
beforehand, whether what we traditionally think of as a "compiler" was
used.
Just to make my point, you cannot "directly" execute Python source
code, the way we traditionally think of interpreted languages. It is
compiled! Ahead of time! But the "target" of that compilation is
bytecode that is executed by a VM.
Java is almost universally considered a "compiled" language, yet it
also never compiles to machine-native code, only to JVM bytecode.
Even the notion of "machine-native" should be a fuzzy topic for a
midranger! There are so many layers of virtualization in IBM i. (Does
a *PGM object consist of XPF instructions? SLIC instructions? Does
anything bypass SLIC and literally consist of POWER CPU instructions?)
Don't worry, I get what you mean. But that is why I say things *feel*
interpreted or compiled. Pretty much everyone thinks Java feels
compiled and Python feels interpreted, even though if you draw a
diagram of their respective execution models and then get rid of the
labels, their diagrams look the same.
In the end, depending on the fact if script or program is important to the discussion, it's better to clarify terms beforehand. For helping Jay, it doesn't matter.
I fully agree it doesn't matter for Jay's situation. That was actually
the point of my response (quoted at the top of this message).
In any case, I am kind of surprised that so little fuss is being made over the fact that whatever Jay has is in Go! There is no formal support for running compiled Go programs in PASE yet, though some of the more intrepid Go enthusiasts have done it.
I guess that even Go supports linking code into a static binary. With that, I see no need to make fuss about Go binaries running in PASE. :-)
What I mean is: there seems to be so little surprise that someone is
running Go in PASE. I would have expected at least offhanded comments
like "hey, how did your Linux guy get that Go program to compile into
something that runs in PASE?"
I've read long threads of people talking about their struggles getting
a hello-world Go program to run in PASE. This is even with Kevin
Adler's help. And when they're done, they still can't *compile* the
program in PASE, they can only generate a binary (on their Windows or
Linux machine) that, once transported to an IFS directory, can run
unmodified in PASE.
I think it's definitely interesting, and worth at least noting, even
though it didn't play any role in solving Jay's immediate problem.
I would have been less surprised if Jay had said he's got an Erlang or
Elixir program he's trying to run in PASE. As languages go, they are
much less well-known than Go, but they at least have been implemented
as yum-installable RPMs available for PASE.
John Y.
midrange.com
