I haate that students coming out of universities, when asked about registers and how would they write a multiply routine if they only had shifts and adds, ask "why do I need to know this?"
As a college-level CS instructor, I desperately hope none of my students ever says that. The answer is: You're not supposed to know it. You're supposed to understand numbers, algorithms and computers well enough that you can figure it out if someone asks you. You're supposed to be familiar with the concept of sometimes having to do things you're accustomed to having done for you, whatever they might be, sometimes unexpectedly. You're supposed to be smart.
I'm with pipingguy. If these people aren't hurting anyone, and they don't want "treatment", why medicate them? So you can feel better about having them around?
Fine. But there are lots of people with depression who do want treatment. People who feel their lives being taken away by the things going on in their brain and will gladly undergo therapy and endure side effects if it means being able to participate in life. Treatments should be available for these people.
Not to mention the fact that programming languages (not assembly) by definition, are extensible. Most programming languages provide loops, if statements, and ways to define classes, methods, and variables.
How is that the definition of extensible? Those aren't mechanisms for extending a language, they're just programming constructs. They illustrate only that programming languages (by definition!) can be programmed in.
I was in a day-long meeting once that involved a lot of people sitting around a conference table with a mess of extension cords underneath to plug our laptops in (the room was not designed for this sort of thing). More than once someone rolled their chair over a cord, or tripped, or something, cutting off power to all the computers on one side of the table. Being modern laptops, they all switched instantly to battery power. Some beeped, and most dimmed their screens slightly, but no one ever lost anything and disruption of the meeting was minimal.
Honestly, how hard would it be for desktops to do this too? And wouldn't it save a lot of trouble?
Original poster: What, pray tell, is "compiler theory"? I'm a little perplexed that someone who knows something about "compiler theory" is asking Slashdot how to write a compiler. Most of the answers you will get here are from people who don't really know any "compiler theory".
People suggesting Lisp/Scheme: Sure, these languages are extensible, but any extension of Lisp/Scheme you can create with macros or whatever will still look like Lisp/Scheme. If the point of this exercise is to design one's own language, one might not want to base the syntax on Lisp's.
People suggesting using various parser generating tools (yacc, bison, antlr,...): A parser is not a compiler. I guess it's good to use the right tool for each part of the job, but parsing is really the least of his problems.
If the point is designing a language for the fun of it, don't bother writing a compiler, write an interpreter. As others have pointed out, writing an interpreter in a sane high-level language like ML (or Scheme or, I suppose, even Java) is really dead easy if you're not worried about performance. It will probably distract you less from the language design than a compiled implementation would, and be easier to modify as you go along. Plus it will be portable, maybe. If your language becomes wildly popular (or if you feel that performance is the only thing standing between your language and wild popularity) you can write a better interepreter, or a JIT, or a compiler, later on when you're more sure of what you're doing.
If the point is writing a compiler for the fun of it, why not do it all yourself from scratch (except maybe for the parser, for which you can use any of the excellent tools recommended by slashdotters if you don't want to do it by hand)? Compilers aren't really that hard (if you know "compiler theory"), especially if you compile to assembly or C and use an assembler or C compiler to go the rest of the way. Compiling to Parrot assembly/bytecode or JVM or.NET bytecode is also a possibility.
Since you say your language has higher-order features, you will want to read up on implementation techniques for functional languages if you haven't already. For instance, check out the 90-minute Scheme-to-C compiler here.
-1 redundant: an equivalence class implies an equivalence relation which implies reflexivity, symmetry and transitivity.
-1 backwards: Grandparent post makes perfect sense. You can't talk about "the largest equivalence class in R" unless you know the relation R is an equivalence relation. Taking the reflexive transitive symmetric closure turns a relation that may or may not be an equivalence into one that is.
Furthermore, "can be reached by an IP packet from" is not transitive, since not all nodes necessarily forward packets. Symmetry is questionable as well. Thus it was necessary to turn that relation into an equivalence before talking about equivalence classes.
There are runtime penalties for doing the type checking, of course, but that's the cost of using generics.
Not if the language does generics right, there aren't. The whole point is that you type-check a generic thing once, at compile time, and then know that no matter how it is instantiated the result will be well behaved. This way you can in principle avoid both (1) the code bloat you get in C++ due to different instances of a template being compiled separately, and (2) the run-time cost you incur in, say, Java when you try to fake generics using Object and have to cast things all the time.
Now, if you're compiling to a "typed" bytecode format such as that of the JVM (or CLR?) and the bytecode's type system doesn't know about generics, then you will pay for type checking that you don't really need (cuz at the bytecode level you have to do the generics the fake way using Object, but none of the casts will ever fail). But that's a separate issue.
In fact this book is pretty damn wonderful. I know, it may sound a bit gushing, but before you review my review, give the book a read yourself.
I seriously doubt anyone will do that. In fact it's pretty likely people will opine on the book without having read either the book or the review!
Are we going to see "RTFB" in book review discussions now?
Not only did the reviewer gush about the book, there was a little bit of gushing about the book's message (and bashing of its predicted detractors) that wasn't really informative about the book itself at all. It would have been better to devote more space to discussing what the authors actually said, so I'd have some incentive to read the book other than the satisfaction of seeing my point of view supported.
A Warning: I agree that Spivak's "Calculus" is a good book, but I wouldn't start with it if you don't know any calculus already.
I learned calculus from Douglas Downing's Calculus the Easy Way (I can also recommend Algebra the Easy Way and Trigonometry the Easy Way by the same author; all are published by Barron's), before I studied it in high school. Three years later as a college junior (at one of those elite private institutions) I took an analysis class that used Spivak as the text, and I remember thinking "Hey, this is all the same stuff as in AP calc, but it's ten times harder now!"
The Spivak book was great for turning a working knowledge of calculus into a deeper understanding of what makes the real numbers what they are. But math "newbies" may find it discouraging. YMMV.
It also lacks details on how to rip the old printing system out of your legacy Unix -- but if you've got root, this is something you should know anyhow.
That's bogus. Anyone who has installed a system on his or her home computer will have root, but nowhere near all of them will know where all the components that have to be ripped out are located. I know I don't.
That said, I suppose replacing a legacy system with CUPS might not be considered on-topic for this book... but there seems to be a niche for more generic books about Unix printing that would cover such things.
There are some problems where a recursive solution seems the obvious way to go, but it can bite you in the ass if you're not up to speed on (for instance) program complexity or other matters.
(Before the assignment was due, the instructor suggested switching to an iterative approach, which was of linear complexity instead of exponential complexity.)
Of course, this wouldn't have been a problem had you been using a language where tail recursion is optimized away by the compiler. This would include most decent functional language compilers.
I'm pretty sure this is wrong for the example given. If you write the fibonacci function in the "obvious" way (with two recursive calls), then it isn't tail recursive and will take exponential time no matter what the compiler does.
If, on the other hand, you write fibonacci this way (in ML):
fun fact' (a,b,n) = if n = 0 then a
else fact' (b,a+b,n-1)
fun fact n = fact' (1,1,n)
then it is tail-recursive. An ML compiler will treat this as iteration, so you get (1) slightly better time performance, and (2) much better space performance, since you don't use additional stack space for every recursive call.
Needless to say, people learning functional languages are taught to write code that is tail recursive when possible. Once you get used to this it is just as natural as writing loops.
No. That's math geek speak for the surface of what ordinary people might call a 3-dimensional sphere. Just the ordinary sort of sphere you see everyday, but called "2-dimensional" because it's the surface, not the interior, that counts.
in fact Rice's theorem proves no non-trivial property of programs can be proven mechanically.
I followed that link to Rice's theorem, and it states that no non-trivial property of programs can be checked mechanically (not "proved" -- there are plenty of programs with non-trivial properties that are provable). In particular, relying on unit testing to ensure any aspect of correctness beyond doubt is doomed.
On the other hand, if your encoding of Turing machines is a type-safe language, then type safety is a trivial property -- so you can be sure your program has it. Surely knowing something is better than knowing nothing.
How many times have you wanted to jump out of the type cage?
In Java, all the f*cking time. In ML, just about never.
JV
Re:You lost me on the incredible leap of logic...
on
XML and Perl
·
· Score: 1
I agree completely. Not having any particular expertise in this area, I won't argue whether regular languages occur often enough in practice to justify blanket statements about perl. But my point, which I never quite said explicitly, was that XML is not regular (in the sense of regular expressions) and therefore perl's advantage for the task is limited if it exists at all.
CJV
Re:You lost me on the incredible leap of logic...
on
XML and Perl
·
· Score: 1
Note the "by definition" part.
y(z) does not follow "by definition" unless your first assumption is the definition of y. It is not the definition of perl that it is good at processing text files. It is at most a fact about perl.
In fact I don't think it makes sense to claim "For all text files T, perl is good at processing T." That's pretty nonsensical if you ask me. And I don't think it's even true that "For all operations O on text files, perl is a good implementation language for O." If this were really true, then it would follow that perl is a good language for any operation that assumes its input is an XML file, which is what the original poster seemed to mean.
What's more reasonable is to relax the statement to "There exists a fairly large class C of operations on text files such that perl is a good implementation language for any operation O in C." But it does not follow from this that perl is good for XML, unless the intersection of C and "XML operations" is a fairly large portion of the latter set.
Does this mean they actually implemented a fix to the covariant-parameter unsafety that used to exist? I haven't paid attention to Eiffel for a few years, so I can't be surprised if they have.
For those who don't know, earlier versions of the Eiffel language had a serious bug whereby you could write a program that would compile just fine but would end up calling a method on an object that didn't implement that method, resulting in an ungraceful crash. The problem was due to the way method parameter types are allowed to change in subclasses, and IIRC a couple of different fixes were proposed, but I had heard rumors that the Eiffel implementations did not actually use them, leaving the language unsound.
My first reaction upon reading the article was, "Yes, that is exactly what has happened to me." When I was a kid, every time I acquired a new electronic device -- even something as simple as a walkman, a clock radio or a digital watch -- I would read the entire manual from front to back and try out every feature of the thing to learn how to use it. Last year when my alarm clock broke I went to Wal-Mart and tried to find a new one that was as much like my old one as possible, to avoid having to learn anything new. The same thing has happened for new watches, new microwaves, new versions of KDE, you name it.
I've always assumed that this is because I'm getting old (at 25), but this article offered me some hope. (Not that I'm taking it all that seriously, but still.) The author notes that he and his brother, though different ages, have been exposed to technology for about the same absolute number of years, and are both experiencing version fatigue. The hypothesis this suggests is that version fatigue is a universal phenomenon that has been getting ready to happen ever since high-tech devices began working their way into our lives, and is now taking hold of everyone simultaneously.
I'm not sure if I believe this story, but it makes me feel less old.
I'd like to point out that I am not a nontechnical person, but that version fatigue has affected me as a programmer as well. A decade ago, I felt like I knew Turbo Pascal 5 inside and out. But then as I migrated from Pascal to C, DOS to Windows, Windows to Linux, C to Java, etc. I found I didn't really care to update my skills. (Of course, I didn't have to since I don't program for a living.) Now every time I want to write a shell script, the first thing I type is "man csh".
Perhaps I am pathetic, but it appears I am not alone.
>>What I mean by that is that students should be instructed in the intellectual process of designing solutions to problems, or working out ways to accomplish tasks, rather than just showing them how a CPU works, how a compiler works, and a few "Patterns" and then telling them to figure out the rest for themselves.
>I agree. That's why I didn't go into detail about how CPUs and compilers work. That wouldn't be my goal at all.
When I took AP CS in high school many years ago, the teacher began the course by showing us a diagram of a computer that consisted of a "control unit", an ALU, some memory, and "input" and "output" devices. She then showed us some simple code in pseudo-assembler and traced through it in front of us. Finally she told us that we would be learning a high-level language that was easier to write but would be reduced by the compiler to instructions like we had just seen.
This may be what is necessary in order to teach Pascal (or now C++) to high school kids, but it is not too helpful in developing "programming" (as in problem solving) skills. (She also taught us "top-down design" and flowcharting, but I'm not sure how helpful these were either.) I think it's important that after an introductory programming course, if I ask students "Ok, so how could you put these numbers into ascending order?" they don't automatically begin with "Well, first I'd need to allocate these local variables..." or some other programming language driven response.
I agree with you (although it may have seemed I didn't) that having students write programs in a real language is crucial, mostly because it gives them a sense of how infuriatingly precisely they have to say what they mean in order to get the behavior they want. It will also allow them to automatically get feedback from the computer as to whether their programs are right -- but it's important not to confuse "learning through interaction with the computer" with "learning that the way to program is by interacting with the computer", i.e. learning a trial-and-error-can-solve-anything design methodology.
First, I would teach what memory is, and how instructions are followed in memory and the concept of algorithms. The next thing would be variables, followed by pointers.
Wait, you think this is design? This is not design. This is "how a computer works", which is *not* what people should be thinking about when they design programs. I'm not even convinced this is what people should be thinking about as they write programs. If, for example, you are programming in a functional language, then thinking too much about how the computer will execute your code will hurt you more than it helps -- making your head hurt and your code suck.
I agree, though, that it is useful to teach "programming" as opposed to "coding". What I mean by that is that students should be instructed in the intellectual process of designing solutions to problems, or working out ways to accomplish tasks, rather than just showing them how a CPU works, how a compiler works, and a few "Patterns" and then telling them to figure out the rest for themselves.
Also, rather than post again in a different thread, I'd just like to get off my chest the fact that it is impossible by definition to teach programming by just teaching syntax. Even if you think you're just teaching syntax, you're probably also conveying to students at least a vague sense of what the different syntactic constructs "do", or "mean" -- i.e., semantics.
I use OpenAFS between work/school and home. It is very convenient to access at work, where a fast Ethernet connects me to the AFS server, but quite slow from home over DSL. Examples: when Emacs auto-saves to AFS, I have to stop typing for a while; I try hard to avoid compiling things (or running TeX) where the code is in AFS; when I kept my email in AFS, sylpheed took a really freakin' long time to scan my inbox and was much slower to incorporate new messages than it ought to have been.
Also, I was frustrated by the process of compiling OpenAFS for my Mandrake 8 box (GCC version crap), and if I ever try to mount AFS when anything is wrong with the network, I know I am in for a serious crash later on. Perhaps these are just my fault, of course.
Time for a stupid question: If it is such a bad idea to undefine the default (or any?) namespace, why does XML allow it?
Perhaps the inability to undefine non-default namespaces (see the last section of the article) should be called a "wise decision" as opposed to an "oversight"?
Slashdot Mirror
I haate that students coming out of universities, when asked about registers and how would they write a multiply routine if they only had shifts and adds, ask "why do I need to know this?"
As a college-level CS instructor, I desperately hope none of my students ever says that. The answer is: You're not supposed to know it. You're supposed to understand numbers, algorithms and computers well enough that you can figure it out if someone asks you. You're supposed to be familiar with the concept of sometimes having to do things you're accustomed to having done for you, whatever they might be, sometimes unexpectedly. You're supposed to be smart.
CJV
Fine. But there are lots of people with depression who do want treatment. People who feel their lives being taken away by the things going on in their brain and will gladly undergo therapy and endure side effects if it means being able to participate in life. Treatments should be available for these people.
CJV
How is that the definition of extensible? Those aren't mechanisms for extending a language, they're just programming constructs. They illustrate only that programming languages (by definition!) can be programmed in.
CJV
Honestly, how hard would it be for desktops to do this too? And wouldn't it save a lot of trouble?
JV
People suggesting Lisp/Scheme: Sure, these languages are extensible, but any extension of Lisp/Scheme you can create with macros or whatever will still look like Lisp/Scheme. If the point of this exercise is to design one's own language, one might not want to base the syntax on Lisp's.
People suggesting using various parser generating tools (yacc, bison, antlr,...): A parser is not a compiler. I guess it's good to use the right tool for each part of the job, but parsing is really the least of his problems.
If the point is designing a language for the fun of it, don't bother writing a compiler, write an interpreter. As others have pointed out, writing an interpreter in a sane high-level language like ML (or Scheme or, I suppose, even Java) is really dead easy if you're not worried about performance. It will probably distract you less from the language design than a compiled implementation would, and be easier to modify as you go along. Plus it will be portable, maybe. If your language becomes wildly popular (or if you feel that performance is the only thing standing between your language and wild popularity) you can write a better interepreter, or a JIT, or a compiler, later on when you're more sure of what you're doing.
If the point is writing a compiler for the fun of it, why not do it all yourself from scratch (except maybe for the parser, for which you can use any of the excellent tools recommended by slashdotters if you don't want to do it by hand)? Compilers aren't really that hard (if you know "compiler theory"), especially if you compile to assembly or C and use an assembler or C compiler to go the rest of the way. Compiling to Parrot assembly/bytecode or JVM or .NET bytecode is also a possibility.
Since you say your language has higher-order features, you will want to read up on implementation techniques for functional languages if you haven't already. For instance, check out the 90-minute Scheme-to-C compiler here.
Best of luck,
CJV
-1 backwards: Grandparent post makes perfect sense. You can't talk about "the largest equivalence class in R" unless you know the relation R is an equivalence relation. Taking the reflexive transitive symmetric closure turns a relation that may or may not be an equivalence into one that is.
Furthermore, "can be reached by an IP packet from" is not transitive, since not all nodes necessarily forward packets. Symmetry is questionable as well. Thus it was necessary to turn that relation into an equivalence before talking about equivalence classes.
Geez.
CJV
Not if the language does generics right, there aren't. The whole point is that you type-check a generic thing once, at compile time, and then know that no matter how it is instantiated the result will be well behaved. This way you can in principle avoid both (1) the code bloat you get in C++ due to different instances of a template being compiled separately, and (2) the run-time cost you incur in, say, Java when you try to fake generics using Object and have to cast things all the time.
Now, if you're compiling to a "typed" bytecode format such as that of the JVM (or CLR?) and the bytecode's type system doesn't know about generics, then you will pay for type checking that you don't really need (cuz at the bytecode level you have to do the generics the fake way using Object, but none of the casts will ever fail). But that's a separate issue.
But IDNKC#, and IDNRTA.
CJV
I seriously doubt anyone will do that. In fact it's pretty likely people will opine on the book without having read either the book or the review! Are we going to see "RTFB" in book review discussions now?
Not only did the reviewer gush about the book, there was a little bit of gushing about the book's message (and bashing of its predicted detractors) that wasn't really informative about the book itself at all. It would have been better to devote more space to discussing what the authors actually said, so I'd have some incentive to read the book other than the satisfaction of seeing my point of view supported.
JCV
I learned calculus from Douglas Downing's Calculus the Easy Way (I can also recommend Algebra the Easy Way and Trigonometry the Easy Way by the same author; all are published by Barron's), before I studied it in high school. Three years later as a college junior (at one of those elite private institutions) I took an analysis class that used Spivak as the text, and I remember thinking "Hey, this is all the same stuff as in AP calc, but it's ten times harder now!"
The Spivak book was great for turning a working knowledge of calculus into a deeper understanding of what makes the real numbers what they are. But math "newbies" may find it discouraging. YMMV.
CJV
That's bogus. Anyone who has installed a system on his or her home computer will have root, but nowhere near all of them will know where all the components that have to be ripped out are located. I know I don't.
That said, I suppose replacing a legacy system with CUPS might not be considered on-topic for this book... but there seems to be a niche for more generic books about Unix printing that would cover such things.
CJV
CJV
I'm pretty sure this is wrong for the example given. If you write the fibonacci function in the "obvious" way (with two recursive calls), then it isn't tail recursive and will take exponential time no matter what the compiler does.
If, on the other hand, you write fibonacci this way (in ML):
then it is tail-recursive. An ML compiler will treat this as iteration, so you get (1) slightly better time performance, and (2) much better space performance, since you don't use additional stack space for every recursive call.Needless to say, people learning functional languages are taught to write code that is tail recursive when possible. Once you get used to this it is just as natural as writing loops.
CJV
Is that math geek speak for circle?
No. That's math geek speak for the surface of what ordinary people might call a 3-dimensional sphere. Just the ordinary sort of sphere you see everyday, but called "2-dimensional" because it's the surface, not the interior, that counts.
JV
I followed that link to Rice's theorem, and it states that no non-trivial property of programs can be checked mechanically (not "proved" -- there are plenty of programs with non-trivial properties that are provable). In particular, relying on unit testing to ensure any aspect of correctness beyond doubt is doomed.
On the other hand, if your encoding of Turing machines is a type-safe language, then type safety is a trivial property -- so you can be sure your program has it. Surely knowing something is better than knowing nothing.
How many times have you wanted to jump out of the type cage?
In Java, all the f*cking time. In ML, just about never.
JV
CJV
y(z) does not follow "by definition" unless your first assumption is the definition of y. It is not the definition of perl that it is good at processing text files. It is at most a fact about perl.
In fact I don't think it makes sense to claim "For all text files T, perl is good at processing T." That's pretty nonsensical if you ask me. And I don't think it's even true that "For all operations O on text files, perl is a good implementation language for O." If this were really true, then it would follow that perl is a good language for any operation that assumes its input is an XML file, which is what the original poster seemed to mean.
What's more reasonable is to relax the statement to "There exists a fairly large class C of operations on text files such that perl is a good implementation language for any operation O in C." But it does not follow from this that perl is good for XML, unless the intersection of C and "XML operations" is a fairly large portion of the latter set.
CJV
Does this mean they actually implemented a fix to the covariant-parameter unsafety that used to exist? I haven't paid attention to Eiffel for a few years, so I can't be surprised if they have.
For those who don't know, earlier versions of the Eiffel language had a serious bug whereby you could write a program that would compile just fine but would end up calling a method on an object that didn't implement that method, resulting in an ungraceful crash. The problem was due to the way method parameter types are allowed to change in subclasses, and IIRC a couple of different fixes were proposed, but I had heard rumors that the Eiffel implementations did not actually use them, leaving the language unsound.
So what's the current story on this?
JV
You people are too fast for me.
Come to think of it, it's a little bit weird to say "if you don't care about side effects," because after all the deletion is itself a [side] effect.
JV
Nobody gave the answer yet? Is this it?
void remove (NODE *trash) {
trash->data = trash->next->data;
trash->next = trash->next->next;
}
I assume you meant a pointer to the node to be removed, not the element. Pretty cool.
JV
I've always assumed that this is because I'm getting old (at 25), but this article offered me some hope. (Not that I'm taking it all that seriously, but still.) The author notes that he and his brother, though different ages, have been exposed to technology for about the same absolute number of years, and are both experiencing version fatigue. The hypothesis this suggests is that version fatigue is a universal phenomenon that has been getting ready to happen ever since high-tech devices began working their way into our lives, and is now taking hold of everyone simultaneously.
I'm not sure if I believe this story, but it makes me feel less old.
I'd like to point out that I am not a nontechnical person, but that version fatigue has affected me as a programmer as well. A decade ago, I felt like I knew Turbo Pascal 5 inside and out. But then as I migrated from Pascal to C, DOS to Windows, Windows to Linux, C to Java, etc. I found I didn't really care to update my skills. (Of course, I didn't have to since I don't program for a living.) Now every time I want to write a shell script, the first thing I type is "man csh".
Perhaps I am pathetic, but it appears I am not alone.
JV
>>What I mean by that is that students should be instructed in the intellectual process of designing solutions to problems, or working out ways to accomplish tasks, rather than just showing them how a CPU works, how a compiler works, and a few "Patterns" and then telling them to figure out the rest for themselves.
>I agree. That's why I didn't go into detail about how CPUs and compilers work. That wouldn't be my goal at all.
When I took AP CS in high school many years ago, the teacher began the course by showing us a diagram of a computer that consisted of a "control unit", an ALU, some memory, and "input" and "output" devices. She then showed us some simple code in pseudo-assembler and traced through it in front of us. Finally she told us that we would be learning a high-level language that was easier to write but would be reduced by the compiler to instructions like we had just seen.
This may be what is necessary in order to teach Pascal (or now C++) to high school kids, but it is not too helpful in developing "programming" (as in problem solving) skills. (She also taught us "top-down design" and flowcharting, but I'm not sure how helpful these were either.) I think it's important that after an introductory programming course, if I ask students "Ok, so how could you put these numbers into ascending order?" they don't automatically begin with "Well, first I'd need to allocate these local variables..." or some other programming language driven response.
I agree with you (although it may have seemed I didn't) that having students write programs in a real language is crucial, mostly because it gives them a sense of how infuriatingly precisely they have to say what they mean in order to get the behavior they want. It will also allow them to automatically get feedback from the computer as to whether their programs are right -- but it's important not to confuse "learning through interaction with the computer" with "learning that the way to program is by interacting with the computer", i.e. learning a trial-and-error-can-solve-anything design methodology.
JV
Wait, you think this is design? This is not design. This is "how a computer works", which is *not* what people should be thinking about when they design programs. I'm not even convinced this is what people should be thinking about as they write programs. If, for example, you are programming in a functional language, then thinking too much about how the computer will execute your code will hurt you more than it helps -- making your head hurt and your code suck.
I agree, though, that it is useful to teach "programming" as opposed to "coding". What I mean by that is that students should be instructed in the intellectual process of designing solutions to problems, or working out ways to accomplish tasks, rather than just showing them how a CPU works, how a compiler works, and a few "Patterns" and then telling them to figure out the rest for themselves.
Also, rather than post again in a different thread, I'd just like to get off my chest the fact that it is impossible by definition to teach programming by just teaching syntax. Even if you think you're just teaching syntax, you're probably also conveying to students at least a vague sense of what the different syntactic constructs "do", or "mean" -- i.e., semantics.
JVI use OpenAFS between work/school and home. It is very convenient to access at work, where a fast Ethernet connects me to the AFS server, but quite slow from home over DSL. Examples: when Emacs auto-saves to AFS, I have to stop typing for a while; I try hard to avoid compiling things (or running TeX) where the code is in AFS; when I kept my email in AFS, sylpheed took a really freakin' long time to scan my inbox and was much slower to incorporate new messages than it ought to have been.
Also, I was frustrated by the process of compiling OpenAFS for my Mandrake 8 box (GCC version crap), and if I ever try to mount AFS when anything is wrong with the network, I know I am in for a serious crash later on. Perhaps these are just my fault, of course.
Hope this helps.
Time for a stupid question: If it is such a bad idea to undefine the default (or any?) namespace, why does XML allow it?
Perhaps the inability to undefine non-default namespaces (see the last section of the article) should be called a "wise decision" as opposed to an "oversight"?