Linked by Thom Holwerda on Mon 3rd Sep 2012 20:46 UTC, submitted by MOS6510
General Development I like this one: "By definition, a program is an entity that is run by the computer. It talks directly to the CPU and the OS. Code that does not talk directly to the CPU and the OS, but is instead run by some other program that does talk directly to the CPU and the OS, is not a program; it's a script." Here's the other eleven.
Thread beginning with comment 533714
To read all comments associated with this story, please click here.
by panzi on Mon 3rd Sep 2012 21:20 UTC
Member since:

So if you run any OS in an VM (not paravirtualized) it suddenly becomes a script?

Reply Score: 6

RE: Scripts
by c0m47053 on Mon 3rd Sep 2012 21:28 in reply to "Scripts"
c0m47053 Member since:

Lots of these opinions are "controversial" because they are a load of hogwash.

I don't think there was any effort to actually filter out rubbish answers.

I think you could say that it is only programming if you don't use a compiler (or even assembler), and be equally (in)valid.

Reply Parent Score: 8

RE[2]: Scripts
by Vanders on Mon 3rd Sep 2012 21:36 in reply to "RE: Scripts"
Vanders Member since:

Lots of these opinions are "controversial" because they are a load of hogwash.

Hogwash and/or gibberish. For example:

If a method has a second line of code, it is a code smell. Refactor.

What does that even mean?

Having come from a coding background where you were required to know the hardware, and where this is still a vital requirements in my industry, I view high level languages as simply assembling someone else's work.

So I assume this guy programs by waving a magnetised needle over the platter. Hey, wouldn't want to be using somebodies else's work now!

Reply Parent Score: 5

not controversial at all, just plain stupid.
by sergio on Mon 3rd Sep 2012 22:30 in reply to "Scripts"
sergio Member since:

x86 assembler is scripting too.

Because It's not native at all. All x86 machine code is translated internally to microcode and that microcode is the native language of today CPUs.

x86 instruction set is just a compatibility layer. So all what We write are scripts.

Reply Parent Score: 9

RE: Scripts
by butters on Tue 4th Sep 2012 01:41 in reply to "Scripts"
butters Member since:

There are significant downsides to treating the hardware instruction set as a stable programming interface. Logic processors have been stuck on the Von Neumann architecture since the dawn of time because we use static optimizing compilers to target a particular hardware instruction set, and in the case of x86, it's not even a particularly convenient instruction set to implement in hardware.

Contrast this with the evolution of graphics processors, which support high-level programming interfaces via runtime interpreters plugged into the kernel device driver system which target unstable hardware architectures.

Over time, the hardware interface moved up the stack as certain operations, such as vertex shading, were factored out of the drivers and implemented in hardware. The programming model didn't change much, but the hardware changed radically.

Modern graphics processors understand compound data types like pixels, vertices, polygons, textures, and frames. Modern processors are remarkably good at integer arithmetic and boolean logic, but they don't understand the generalized sorted mapping type which dominates the architecture of most software systems.

Everything from C and UNIX filesystems to Ruby and Cassandra are based on sorted maps. At some point in the development or runtime process, each reference is translated into a key on a sorted map, which is then translated into an address in a flat linear array.

If not for statically compiled native machine code, the hardware would have evolved closer to the structured programming models that have prevailed since ALGOL, and modern processors would implement an instruction set closer to lua than x86.

Reply Parent Score: 6

RE: Scripts
by phoudoin on Tue 4th Sep 2012 12:22 in reply to "Scripts"
phoudoin Member since:

Well, he didn't said that the CPU or the OS can't be virtual and guest, respectively, but only that the program should be *directly* talking to the CPU and the OS. By such definition, a program whose instructions are *directly* talking to a virtual CPU and an guest OS is still a program, not a script...

Anyway, less controversial than pseudo-elitism IMHO.

Reply Parent Score: 3

RE: Scripts
by JuEeHa on Wed 5th Sep 2012 16:17 in reply to "Scripts"
JuEeHa Member since:

Also is any program using a I/O library (ie. not talking to OS directly) a script?

Reply Parent Score: 1