Ketil Malde writes:
I'm sorry, but, if we define "compiler" as a input->process->output pipeline, then:
"shuffling and transforming data" = compiler "transforming data for reports" = compiler
I actually think a lot of useful programs fit into that category.
Ketil, calling "compiler" all this stuff you mention, simply desintegrates the very definition of compilation. ALL is compiler... An image synthesis program (say, a ray-tracer like POV-Ray) is a compiler. TeX is a compiler. Etc. ... Perhaps, if you wish. But still, most people *USE* TeX or POV-Ray to make images or formatted documents. So, I think that your opponent (was it Alistair Bayley?) is mostly right claiming that people *write compilers* rarely. Even if I accept your philosophy that all/most data processing activities is a *kind* of compilation, in order to keep some minimum of discipline, I believe that it is good to assume that + Compilers are *universal*; they should handle a large set of sources, transforming them in something digested, reformatted, rendered visually etc. + The output of the compiler *should, at least conceptually* preserve the semantics - as we see it - of the source. Thus, say, a game is not a compiler. + They are more or less autonomous. TeX is a compiler. An add-on, say, a LaTeX macro-package (or an #included script to POV-Ray) are not, they just enrich the grammar of processed documents. + Compilers must respect some criteria of decency. (This is my idée fixe, I used to insist on that during all my compilation courses...) They are not allowed to break on erroneous data. They MUST terminate (gracefully). Etc. What is the percentage of programs written by average Norwegian salmon eaters which respect that? Concerning local French snail-eaters ... well, I lost all illusions quite a time ago. Jerzy Karczmarczuk PS. About the subject (when to teach IO): don't be sectarians. If a programming course insists on algorithmics, the IO issues can be postponed a bit. If it insists on practical data processing, IO should come in immediately. A programming course should be harmonious, homogeneous, well assembled, interesting, and easy to put into practice (...sorry for triviality, you ALL know that...), and the details depend on the language and on the teacher. In Scheme it is easier than in Haskell.