"For centuries, people have been sharing cultural performances without much upset from the artists and producers."
They started to get very upset about it when automated large scale distribution mechanisms permitted the owners of said mechanisms to profit from selling multiple copies of works without giving the authors anything. Britain's Statute of Anne enacted the first real copyright act in 1709 to remedy this situation after constant lobbying by writers, cartographers, and artists, and it was very much like modern ones, i.e. the author or artist maintained rights to his or her work for a certain period, after which they entered the public domain.
"so people do what they have done for years, and that suddenly means it's time to sue everyone and his brother for copyright violations?"
In 2009, copyright will have its 300th birthday, which means that people will than have been suing others for copyright violation for three centuries. Thus, the response today is precisely what it was "for years", i.e. copyright violators run the risk of getting sued for it.
Where did I mention CDs? I said that sales of _recorded music_ have dropped steadily since 1999, and recorded music clearly includes downloadable content.
"So, it is not that people have stopped purchasing music, it is just that they have switched to a different medium."
I suggest you check some statistics before making claims like this one. Digital downloads rose by 40% during 2007, but this was not enough to offset the decline in CD sales, so the overall market for recorded music fell by 10% in terms of units sold (revenue fell a lot more due to the fact that people tend to buy songs online rather than albums).
"So it is not that peopel have stopped purchasing their products"
The entire market for recorded music is about half of what it was in 1999-2000, which means, as I said, that significant numbers of people have stopped purchasing their products (while some of course may be continuing to purchase them less often).
NB: 1999 was a peak year that may well have helped considerably by baby boomers buying CD versions of content they already had on vinyl or tape.
"Ehm, I don't know how old you are, but both Netscape and Opera were always 'free'"
The first releases of Netscape had both evaluation and commercial versions. Evaluation versions were identified by an "N" suffix (e.g. 1.1N), and were only supposed to be used for trial purposes, after which one was expected to pay for a commercial license.
"I agree with you that people should revolt against the RIAA and stop purchasing their products. But people wont."
Recorded music sales have declined drastically all over the world during the last few years, so it's obvious that significant numbers of people _have_ stopped purchasing their products, although revolts against the media industry are probably not one of the significant contributing factors.
And also quite wrong. The retail price of $15 includes both wholesaler and dealer mark-ups, which account for at least 50% of it, so the gross amount that the music company gets is about $7.50 a copy. This does of course assume that they've manufactured a CD, and and it's sitting around in a warehouse or on a dealer's shelf because "pirates" have stopped people from buying it. If this isn't the case, then they aren't paying manufacturing, storage, and distribution costs, which are factored into that $7.50, so the IP alone on the CD is worth about $6 (I'm being generous here), and IP is what they claim the "pirates" are "stealing".
"If Hitler hadn't killed and chased away the Jews, some of whom were gifted scientists, they might stayed in Germany and made him an atom bomb."
Instead of going to America, telling its government that the Germans were making atom bombs anyway, and getting huge allocations of resources to start a project for making atom bombs.
TV companies in most of the world regard "piracy" as a threat to their own sources of revenue, so the fact that they transmit advertising for their own viewpoint disguised as news shouldn't surprise you or anyone else.
It depends what you mean by "the EU". Precedents aren't set by judicial decisions in the European Courts of Justice (ECJ), although it's fairly common for them to refer to prior decisions when making new ones. Not all EU member states operate in the same way however, with the UK for example still using their venerable precedent-driven Common Law that the US legal system is based on.
"the best way to avoid the BSA is to stop being a Microsoft customer"
Microsoft are far from being the only member of the BSA, so simply steering clear of MS software won't be enough -- people will also have to avoid using anything by the others on the BSA's member list:
""Something that understands Prolog", sure, but that need not be a Prolog interpreter. A number of compiled languages can add bits built from of arbitrary source code at runtime using something that "understands" the language -- a compiler. Off the top of my head, Erlang, C#, Mozart/Oz, newer releases of Java, and some Common Lisp implementations each have some mechanism to do this."
They have mechanisms for allowing pre-written pieces of code to replace other pre-written pieces of code, but a fundamental aspect of Prolog is its support for programs that can "learn" by modifying themselves while they're running. Supporting this with a static compiler would be non-trivial, because it's not always possible to predict when the backward-chaining inference engine will modify something, and what effect that this will have on the rest of the system, because each modification has the potential to make other modifications, which may in their turn modify something else, and so on, thus producing a situation where the system could become bogged down with multiple successive compilations of the rule database, with a consequent and possibly severe degradation in runtime performance. One could solve this problem with a dynamic compiler that only compiles the changed sections when it needs to use them (and there may well be Prolog systems that do this nowadays), but the difference between a dynamic compiler and an interpreter are a subject of much debate, so it would be possible to claim that such a system was interpreted, compiled, or both without being entirely right or wrong.
"That seems to rest on a fairly narrow definition of what isn't an interpreter, but its not like there is a real concrete divide between interpretation and compilation; its certainly more of a continuum."
It is now, because etymologically challenged people have muddied the waters by using both terms far more loosely than used to be the case. "Compiler" and "interpreter" are both English words that, like "editor", "command line", "memory", "kernel", "floppy disk" and a whole host of other terms "stuck" because most people in computing at the time agreed that they were a pretty good description of whatever they were being applied to (most of the more venerable ones had several alternative names that have now largely fallen into disuse -- "translator" for example was an early synonym for "compiler"). Compilers are people who incorporate a series of existing _written_ works into a new one by analysing, organising, annotating, and where necessary, translating the originals; while interpreters act as intermediaries in conversations between parties who understand different languages, translating what each of them is saying in small, sequential sections which permit the conversation to actually be a conversation, albeit one that's somewhat slower than would be the case if both parties spoke the same language, and therefore didn't require an interpreter.
There have been a variety of architectures that use static compilers to produce intermediate code which is then run by an interpreter, some of which date back to the late 1950s. We would now describe some of those interpreters as "virtual machines", but that wasn't what their designers called them, because in those days they applied the "if it walks like a duck and quacks like a duck..." test, so the USCD P-Code system for example used what they called a "P-Code interpreter", which various languages used static compilers to generate code for. It's also important to note that there have been many compilers written to target a high-level language rather than a virtual machine, and some of these high level languages have been interpreted ones, e.g. several that were meant for early home computers which output source for the particular dialect of BASIC that shipped in their ROMs.
Which brings us to the point of whether a static compiler that's part of an interpreter's run-time system, and must be invoked on source code before any interpreting can begin, ceases to be a static compiler when
"Those are really my points. I wasn't speaking out against religion, just responding to the parent's argument that "When religion doesn't get it right, people abandon it completely." Obviously religion has changed over the centuries when it has gotten things wrong or even just as attitudes change in society."
And many religions or sects of religions have been pretty easy-going from the beginning, leaving the decision of whether to follow their beliefs to each individual rather than trying to force everyone to conform. Buddhists, Quakers, and various types of Sufi Muslims come to mind here, but they're far from being unique in this respect.
""I fail to see where anything in my reply mentioned, or was in any way applicable to paper ballots.""
"Here it is: "printed audit trail". If it's not printed on paper then what is it printed on?"
You are either a troll, or simply too dense to realise the difference between a paper ballot (unprocessed input) and an audit trail (processed output). Neither possibility is worth wasting any more time on.
"Um, so? Lots of compiled languages can "change their behavior" at runtime by rebinding variables, or even, in some cases, updating running code. Nothing about that behavior is inconsistent with a compiled implementation, and most prolog implementations that aren't toys (and many that are) are compilers."
I find it difficult to see what point you're trying to make here, because the phrase you quote was followed by:
"There have been compiled versions, but they've either required compromises to the nature of the language (e.g. being able to assert facts (data) but not rules (code) at run-time), or include what amounts to a full Prolog interpreter to handle run-time rule assertions, so they can at best be described as partially compiled versions."
Your reply also displays the fact that you don't know much about Prolog, otherwise you wouldn't be making comments about re-binding variables or updating running code. A Prolog dynamic rule assertion is a piece of _Prolog source code_ of arbitrary complexity that is added at run-time to the database (this is an internal Prolog construct, not a RDBMS, although some implementations support using a RDBMS as a persistent rule store). Code written in Prolog obviously requires something capable of "understanding" Prolog to be useful, hence the fact that compiled Prologs typically include some sort of Prolog interpreter in either the compiled code itself or its run-time support system. If implementing the full Prolog language requires an interpreter at some point, then it's fair to say that Prolog itself was specifically designed to take advantage of certain features that interpreted environments offer.
"How does that make it ill-suited to running in an interpreted environment? It certainly would require a two-pass interpreter that seperates analysis from execution, but that's not an uncommon interpreter design."
The term "ill-suited" does not equate to "impossible". Note also that an interpreter which requires two or more passes of the source for _an entire software system_ before it can start doing its job (i.e. interpreting) would be more correctly described as a VM whose input is derived from an in-memory compiler, because even insignificant changes to any part of that source will require re-compiling all of it.
NB: there have in fact been several Eiffel interpreters, but they tend to leave out the global analysis bits, so although some can handle most Eiffel syntax, they're semantically only subsets of the Eiffel language specification (although to be fair, this has also been the case with some compilers).
"There is no such thing as a set of rules that cannot be described as a single rule consisting of sub-rules."
Many of the things humans have done unto each other could more properly be summed up as "Do unto others before the thought of doing unto you has even occurred to them".
"The Catholic church that chose the four stories to make up the new testament out of the sixteen or so there were"
There were actually something like 200 gospels, a large number of which have disappeared, although I would hesitate to say that this is a permanent state of affairs, because some of them turn up in unexpected places now and then (albeit often in the form of fragments from which key parts are missing). Note also that various New Testament apocrypha, despite not having the same deuterocanonical status as some old testament apocrypha, have influenced the beliefs of many Catholics, and indeed non-Catholic Christians (e.g. the idea that three kings with specific names brought gifts, when neither the official cannon gospels or the Church say how many there were, or that they were kings, or give any of them names).
"Religious has someone telling you something or reading a 2,000 year old book written by people that are long dead and that contradicts itself in many places and says to assume that it is all true and go from there."
Only a small minority of Christians are fundamentalists who take everything in the Bible literally, and most of them seem to live in the US. Ranged against them are Catholics, Anglicans, Baptists, Presbyterians, Quakers, and bunch of others who accept the general scientific consensus about the age of the universe and the Earth, evolution, and are in many cases just as concerned and disturbed as atheists about attempts to get Creationism taught in school science classes. If you doubt that this is so, then check out this link, which is the official position of Presbyterians on what's currently going on: http://www.don-lindsay-archive.org/creation/voices/RELIGIOU/PRES82.htm
"Religion has therefore changed instead of being abandoned, as recent popes' concessions that evolution is not incompatible with religion and Pope Gregory XIII in 1580 saying that the earth was created in 5199 BCE."
It wasn't an unreasonable thing to say in 1580, when much of what passed for "science" was silly balderdash that made some of the things religios believed look like the last word in rationalism.
"So religion must change in light of newly discovered facts to avoid having its followers choose between leaving or looking like an idiot."
Two observations:
1) Religious fundamentalism has experienced massive growth in the US during the 20th and early 21st centuries. This is also the period when the US moved from being a technological, political, and economic also-ran to a world superpower in all of these areas, largely as a result of its scientific and technological excellence.
2) Bishops wouldn't walk around in funny hats and dresses if religious people really cared whether others thought they looked like idiots.
NB: before you make any unwarranted assumptions about me, I am an agnostic, not a Christian.
The Berne Convention is international. The fact that it was originally signed in Switzerland doesn't make it European any more than the Kyoto Convention was Japanese just because Kyoto happens to be in Japan.
It will save time and paper by not bothering to print out something that contains exactly the same "errors" that the machine has already incorporated in its data.
"At least with paper ballots someone can call for a hand count of the ballots."
I fail to see where anything in my reply mentioned, or was in any way applicable to paper ballots.
You appear to be suffering from Rose Tinted Nostalgia Syndrome, the most obvious symptom of which is an insistence that everything was better "in the old days", including people, who were invariably more honest, intelligent, and capable than today's lamentable horde of thieving, lying, know-nothing dross.
"Nah, it was nowhere near like that. People knew the commands because they had to use them every time they wanted to install software."
Most DOS software had automated installers that required nothing more complex than typing "A:INSTALL", which the user manual told them to type. Systems without hard-disks didn't even need that much -- the manuals told users how to back up the floppy, and they'd run the software off the backup disk by sticking it in the drive and typing the program's name. Not that the majority of users were capable even of this, so people like me made lots of lovely money setting up text menus that were called from AUTOEXEC.BAT (or PROFILE.SUB on CP/M), and allowed them to launch the two or three applications they were interested in by typing a one digit number.
These supposedly technically adept DOS users also had some interesting practices for managing 51/4" floppies, such as stapling them together, punching holes through them so they wouldn't fall out of clip spine folders, folding them up before storing or mailing them, thinking that "send me a copy of the disk" meant that one wanted a photocopy of it, and taking the round brown bit out of the square black part "because it makes a funny scraping noise when it goes round and round".
"Actually when I first learned of it in the late 70's I thought Pascal was a pretty cool and powerful language."
Being specifically designed for teaching structured programming concepts doesn't preclude a language from being powerful.
"At that time, Fortran IV was probably the language most people learned first (BASIC was starting to take hold too...)."
Wirth's goal with Pascal was to instil an awareness of structure in students who would be likely to spend their careers writing COBOL and FORTRAN code. His first successful implementation was in 1970 for a mainframe, and it was extremely rare in those days to find a high-level language other than COBOL or FORTRAN on any computer outside research establishments, so it was natural for him to assume that most of those who learned Pascal would end up coding in one of them.
"So in the context of the time, Pascal was (and still is) a perfectly reasonable general-purpose programming language. Maybe the general-purposeness of it might have hurt it more than anything else - it never was the best at anything (except perhaps enforced readability)"
Wirth Pascal had a number of deliberate restrictions that prevented it from being a practical vehicle for commercial software development. I suggest you read Brian Kernighan's criticism of it (when compared to his and Ritchie's C) for a reasonable overview of them that might help you understand why many programmers disliked it. You can find it at (among many other places) http://www.lysator.liu.se/c/bwk-on-pascal.html
NB: this is a fairly old paper, so most of the criticisms don't apply to modern Pascals such as FreePascal, which have been influenced by more practical implementations from the likes of Borland and Apple that specifically targeted applications programmers, and therefore both removed some of the restrictions that were only desirable from a didactic viewpoint, and clearly defined certain aspects of Pascal that were either not defined or ambiguous in the original specification.
On a final note, I much preferred both Modula-2 and the later Oberon to C or Pascal, but neither of them managed to gain much of a foothold in the industry despite the fact that both had amply demonstrated their capabilities as both systems and applications programming languages whilst at the same time managing to avoid many of C's pitfalls.
"I can't see how you could misread that, since the specific example was outputting "Hello, World" via System.out.println()."
If this was the only thing you'd taken issue with about Java, then I would agree that I'd misread things. Your original post did not however restrict itself to a criticism of this aspect of a simple Java program.
""interpreted" isn't a feature of languages, but of implementations."
This isn't necessarily the case, because some languages are specifically designed for an interpreted environment. One example is Prolog, which has the ability to modify its behaviour at run-time by asserting new rules into its internal database. There have been compiled versions, but they've either required compromises to the nature of the language (e.g. being able to assert facts (data) but not rules (code) at run-time), or include what amounts to a full Prolog interpreter to handle run-time rule assertions, so they can at best be described as partially compiled versions. The other side of the coin would be represented by Eiffel for example, which requires global code analysis for some of its design-by-contract features, and is therefore ill suited to running in an interpreted environment.
"whether bytecode run on a VM is "interpreted" or "compiled"--or both--is a side topic, though it relates to which side of that fence Java should be considered on, as well."
A VM is neither more nor less an interpreter than a CPU is an interpreter. As for Java the language, it's most definitely compiled (or at least the most common implementations are compiled), because "javac" is used to convert source files into files containing op codes for the VM, which cannot in itself execute the Java language any more than current hardware CPUs can execute C or BASIC source code. There are however a number of other languages for the Java VM which use interpreted environments, so Java the language is an option with Java the VM, not a requirement.
"Using the broad use of I/O that you have no clarified that you were using (which makes your original criticism misplaced with regard to the post it responded to)"
This would be true if your original criticism of the Java fragment only dealt with the bit between the braces, and my initial response also restricted itself to the bit between the curly braces. I suggest therefore that you read both your original post, and my initial response again to see why neither you nor I addressed only that part of the example you used.
"its not less generally applicable than yours, since a rule need not be simple; a compound rule composed of other rules can still be described as "a rule"a rule need not be simple; a compound rule composed of other rules can still be described as "a rule"
There are many programs that perform a variety of unrelated tasks, and cannot therefore be described by a single rule consisting of sub-rules. iTunes is an excellent example, because in addition to managing media files (a rule), it can also be used to register iPhones with a cellular telecommunications service provider (a completely different rule that isn't a sub-rule of the managing media files rule).
"At worst, I'll just break out the road atlas and plan a route that avoids toll roads if the tolls prove particularly onerous. As we say on FARK: I'll get over it."
A lot of people use alternate routes to avoid the worst traffic jams now, so it's probably true to say that there are a fair number sitting in such jams around the world who do so because they can't be bothered to find another way of getting where they want to go. If these new toll systems make at least some of those who could do so take another route, then they'll have helped to decrease congestion on the main arteries where they're being applied, thereby making life just a little bit better (although more expensive) for the people who have no other viable ways of reaching their destinations.
"Programs that perform I/O are inherently not "simple" programs--now, I/O is a requirement for useful programs, and might be pedagogically useful at an early stage to give people a feeling of making the computer "do something" productive, but its not simple, and it isn't central to understanding computing or program design"
I think you're misunderstanding what I mean by I/O. My use of the term is a generic one which does not imply any form of I/O devices, but refers instead to the fact that all meaningful processes (i.e. ones that do more than consume CPU time with empty loops) operate on data which can be described as an input to the process itself, and a result which is the process's output. Both input and output could therefore quite easily be (for example) a single variable that acts as both a data source (input) and data sink (output) for a process. This is such a fundamental concept that any course which doesn't teach students to think of data and processes in this way from the outset is failing to do it's job.
"The structure of Java (this is true of C and Pascal as well, though to a slightly lesser extent) programs inherently is not "simple", it involves lots of overhead."
Agreed. I've said elsewhere in this topic that I favour interpreted languages as vehicles for teaching very basic concepts precisely because they have little or no overhead, and I include things such as having to handle files and compilation phases in my definition of overhead that beginners shouldn't be distracted with.
"I prefer HtDP's description: "[A program] is a rule that tells us and the computer how to produce data from some other data.""
I fail to see where this is semantically different from my definition in any way that doesn't make it less generally applicable (e.g. "processes" can clearly include an arbitrary number of rules, whereas "a rule" implies that programs can only have one of them).
Slashdot Mirror
"For centuries, people have been sharing cultural performances without much upset from the artists and producers."
They started to get very upset about it when automated large scale distribution mechanisms permitted the owners of said mechanisms to profit from selling multiple copies of works without giving the authors anything. Britain's Statute of Anne enacted the first real copyright act in 1709 to remedy this situation after constant lobbying by writers, cartographers, and artists, and it was very much like modern ones, i.e. the author or artist maintained rights to his or her work for a certain period, after which they entered the public domain.
"so people do what they have done for years, and that suddenly means it's time to sue everyone and his brother for copyright violations?"
In 2009, copyright will have its 300th birthday, which means that people will than have been suing others for copyright violation for three centuries. Thus, the response today is precisely what it was "for years", i.e. copyright violators run the risk of getting sued for it.
"While CD sales are down, MP3 sales are up."
Where did I mention CDs? I said that sales of _recorded music_ have dropped steadily since 1999, and recorded music clearly includes downloadable content.
"So, it is not that people have stopped purchasing music, it is just that they have switched to a different medium."
I suggest you check some statistics before making claims like this one. Digital downloads rose by 40% during 2007, but this was not enough to offset the decline in CD sales, so the overall market for recorded music fell by 10% in terms of units sold (revenue fell a lot more due to the fact that people tend to buy songs online rather than albums).
"So it is not that peopel have stopped purchasing their products"
The entire market for recorded music is about half of what it was in 1999-2000, which means, as I said, that significant numbers of people have stopped purchasing their products (while some of course may be continuing to purchase them less often).
NB: 1999 was a peak year that may well have helped considerably by baby boomers buying CD versions of content they already had on vinyl or tape.
"Ehm, I don't know how old you are, but both Netscape and Opera were always 'free'"
The first releases of Netscape had both evaluation and commercial versions. Evaluation versions were identified by an "N" suffix (e.g. 1.1N), and were only supposed to be used for trial purposes, after which one was expected to pay for a commercial license.
"That's why no one really care aboot the RIAA"
Politicians care about them, just like they care about everyone who gives lots of money to politicians.
"I agree with you that people should revolt against the RIAA and stop purchasing their products. But people wont."
Recorded music sales have declined drastically all over the world during the last few years, so it's obvious that significant numbers of people _have_ stopped purchasing their products, although revolts against the media industry are probably not one of the significant contributing factors.
"$15 * 100,000 = $1.5 million. Quite simple, really."
And also quite wrong. The retail price of $15 includes both wholesaler and dealer mark-ups, which account for at least 50% of it, so the gross amount that the music company gets is about $7.50 a copy. This does of course assume that they've manufactured a CD, and and it's sitting around in a warehouse or on a dealer's shelf because "pirates" have stopped people from buying it. If this isn't the case, then they aren't paying manufacturing, storage, and distribution costs, which are factored into that $7.50, so the IP alone on the CD is worth about $6 (I'm being generous here), and IP is what they claim the "pirates" are "stealing".
"If Hitler hadn't killed and chased away the Jews, some of whom were gifted scientists, they might stayed in Germany and made him an atom bomb."
Instead of going to America, telling its government that the Germans were making atom bombs anyway, and getting huge allocations of resources to start a project for making atom bombs.
"Secularist movements have had their warts too -- eugenics, Stalin's gulags, the Cultural Revolution, etc."
And their own forms of religious dogma that must be read and memorised by the faithful, e.g. Mein Kampf and The Thoughts Of Chairman Mao.
"That's on a *public* TV."
TV companies in most of the world regard "piracy" as a threat to their own sources of revenue, so the fact that they transmit advertising for their own viewpoint disguised as news shouldn't surprise you or anyone else.
It depends what you mean by "the EU". Precedents aren't set by judicial decisions in the European Courts of Justice (ECJ), although it's fairly common for them to refer to prior decisions when making new ones. Not all EU member states operate in the same way however, with the UK for example still using their venerable precedent-driven Common Law that the US legal system is based on.
"the best way to avoid the BSA is to stop being a Microsoft customer"
Microsoft are far from being the only member of the BSA, so simply steering clear of MS software won't be enough -- people will also have to avoid using anything by the others on the BSA's member list:
http://www.bsa.org/country/BSA%20and%20Members/Our%20Members.aspx
""Something that understands Prolog", sure, but that need not be a Prolog interpreter. A number of compiled languages can add bits built from of arbitrary source code at runtime using something that "understands" the language -- a compiler. Off the top of my head, Erlang, C#, Mozart/Oz, newer releases of Java, and some Common Lisp implementations each have some mechanism to do this."
They have mechanisms for allowing pre-written pieces of code to replace other pre-written pieces of code, but a fundamental aspect of Prolog is its support for programs that can "learn" by modifying themselves while they're running. Supporting this with a static compiler would be non-trivial, because it's not always possible to predict when the backward-chaining inference engine will modify something, and what effect that this will have on the rest of the system, because each modification has the potential to make other modifications, which may in their turn modify something else, and so on, thus producing a situation where the system could become bogged down with multiple successive compilations of the rule database, with a consequent and possibly severe degradation in runtime performance. One could solve this problem with a dynamic compiler that only compiles the changed sections when it needs to use them (and there may well be Prolog systems that do this nowadays), but the difference between a dynamic compiler and an interpreter are a subject of much debate, so it would be possible to claim that such a system was interpreted, compiled, or both without being entirely right or wrong.
"That seems to rest on a fairly narrow definition of what isn't an interpreter, but its not like there is a real concrete divide between interpretation and compilation; its certainly more of a continuum."
It is now, because etymologically challenged people have muddied the waters by using both terms far more loosely than used to be the case. "Compiler" and "interpreter" are both English words that, like "editor", "command line", "memory", "kernel", "floppy disk" and a whole host of other terms "stuck" because most people in computing at the time agreed that they were a pretty good description of whatever they were being applied to (most of the more venerable ones had several alternative names that have now largely fallen into disuse -- "translator" for example was an early synonym for "compiler"). Compilers are people who incorporate a series of existing _written_ works into a new one by analysing, organising, annotating, and where necessary, translating the originals; while interpreters act as intermediaries in conversations between parties who understand different languages, translating what each of them is saying in small, sequential sections which permit the conversation to actually be a conversation, albeit one that's somewhat slower than would be the case if both parties spoke the same language, and therefore didn't require an interpreter.
There have been a variety of architectures that use static compilers to produce intermediate code which is then run by an interpreter, some of which date back to the late 1950s. We would now describe some of those interpreters as "virtual machines", but that wasn't what their designers called them, because in those days they applied the "if it walks like a duck and quacks like a duck..." test, so the USCD P-Code system for example used what they called a "P-Code interpreter", which various languages used static compilers to generate code for. It's also important to note that there have been many compilers written to target a high-level language rather than a virtual machine, and some of these high level languages have been interpreted ones, e.g. several that were meant for early home computers which output source for the particular dialect of BASIC that shipped in their ROMs.
Which brings us to the point of whether a static compiler that's part of an interpreter's run-time system, and must be invoked on source code before any interpreting can begin, ceases to be a static compiler when
"Those are really my points. I wasn't speaking out against religion, just responding to the parent's argument that "When religion doesn't get it right, people abandon it completely." Obviously religion has changed over the centuries when it has gotten things wrong or even just as attitudes change in society."
And many religions or sects of religions have been pretty easy-going from the beginning, leaving the decision of whether to follow their beliefs to each individual rather than trying to force everyone to conform. Buddhists, Quakers, and various types of Sufi Muslims come to mind here, but they're far from being unique in this respect.
""I fail to see where anything in my reply mentioned, or was in any way applicable to paper ballots.""
"Here it is: "printed audit trail". If it's not printed on paper then what is it printed on?"
You are either a troll, or simply too dense to realise the difference between a paper ballot (unprocessed input) and an audit trail (processed output). Neither possibility is worth wasting any more time on.
"Um, so? Lots of compiled languages can "change their behavior" at runtime by rebinding variables, or even, in some cases, updating running code. Nothing about that behavior is inconsistent with a compiled implementation, and most prolog implementations that aren't toys (and many that are) are compilers."
I find it difficult to see what point you're trying to make here, because the phrase you quote was followed by:
"There have been compiled versions, but they've either required compromises to the nature of the language (e.g. being able to assert facts (data) but not rules (code) at run-time), or include what amounts to a full Prolog interpreter to handle run-time rule assertions, so they can at best be described as partially compiled versions."
Your reply also displays the fact that you don't know much about Prolog, otherwise you wouldn't be making comments about re-binding variables or updating running code. A Prolog dynamic rule assertion is a piece of _Prolog source code_ of arbitrary complexity that is added at run-time to the database (this is an internal Prolog construct, not a RDBMS, although some implementations support using a RDBMS as a persistent rule store). Code written in Prolog obviously requires something capable of "understanding" Prolog to be useful, hence the fact that compiled Prologs typically include some sort of Prolog interpreter in either the compiled code itself or its run-time support system. If implementing the full Prolog language requires an interpreter at some point, then it's fair to say that Prolog itself was specifically designed to take advantage of certain features that interpreted environments offer.
"How does that make it ill-suited to running in an interpreted environment? It certainly would require a two-pass interpreter that seperates analysis from execution, but that's not an uncommon interpreter design."
The term "ill-suited" does not equate to "impossible". Note also that an interpreter which requires two or more passes of the source for _an entire software system_ before it can start doing its job (i.e. interpreting) would be more correctly described as a VM whose input is derived from an in-memory compiler, because even insignificant changes to any part of that source will require re-compiling all of it.
NB: there have in fact been several Eiffel interpreters, but they tend to leave out the global analysis bits, so although some can handle most Eiffel syntax, they're semantically only subsets of the Eiffel language specification (although to be fair, this has also been the case with some compilers).
"There is no such thing as a set of rules that cannot be described as a single rule consisting of sub-rules."
I concede this point.
"Do unto others before they do unto you."
Many of the things humans have done unto each other could more properly be summed up as "Do unto others before the thought of doing unto you has even occurred to them".
"The Catholic church that chose the four stories to make up the new testament out of the sixteen or so there were"
There were actually something like 200 gospels, a large number of which have disappeared, although I would hesitate to say that this is a permanent state of affairs, because some of them turn up in unexpected places now and then (albeit often in the form of fragments from which key parts are missing). Note also that various New Testament apocrypha, despite not having the same deuterocanonical status as some old testament apocrypha, have influenced the beliefs of many Catholics, and indeed non-Catholic Christians (e.g. the idea that three kings with specific names brought gifts, when neither the official cannon gospels or the Church say how many there were, or that they were kings, or give any of them names).
"Religious has someone telling you something or reading a 2,000 year old book written by people that are long dead and that contradicts itself in many places and says to assume that it is all true and go from there."
Only a small minority of Christians are fundamentalists who take everything in the Bible literally, and most of them seem to live in the US. Ranged against them are Catholics, Anglicans, Baptists, Presbyterians, Quakers, and bunch of others who accept the general scientific consensus about the age of the universe and the Earth, evolution, and are in many cases just as concerned and disturbed as atheists about attempts to get Creationism taught in school science classes. If you doubt that this is so, then check out this link, which is the official position of Presbyterians on what's currently going on: http://www.don-lindsay-archive.org/creation/voices/RELIGIOU/PRES82.htm
"Religion has therefore changed instead of being abandoned, as recent popes' concessions that evolution is not incompatible with religion and Pope Gregory XIII in 1580 saying that the earth was created in 5199 BCE."
It wasn't an unreasonable thing to say in 1580, when much of what passed for "science" was silly balderdash that made some of the things religios believed look like the last word in rationalism.
"So religion must change in light of newly discovered facts to avoid having its followers choose between leaving or looking like an idiot."
Two observations:
1) Religious fundamentalism has experienced massive growth in the US during the 20th and early 21st centuries. This is also the period when the US moved from being a technological, political, and economic also-ran to a world superpower in all of these areas, largely as a result of its scientific and technological excellence.
2) Bishops wouldn't walk around in funny hats and dresses if religious people really cared whether others thought they looked like idiots.
NB: before you make any unwarranted assumptions about me, I am an agnostic, not a Christian.
The Berne Convention is international. The fact that it was originally signed in Switzerland doesn't make it European any more than the Kyoto Convention was Japanese just because Kyoto happens to be in Japan.
"How will not having an audit trail help?"
It will save time and paper by not bothering to print out something that contains exactly the same "errors" that the machine has already incorporated in its data.
"At least with paper ballots someone can call for a hand count of the ballots."
I fail to see where anything in my reply mentioned, or was in any way applicable to paper ballots.
You appear to be suffering from Rose Tinted Nostalgia Syndrome, the most obvious symptom of which is an insistence that everything was better "in the old days", including people, who were invariably more honest, intelligent, and capable than today's lamentable horde of thieving, lying, know-nothing dross.
"Nah, it was nowhere near like that. People knew the commands because they had to use them every time they wanted to install software."
Most DOS software had automated installers that required nothing more complex than typing "A:INSTALL", which the user manual told them to type. Systems without hard-disks didn't even need that much -- the manuals told users how to back up the floppy, and they'd run the software off the backup disk by sticking it in the drive and typing the program's name. Not that the majority of users were capable even of this, so people like me made lots of lovely money setting up text menus that were called from AUTOEXEC.BAT (or PROFILE.SUB on CP/M), and allowed them to launch the two or three applications they were interested in by typing a one digit number.
These supposedly technically adept DOS users also had some interesting practices for managing 51/4" floppies, such as stapling them together, punching holes through them so they wouldn't fall out of clip spine folders, folding them up before storing or mailing them, thinking that "send me a copy of the disk" meant that one wanted a photocopy of it, and taking the round brown bit out of the square black part "because it makes a funny scraping noise when it goes round and round".
"Actually when I first learned of it in the late 70's I thought Pascal was a pretty cool and powerful language."
Being specifically designed for teaching structured programming concepts doesn't preclude a language from being powerful.
"At that time, Fortran IV was probably the language most people learned first (BASIC was starting to take hold too...)."
Wirth's goal with Pascal was to instil an awareness of structure in students who would be likely to spend their careers writing COBOL and FORTRAN code. His first successful implementation was in 1970 for a mainframe, and it was extremely rare in those days to find a high-level language other than COBOL or FORTRAN on any computer outside research establishments, so it was natural for him to assume that most of those who learned Pascal would end up coding in one of them.
"So in the context of the time, Pascal was (and still is) a perfectly reasonable general-purpose programming language. Maybe the general-purposeness of it might have hurt it more than anything else - it never was the best at anything (except perhaps enforced readability)"
Wirth Pascal had a number of deliberate restrictions that prevented it from being a practical vehicle for commercial software development. I suggest you read Brian Kernighan's criticism of it (when compared to his and Ritchie's C) for a reasonable overview of them that might help you understand why many programmers disliked it. You can find it at (among many other places) http://www.lysator.liu.se/c/bwk-on-pascal.html
NB: this is a fairly old paper, so most of the criticisms don't apply to modern Pascals such as FreePascal, which have been influenced by more practical implementations from the likes of Borland and Apple that specifically targeted applications programmers, and therefore both removed some of the restrictions that were only desirable from a didactic viewpoint, and clearly defined certain aspects of Pascal that were either not defined or ambiguous in the original specification.
On a final note, I much preferred both Modula-2 and the later Oberon to C or Pascal, but neither of them managed to gain much of a foothold in the industry despite the fact that both had amply demonstrated their capabilities as both systems and applications programming languages whilst at the same time managing to avoid many of C's pitfalls.
"I can't see how you could misread that, since the specific example was outputting "Hello, World" via System.out.println()."
If this was the only thing you'd taken issue with about Java, then I would agree that I'd misread things. Your original post did not however restrict itself to a criticism of this aspect of a simple Java program.
""interpreted" isn't a feature of languages, but of implementations."
This isn't necessarily the case, because some languages are specifically designed for an interpreted environment. One example is Prolog, which has the ability to modify its behaviour at run-time by asserting new rules into its internal database. There have been compiled versions, but they've either required compromises to the nature of the language (e.g. being able to assert facts (data) but not rules (code) at run-time), or include what amounts to a full Prolog interpreter to handle run-time rule assertions, so they can at best be described as partially compiled versions. The other side of the coin would be represented by Eiffel for example, which requires global code analysis for some of its design-by-contract features, and is therefore ill suited to running in an interpreted environment.
"whether bytecode run on a VM is "interpreted" or "compiled"--or both--is a side topic, though it relates to which side of that fence Java should be considered on, as well."
A VM is neither more nor less an interpreter than a CPU is an interpreter. As for Java the language, it's most definitely compiled (or at least the most common implementations are compiled), because "javac" is used to convert source files into files containing op codes for the VM, which cannot in itself execute the Java language any more than current hardware CPUs can execute C or BASIC source code. There are however a number of other languages for the Java VM which use interpreted environments, so Java the language is an option with Java the VM, not a requirement.
"Using the broad use of I/O that you have no clarified that you were using (which makes your original criticism misplaced with regard to the post it responded to)"
This would be true if your original criticism of the Java fragment only dealt with the bit between the braces, and my initial response also restricted itself to the bit between the curly braces. I suggest therefore that you read both your original post, and my initial response again to see why neither you nor I addressed only that part of the example you used.
"its not less generally applicable than yours, since a rule need not be simple; a compound rule composed of other rules can still be described as "a rule"a rule need not be simple; a compound rule composed of other rules can still be described as "a rule"
There are many programs that perform a variety of unrelated tasks, and cannot therefore be described by a single rule consisting of sub-rules. iTunes is an excellent example, because in addition to managing media files (a rule), it can also be used to register iPhones with a cellular telecommunications service provider (a completely different rule that isn't a sub-rule of the managing media files rule).
"At worst, I'll just break out the road atlas and plan a route that avoids toll roads if the tolls prove particularly onerous. As we say on FARK: I'll get over it."
A lot of people use alternate routes to avoid the worst traffic jams now, so it's probably true to say that there are a fair number sitting in such jams around the world who do so because they can't be bothered to find another way of getting where they want to go. If these new toll systems make at least some of those who could do so take another route, then they'll have helped to decrease congestion on the main arteries where they're being applied, thereby making life just a little bit better (although more expensive) for the people who have no other viable ways of reaching their destinations.
"I am probably not the only person who prefers to pay more for a solitary commute instead of having to share with others."
If you're willing to pay for that, then you shouldn't be worried about an IBM patent that allows you to do precisely that.
"Programs that perform I/O are inherently not "simple" programs--now, I/O is a requirement for useful programs, and might be pedagogically useful at an early stage to give people a feeling of making the computer "do something" productive, but its not simple, and it isn't central to understanding computing or program design"
I think you're misunderstanding what I mean by I/O. My use of the term is a generic one which does not imply any form of I/O devices, but refers instead to the fact that all meaningful processes (i.e. ones that do more than consume CPU time with empty loops) operate on data which can be described as an input to the process itself, and a result which is the process's output. Both input and output could therefore quite easily be (for example) a single variable that acts as both a data source (input) and data sink (output) for a process. This is such a fundamental concept that any course which doesn't teach students to think of data and processes in this way from the outset is failing to do it's job.
"The structure of Java (this is true of C and Pascal as well, though to a slightly lesser extent) programs inherently is not "simple", it involves lots of overhead."
Agreed. I've said elsewhere in this topic that I favour interpreted languages as vehicles for teaching very basic concepts precisely because they have little or no overhead, and I include things such as having to handle files and compilation phases in my definition of overhead that beginners shouldn't be distracted with.
"I prefer HtDP's description: "[A program] is a rule that tells us and the computer how to produce data from some other data.""
I fail to see where this is semantically different from my definition in any way that doesn't make it less generally applicable (e.g. "processes" can clearly include an arbitrary number of rules, whereas "a rule" implies that programs can only have one of them).