Code as speech
I think that there's two kinds of code, and that's what's causing the argument- there's code that's written to accomplish things, and there's code that's written to communicate ideas. Code is often used to communicate algorithims, especially crypto algorithims. It's a good language for describing a crypto algorithim- concise and unambiguous. As I'm sure EKR is aware, the crypto litterature is full of descriptions of algorithims as code. Often these are in pseudocode or code fragements. Neither of those could possibly be construed as existing only for the purposes of running a program, since they won't compile and run. To me, writings or utterings meant to convey information from one human to another are 'speech'. Therefore, code is, at least sometimes, pure speech. On the other hand, the majority of code is written not to explain something to humans, but to perform a task on a computer. That code is sometimes written by one person who isn't thinking about maintainability, so he writes it in whatever style pleases him. That may well be the most awful kind of spagetti code- totally unreadable even to the original programmer when he sees it a month later. Yet it compiles and performs it's task. Most code falls somewhere between these extremes. Most code to perform tasks needs to be readable to some degree, in order for more than one person to be able to work on it, or for future maintenance by one programmer. Most people learn how to make their code at least a little readable after the first time they have to read old code they wrote and spend hours re-discovering what it does. ALL good programmers I have known do this, although ideas about what is "readable" differ widely. -- Eric Murray N*Able Technologieswww.nabletech.com (email: ericm at the sites lne.com or nabletech.com) PGP keyid:E03F65E5
Re: How to donate a clue to a lawyer?
> You're just asserting this again. The fact that people get paid for > making pigs dance and not primarily for making their code readable > suggests that the purpose of the exercise is to make the computer > do stuff, despite your assertion to the contrary. I get paid by the ISC to write code that is readable and can be understood. That's what a reference implementation is. I don't actually claim to have succeeded at this, but I've done my best, and readability is indeed one of the primary goals of my code. Another is the codification of knowledge about the various little edge cases in the DHCP protocol - if you look through my code, you'll find a great deal of code and written comments that document such things. Your disdain for the fruit of your labor is depressing, sir. I encourage you to think of it more highly. _MelloN_
OT: coding as speech (was: Re: How to donate a clue to a lawyer?)
Sprach EKR <[EMAIL PROTECTED]>: > Carl Ellison <[EMAIL PROTECTED]> writes: > > Source code is human speech, for human-to-human communication. It has a > > side-effect of being compilable into machine code, but it is in a human > > language and is intended for human communication. > This strikes me as patently false. > > If programmers though this way, they'd make an attempt to make their > source code readable, but by and large they don't. Moreover, the > code (especially C code) is littered with constructs which serve > no communicative purpose but solely tell the computer what to do. > (Memory management comes to mind as a prime example. The only > purpose of calling free() is to release memory. It serves no > expository purpose. This is clearly shown by the fact that > garbage collected languages do without it.) Ummm. No. As a trivial example, if I am attempting to communicate about memory management issues, my use of free() might become the primary carrier of meaning in the code. In a much more common example, an ongoing question with third party libraries is "who allocates the memory buffers used by the function" and "who frees the memory that's allocated by the function". Suitable uses of malloc() and free() in code fragments (or their absence) precisely communicates the answers to both of those questions. In fact, I will go further than this: every feature of a program, from the actual functional elements to whitespace and punctuation has the potential to carry communication, even when those are seemingly arranged in such a way as to hinder communication. As every professional programmer knows, your use of whitespace bears redundant syntactic meaning for people who use the same whitespace style. Obscure code constructs are a very good way to communicate efficient coding techniques (which is to say: techniques by which the programmer can control the output of the compiler's optimizer), or simply ways to describe the powers and limitations of the language. A perfect example of this last is the Obfuscated C Code contests: surely no one is about to claim that the primary purpose of that code is to control a computer. No, the primary purpose is to communicate the message "I'm mucho more studly coder d00d than U" to the other contestants. In fact, code snippets are such a good way to communicate, that for 7 years, I would interview job candidates merely by showing them a particularly subtle 4 line 8086 assembly code fragment and asking them what function it performed, and to reason out loud as they tried to figure it out. (I also use the fragment to show that optimizers will never be as good as human programmers). Last, don't try any "if programmers thought this way..." statements: I'm a programmer, and I think this way. Therefore, there is at least one programmer who does. There's no "if" involved. -- Jon Paul Nollmann ne' Darren Senn [EMAIL PROTECTED] Unsolicited commercial email will be archived at $1/byte/day. Congratulations FBI men: Hoover would be proud of you
Re: code
Perry E. Metzger wrote: > Source code exists for people first, computers second. If this were > not the case, we'd all just write code in machine language. High level > languages exist *explicitly* to make it easier for people to > comprehend computation tasks. Communicating algorithms, both to the > reader who is not the author, and later to the author of the code > himself, is why we use high level languages. I think that's going a little too far. We use high-level languages because it is easier, because they are more expressive. That is, of course, strongly related to their readability and capability to be used to communicate ideas, but those abilities are _not_ the primary motivation for high-level languages. However, readability and communication _are_ the reason that good programmers use expressive variable and function names, follow code layout styles and so on. > Maybe Mr. Rescorla doesn't believe it, but I do, and it is the > doctrine taught in every decent CS curriculum in the world. It is also what programmers learn from programming (or, at least, some do. I never did a CS degree :-). Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: How to donate a clue to a lawyer?
EKR wrote: > If your purpose in using code is to communicate with other > humans, what you want to communicate is intention with only > the barest amount of procedure. However, in reality programs > are almost all procedure with the barest amount of structure > to attempt to communicate intention to humans who need to > work on it. Don't get it. In a programming context, what is the difference between intention and procedure? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: How to donate a clue to a lawyer?
Carl Ellison <[EMAIL PROTECTED]> writes: > -BEGIN PGP SIGNED MESSAGE- > > At 02:26 PM 5/8/99 -0700, EKR wrote: > >Carl Ellison <[EMAIL PROTECTED]> writes: > >> Source code is human speech, for human-to-human communication. It has a > >> side-effect of being compilable into machine code, but it is in a human > >> language and is intended for human communication. > >This strikes me as patently false. > > Feel free to be struck that way, but you haven't shaken my conviction. I didn't expect to. Convincing yourself does not mean that you have a convincing argument, however. > >If programmers though this way, they'd make an attempt to make their > >source code readable, but by and large they don't. > ...and they suffer for that oversight, later. They suffer because while > they're programming they don't realize the purpose of the source code is not > merely getting pigs to dance on screen but equally to communicate to the > next human to read the code. You're just asserting this again. The fact that people get paid for making pigs dance and not primarily for making their code readable suggests that the purpose of the exercise is to make the computer do stuff, despite your assertion to the contrary. > Of course the purpose of free() is to release computer, not human, memory. > The reason it's readable (an English word, in fact -- as opposed to > 0xB548976A) is so you and I can read it, however. Yeah, so? This doesn't make it a form of human to human communication. Look, computer languages look like English because it makes them (1) easier to learn since you can coopt keywords the user already knows. (2) easier to read because they vaguely look like sentences. For the same reason, many internet protocols are ASCII based (e.g. SMTP) because occasionally someone has to read them. This doesn't mean that the most important purpose of SMTP traces is to be read by humans. I'm not arguing that it's not a worthwhile purpose for code to be readable (despite my personal opinion that it isn't very likely). I'm arguing that it's not it's primary purpose nor is it necessary to fulfill its primary purpose. The fact that the world is full of unreadable code that still runs proves this point quite handily, I think. > The very fact that you used the construct > > free() > > in the middle of a sentence to me, I understood what you meant by it, and I > could reply in kind, also using that construct, shows that that construct is > an element of human-to-human communcation. It can be used in that fashion. However, it's usually not the clearest way to explain how software works. That's why people who distribute software write documentation. I've worked on systems where you had to reverse engineer how the system worked from the source code. I didn't enjoy it. Moreover, when people use code to illustrate their point, they usually strip out a lot of the housekeeping that's really necessary to make software work. (Error handling, for instance. Memory management is another example, as I pointed out previously.) > No computer is going to execute > that paragraph you wrote. Of course, I'm not saying that there is no other > effect -- of getting pigs to dance on screen -- only that there is a > human-to-human communication happening here. You said "It has a side-effect of being compilable into machine code, but it is in a human language and is intended for human communication." Being compilable is not a side effect. It is the PRIMARY purpose. Software that doesn't compile isn't software. > People have to be taught how to write text. We're not born with the ability. Uh, yeah? What's your point? > >> QED > >Hardly. > > Nope, still QED. Blanket assertion is not a form of demonstration, Carl. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]]
Re: How to donate a clue to a lawyer?
If readability of code doesn't matter, why have I seen so much angst within communities of developers indentation styles, identifier spelling, and line breaks? None of them make a bit of difference in the generated object code.. I think Sturgeon's Law may apply here: "90% of everything is crap"... The fact that there's a lot of bad, "write-only" code out there (and I'm certainly responsible for some of it..) does not preclude the existance of quite readable code. Maybe I've just been lucky, but I've had the good fortune to work in environments where my coworkers and mentors cared about the readability of code (and got on my case when I didn't live up to their standards). Programming languages are a mixture of ambiguity and precision. They specify certain things very precisely, and leave other details up to the implementation of the language. Higher level languages are, in general, higher in ambiguity, and lower in precision. Sometimes this is good, sometimes this is bad. Memory management comes to mind as a prime example. The only purpose of calling free() is to release memory. It serves no expository purpose. This is clearly shown by the fact that garbage collected languages do without it. On the contrary, "free()" makes an expository statement that "this object should no longer be used by the program". Often, that isn't necessary, but (for instance) if you are concerned about the exact memory usage of a program, the presence of explicit free() calls makes it easier to understand, and measure, what's going on.. Don Knuth makes a similar argument in defense of his continued use of assembly language for a hypothetical computer for the exposition of algorithms in his continued revisions to The Art of Computer Programming. See the "Why have a machine language" section of http://www-cs-staff.Stanford.EDU/~knuth/mmix.html .. The very fact that you have to be taught this should make clear that the actual purpose of code is instructing machines, not people. People hardly ever forget that the purpose of writing text is communication. I'm not sure I follow the logic here -- all it make clear to me is that the teachers/mentors/etc., care about the quality of the work.. The amateur singers in the theatrical productions I've been involved with regularly needed to be reminded to improve their diction. I would take it that you would argue that the words they sing don't actually matter... - Bill
Re: How to donate a clue to a lawyer?
>From my declaration for the Bernstein case: http://www.eff.org/pub/Privacy/ITAR_export/Bernstein_case/Legal/960726_filing/ellison.decl "18. Attached hereto as Exhibit C is an excerpt from the August 1967 CACM, giving another example of an article which consists solely of source code. 19. In addition, the Exhibit C includes the August, 1967, statement of the algorithm policy of the Association for Computer Machinery. The policy notes: It is necessary, but not sufficient for the published algorithm to operate on some machine and give correct answers. It must also communicate a method to the reader in a clear and unambiguous manner. All contributions will be refereed by human beings and by an appropriate compiler. " That is, of course, not the only example. +--+ |Carl M. Ellison [EMAIL PROTECTED] http://www.pobox.com/~cme | |PGP: 08FF BA05 599B 49D2 23C6 6FFD 36BA D342 | +--Officer, officer, arrest that man. He's whistling a dirty song.-+
procedural vs. declarative speech (was Re: How to donate a clue to a lawyer?)
At 11:47 PM 5/8/99 -0700, EKR wrote: >I believe you're failing to distinguish the intentional purpose >of code -- describing what you want done -- from the procedural >purpose of code -- describing what in fact is to be done. This isn't >surprising, given that no current language gives you the ability >to actually communicate your intentions as opposed to the >procedure. This is a bug, not a feature! I think 'formal verification' is the closest people come to such nonprocedural descriptions; CS language types also like to play with such languages. Ok, in practice very few use formal logic to verify their code in practice, though it can be done. (Possibly people working on small critical code sections might prove various theorems about it.) But a language doesn't have to be implementation-neutral to be humanly-expressive, does it? Going back to your original statement, >> >code (especially C code) is littered with constructs which serve >> >no communicative purpose but solely tell the computer what to do. I can describe English that way too: English prose is littered with constructs which do nothing but instruct another brain. Punctuation, articles, etc. are not part of the 'intent'; they're just there to tell your linguistic processor what to do. >If your purpose in using code is to communicate with other >humans, what you want to communicate is intention with only >the barest amount of procedure. What if you're communicating a procedure? Good or bad, that's what we do.. only managers can get away with specifying only what they want... The host asks for a dish, the chef has to phone another chef for a recipe. Of course the recipe will include implementation-dependent things, like the size of bowls to use or number of times to whip the cream. The recipe is protected speech even if the dish would be illegal in both regions. However, in reality programs >are almost all procedure with the barest amount of structure >to attempt to communicate intention to humans who need to >work on it. > >> Eric I hope you're just miffed about reading some lame >> code written by some quasi-literate who can't touchtype. >Nope. I'm a professional programmer with a realistic attitude >about the situation. I'm not interested in making specious >arguments about how software is speech merely to serve a political >purpose -- even one I happen to agree with. I hope you didn't think I meant you were that novice. The issue for the Bernstein opinion isn't about *software*, its about source code. 'Software' includes executables, which don't seem protected by the B vs. DoJ decision. The fact that you have to choose to perform separate behaviors (compiling, loading, linking, running) isolates source code from otherwise-(mis)regulated executables. A blueprint for a full-auto sear or a NC gerber file for the thing is legal to publish; feeding that blueprint into a milling machine is likely legal, though installing the result into your plinker may require a license. Similarly, you can publish blueprints for ethanol distillers, but making a still runs into (mis)regulated areas. (Curiously, regulated by the same folks who get excited over full-auto sears) But the human-readable bits are protected under this decision. This just occurred to me: while assembly-language mnemonics could be published, you couldn't publish the binary values (e.g., in an _inline) for them, although they are one-to-one. The very term "mnemonic" should tip the judges. Certain concepts, such as showing how to optimally use an instruction set, are best shown to others with assembly, no? The decision recognized that stuff that's mostly alphabetics and punctuation (vs. a block of hex codes) is OK online as it has been OK for paper. I don't think you could synthesize the DESCrack VHDL to some FPGA and publish the FPGA configuration file, but the VHDL can be published freely now, until the decision toggles again :-) >> Good code is more readable than legal prose to a non-lawyer. >To a non-programmer? I suspect that they're equally arcane. >Please feel free to present studies that show the contrary. Visit me around tax time :-( -DH
ADMIN: enough programming-as-communication...
I'm going to start ruthlessly trimming the programming thread shortly. .pm
Re: How to donate a clue to a lawyer?
At 10:39 AM -0700 5/8/99, Carl Ellison wrote: >Have you ever modified a program written by someone else? What's your first >step? You read the program, to find out what it does. You don't read the >massive paper document that describes what the program does and how .. >because there is no such document. You don't read the comments in the code >.. because there are lamentably few comments. Therefore, you read the >source code. My first system programming professor drove this point home >to us -- noting that even solitary projects require communication to some >"other" programmer: namely ourselves at a later date when we've forgotten >what was in our minds at the time we started writing the code. One of my favorite tricks for finding bugs in code that others wrote is to look for differences between the code and the comments. Of course source code is meant for human-to-human communication. There is so much in even uncommented code that machines can't understand. (Names, layout etc.) Look what happens to Java classes when you pass them through an obfusicator. Un-obfusicated Java might even qualify as source code because it has so much information that the computer can't understand. - Bill Frantz | Macintosh: Didn't do every-| Periwinkle -- Consulting (408)356-8506 | thing right, but did know | 16345 Englewood Ave. [EMAIL PROTECTED] | the century would end. | Los Gatos, CA 95032, USA
code
I have to utterly disagree with EKR. 1) I make substantial effort to make sure my code is readable. If the so-called programmers you know don't do that, well, so what? Every class I had when getting my degree drummed structured coding, comments and readability in to me. Maybe some coders don't do that, but many people can't write clear English either, and that doesn't make English not a language for humans to read. 2) Comments exist EXPLICITLY to communicate to humans. 3) free() is no less "for my benefit" than "char *foo". Sure, Java doesn't have free(). Lisp doesn't have "char *foo". "So what?" -- in different languages, there are different models of computation. Keeping track of memory in an algorithm is just as important as knowing what types are in certain models. Your example is completely specious. Source code exists for people first, computers second. If this were not the case, we'd all just write code in machine language. High level languages exist *explicitly* to make it easier for people to comprehend computation tasks. Communicating algorithms, both to the reader who is not the author, and later to the author of the code himself, is why we use high level languages. Maybe Mr. Rescorla doesn't believe it, but I do, and it is the doctrine taught in every decent CS curriculum in the world. Perry
Re: How to donate a clue to a lawyer?
At 02:26 PM 5/8/99 -0700, EKR wrote: > >If programmers though this way, they'd make an attempt to make their >source code readable, but by and large they don't. Um, are you talking your can't-yet-grow-a-moustache teenage "programmer" or an experienced person? Moreover, the >code (especially C code) is littered with constructs which serve >no communicative purpose but solely tell the computer what to do. Wrong. My mental model, when understanding code, involves what the compiler does when it reads what I read. "int i" causes me, and a compiler, to model a bit of (possibly implicitly initialized) state. If its Java I'm reading, there are assumptions about how it goes away, too. When you read any other recipe, similar world-assumptions are used. When making a cake, turn on the mixer for a minute. This implies things: that the blades will spin if its not broken, plugged in, and the power grid is working. No cookbook says this, but it is essential to understand the process being described. >(Memory management comes to mind as a prime example. The only >purpose of calling free() is to release memory. It serves no >expository purpose. It does! It tells the reader to forget about a thing, and to adjust the reader's estimation of max resource usage. This is clearly shown by the fact that >garbage collected languages do without it.) > >> Have you ever modified a program written by someone else? What's your first >> step? You read the program, to find out what it does. You don't read the >> massive paper document that describes what the program does and how .. >> because there is no such document. You don't read the comments in the code >> .. because there are lamentably few comments. Therefore, you read the >> source code. >Because it's your only choice. > >> My first system programming professor drove this point home >> to us -- noting that even solitary projects require communication to some >> "other" programmer: namely ourselves at a later date when we've forgotten >> what was in our minds at the time we started writing the code. >The very fact that you have to be taught this should make clear >that the actual purpose of code is instructing machines, not people. >People hardly ever forget that the purpose of writing text is >communication. > >> QED >Hardly. > >-Ekr Eric I hope you're just miffed about reading some lame code written by some quasi-literate who can't touchtype. Good code is more readable than legal prose to a non-lawyer. The snuffle excerpt was not a great example of this. "l" is not a great function name.
Re: How to donate a clue to a lawyer?
David Honig <[EMAIL PROTECTED]> writes: > At 02:26 PM 5/8/99 -0700, EKR wrote: > > > >If programmers though this way, they'd make an attempt to make their > >source code readable, but by and large they don't. > > Um, are you talking your can't-yet-grow-a-moustache teenage > "programmer" or an experienced person? I think that most people, even professional programmers, only make a marginal attempt to make their code readable, which is why most code is basically unreadable. > Moreover, the > >code (especially C code) is littered with constructs which serve > >no communicative purpose but solely tell the computer what to do. > > Wrong. My mental model, when understanding code, involves what > the compiler does when it reads what I read. "int i" causes > me, and a compiler, to model a bit of (possibly implicitly initialized) > state. If its Java I'm reading, there are assumptions about > how it goes away, too. I believe you're failing to distinguish the intentional purpose of code -- describing what you want done -- from the procedural purpose of code -- describing what in fact is to be done. This isn't surprising, given that no current language gives you the ability to actually communicate your intentions as opposed to the procedure. This is a bug, not a feature! If your purpose in using code is to communicate with other humans, what you want to communicate is intention with only the barest amount of procedure. However, in reality programs are almost all procedure with the barest amount of structure to attempt to communicate intention to humans who need to work on it. > Eric I hope you're just miffed about reading some lame > code written by some quasi-literate who can't touchtype. Nope. I'm a professional programmer with a realistic attitude about the situation. I'm not interested in making specious arguments about how software is speech merely to serve a political purpose -- even one I happen to agree with. > Good code is more readable than legal prose to a non-lawyer. To a non-programmer? I suspect that they're equally arcane. Please feel free to present studies that show the contrary. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]]
Re: How to donate a clue to a lawyer?
-BEGIN PGP SIGNED MESSAGE- At 02:26 PM 5/8/99 -0700, EKR wrote: >Carl Ellison <[EMAIL PROTECTED]> writes: >> Source code is human speech, for human-to-human communication. It has a >> side-effect of being compilable into machine code, but it is in a human >> language and is intended for human communication. >This strikes me as patently false. Feel free to be struck that way, but you haven't shaken my conviction. >If programmers though this way, they'd make an attempt to make their >source code readable, but by and large they don't. ...and they suffer for that oversight, later. They suffer because while they're programming they don't realize the purpose of the source code is not merely getting pigs to dance on screen but equally to communicate to the next human to read the code. >Moreover, the >code (especially C code) is littered with constructs which serve >no communicative purpose but solely tell the computer what to do. >(Memory management comes to mind as a prime example. The only >purpose of calling free() is to release memory. It serves no >expository purpose. This is clearly shown by the fact that >garbage collected languages do without it.) Of course the purpose of free() is to release computer, not human, memory. The reason it's readable (an English word, in fact -- as opposed to 0xB548976A) is so you and I can read it, however. The very fact that you used the construct free() in the middle of a sentence to me, I understood what you meant by it, and I could reply in kind, also using that construct, shows that that construct is an element of human-to-human communcation. No computer is going to execute that paragraph you wrote. Of course, I'm not saying that there is no other effect -- of getting pigs to dance on screen -- only that there is a human-to-human communication happening here. The Bernstein argument is that the human-to-human element of the communication deserves protection even if the human-to-computer communication is deemed harmful to national security. The former is more important than the latter. >> Have you ever modified a program written by someone else? What's your first >> step? You read the program, to find out what it does. You don't read the >> massive paper document that describes what the program does and how .. >> because there is no such document. You don't read the comments in the code >> .. because there are lamentably few comments. Therefore, you read the >> source code. >Because it's your only choice. The ACM articles I cited in my submission to the Bernstein case used source code as communication to humans, interspersed with text -- or sometimes instead of text -- because the subject of the communication was programming and source code was the most concise way to communicate the thought of the author to the mind of the reader. That's all Bernstein was trying to do with his source code postings. If all he wanted to do was let machines run code, he could have asked to post executables. He didn't. He was posting source code because of its human-to-human communicative value. Those ACM articles, BTW, (the ones that were all code) were required to compile and execute correctly, even though their declared intention was to communicate from human-to-human. >> My first system programming professor drove this point home >> to us -- noting that even solitary projects require communication to some >> "other" programmer: namely ourselves at a later date when we've forgotten >> what was in our minds at the time we started writing the code. >The very fact that you have to be taught this should make clear >that the actual purpose of code is instructing machines, not people. >People hardly ever forget that the purpose of writing text is >communication. People have to be taught how to write text. We're not born with the ability. >> QED >Hardly. Nope, still QED. - Carl -BEGIN PGP SIGNATURE- Version: PGP 6.5.1b15 iQCVAwUBNzUUkhN3Wx8QwqUtAQE2+wP9Go4W7oOc3rbgNwBdStUd8wSPdIBseNLs zbCjGuZucEvpYE/ObgXGgn03BNcgSCi2G1Qpcjv4hQ11FgIbzknNAX0FC30PC/r+ L0xQLW5wUQqXJfuWiwsYou0XqsmpdxvapTpM1Wqpbdn9qlKaK9TWDLmVUQ7yRcc7 lgtaqEUdimg= =97LH -END PGP SIGNATURE- +--+ |Carl M. Ellison [EMAIL PROTECTED] http://www.pobox.com/~cme | |PGP: 08FF BA05 599B 49D2 23C6 6FFD 36BA D342 | +--Officer, officer, arrest that man. He's whistling a dirty song.-+
