On Fri, 16 Mar 2007, Gabriella Turek wrote: > > With instructions that involve physical properties (such as how to > > cook spaghetti, or how to speak effectively) the instructions alone > > don't get you very far. You need labour and possibly raw materials. > > > > With source (or object) code, the instructions are pretty-much > > everything. > > One could argue that unless you can compile the stuff, you can't do very > much. Compiling is not necessarily straight forward, Well I suppose it all depends on how you define the word "compiling". Launching the compiler to convert source code into object code is as simple as falling off the proverbial log [1], whereas what the compiler does internally to achieve this conversion is, I agree, far from simple. Many Doctorate theses have been won creating and enhancing the process.
> although I presume > you could take the src and use it to write something you can compile > yourself. Provided you have the tools and dependencies to do it, you can _always_ compile somebody else's code. That's what you are doing whenever you write 'make' to the shell while in the top directory of a source code tree. [1] See Lesson01 in:- ftp://svr-ftp.eng.cam.ac.uk/misc/sawtell_C.shar or locally http://shell.clug.org.nz/~chris/sawtell_C.shar Whilst that was written some 15 years ago it is still relevent today. The point Carl & I are trying to make is that compiling is a fixed mechanical process which does nothing whatsoever to change the fundamental meanings or algorithms expressed in the source code. In the case of the source code the algorithms are expressed in a human readable form, whereas the executable code produced by the compiling and linking processes expresses the identical algorithms in a machine readable form. The actual meaning has not been changed one iota. I would love to know what logical processes the US Congress used to split the hair which allowed it - Congress - to legislate that the source code of a program is free-speech, whereas the executable binary file is not. -- CS
