I don't have any figures, but I do have an anecdote.

My idiot brother, with no talent, skill, or formal education has a job in KY as a public school teacher.

I should probably also mention that he's a young earth creationist and a tea-birther -- just in case you didn't believe that he's a complete idiot.

So, to answer your question, I'd say that Kentucky is using as little as possible on education.

Are you seriously asking for hundreds of examples, in chronological order, of scientific ideas that were "ridiculed for far too long" before being both generally accepted and which were also revolutionary?

I don't think the GP meant, in any way, to imply that we had one of those a year, say, since Newton. (I'd say science was a failed enterprise if every year someone managed to turn it on its head!)

If you really want examples, one that springs immediately to mind is light quanta. If I remember correctly, that took some doing -- due in no small part to the fact that it was trivially easy at the time to show light to be a wave.

It's just one example, but it was a pretty revolutionary one. :)

More importantly, why do you think he's lying? The history of science is full of such stories.

While I'll admit that only a few could be considered 'revolutionary' there are certainly enough 'especially good' ideas, ridiculed for a reasonable amount of time before becoming generally accepted, that the GP could hardly be considered lying.

Neat, "Pascals Wager" for AGW.

More seriously, I've seen a lot of stuff from a lot of "global warming skeptics" but not once have I seen one who thinks we should just keep on polluting more and more.

If AGW was shown to be a complete fiction tomorrow, would you change your position on renewable energy or emissions standards? Would you head to the back yard, burn some tires, and dump used motor-oil down a storm drain on your way to trade in your hybrid for an SUV?

Of course not.

The GP didn't say anything about reporting from the center.

You can eliminate a good bit of bias by reporting only the straight facts and deciding what is important to report by the number of people likely to be affected.

You can't get rid of bias completely -- but a good journalist should make every effort to eliminate it from their reporting.

Fox, on the other hand, is actively bias as evidenced by the recently leaked Fox News memo.

Yet, at the same time, they claim to be without bias in their 'straight' news segments.

I'd call that a lie. Bias is one thing, but flat-out lying is another.

This makes me sad. As a child, Brontosaurus was my favorite dinosaur.

You'll find that 'who says it' is an important first consideration when evaluating a claim. For example, if Kent Hovind told me something about geology I would feel confident that I could ignore whatever he presented without further investigation because he has a long history of making false geological claims.

In cases like this article, Fox News suffers the same problem that the boy who cried wolf (the protagonist of the popular cautionary tale of the same name) suffered. They've told so many lies over the years that when they do say something true, no one believes them.

If true, this means that you are well-educated and have well-developed critical thinking skills.

Consequently, this makes you an elitist and part of the radical left out to destroy America.

Yes, thank you. This definitely clarifies things.

GOTO was also quite handy for doing conditional iteration.

See everyone, you can write structured code in BASIC -- even in those old unstructured 8k ROM versions of BASIC. It's the programmer, not the language, that produces good or bad code.

The main point, of course, is that GOTO isn't inherently evil. I know how the meme got started, I just don't know why it persists.

The two folks who inadvertently started the great GOTO war were Dijkstra and Wirth -- who weren't even railing against GOTO in general and certainly not for the popular (but unfounded) "spaghetti code" reason. (You can read the original letters yourself to get their true intent. Links to them are posted several places in these comments.)

It's interesting to note that Wirth kept Break out of Pascal and Modula-2 for the exact same reasons he was opposed to the use of GOTO in structured languages -- yet this bit never spread, and people use Break (and Return, to the same effect) without a second thought.

After all, what is Break if not an unconditional branch?

That's right folks, Break is GOTO

Just let that sink in.

If by "poorly designed editors" you mean any good code editor designed before Python...

Sorry, I think you've lost sight of reality.

Besides, any Well Designed code editor will have features for converting tabs to spaces (and vice versa) and features to auto indent and otherwise format code to your preferences.

As these are common and well-liked features of code editors, I find it odd that you'd call a program which included them as 'poorly designed'.

Ignoring that for just a moment, there is one unique problem that python has regardless of how good the editor is -- that's moving large blocks of code within or between source files. The editor will (in some cases) be forced to 'guess' at the intended indentation after the copy or move. In a language with traditionally delimited blocks, this isn't an issue as the average editor can automatically correct the indentation. No so with Python.

As a Python user, you should already be aware that the lexical analyzer adds indent and dedent tokens to mark blocks. When an editor is forced to guess, and guesses incorrectly, the tokens it generates for that purpose will also be wrong and it will improperly indent the code.

Why bring this up? It's a very weak argument against the use of meaningful whitespace, but it IS a clear problem with any language which uses meaningful whitespace the way python does which will exist regardless of the quality of the editor used.

Now I see why you're so irrational -- you struggle so with reading comprehension.

I've not said one word about hating python -- I've only talked about the problems with pythons meaningful whitespace.

But because I dared to criticize one aspect your sacred cow, you imagined that I was some sort of anti-python infidel.

Again, I've only criticized one aspect of Python. The opinion you think I have was created whole from your imagination.

Still, your list does tell me one thing: Your advise is completely worthless.

Look at what you've produced: You took three completely random groups and wrote down which languages you (inexplicably) decided they should learn.

Here's a clue -- learning about programing has NOTHING to do with the language. Absolutely nothing. The principles taught don't change with the language.

The instructors choice of language, however, can make learning about programming easier or more difficult. That's all the impact it can have, and why this Slashdot article exists in the first place.

This is why your "software engineers should learn two nearly-dead procedural languages" and "computer scientists should learn my favorite language and a functional language" so laughable.

First, there is no reason why the students intended future profession should have any bearing on the curriculum -- the principles are the same, no matter what the student chooses to do in the future. As stated earlier, the principles you teach are the same no matter WHAT the language!

As for "school-age children" you should know (if you're handing out advice) that that covers a broad range of ages. (Consequently, a good chunk of the cognitive development spectrum.)

You should also know, that there has been a good deal of actual research done on the subject of teaching children about programming. Research of which you're clearly unaware.

Sorry, if I need a special editor to write code in a language, that's the fault of the language.

I hear this all the time from people defending meaningful whitespace in Python like it's some kind of revolutionary idea. In reality, it causes many more problems than the one it unnecessarily solves. This has been very well established, though you seem to be having trouble seeing this through your zealotry.

Pretending that the problems don't exist or that the problems are caused by something external is irrational.

You're free that like meaningful whitespace -- you're entitled to your subjective opinion.

You should, however, acknowledge the drawbacks. As I said before, willfully ignoring their existence is completely irrational.

I see that you think that because I disagree with you I must have some ulterior motive? I'm sorry to inform you that I do not.

My opinion is based on reason and evidence. The fact that you refuse to acknowledge that the problems I've listed exist despite the overwhelming evidence suggests that you've based your opinions on nothing but your subjective impression of the language.

To move this discussion back on topic, we're talking about teaching programming to children. The whitespace issue will likely lead to mistakes difficult to find as students enter examples and problems from print sources (textbooks, handouts, etc.) where correct indentation may be non-obvious especially if they're struggling with the concept of blocks. They are also likely to inadvertently mix tabs and spaces -- for programmers, the distinction is obvious, not so for beginners. Consequently, it becomes an easy rule for students to accidentally ignore, leading to unnecessary problems.

Aside from that, having end of blocks clearly marked can make instruction easier as children can think of an end of block mark as a kind of instruction. (e.g. "When the interpreter sees 'next i' it jumps back to the top of the loop")

But you don't care about that. It seems your devotion to python has blinded you to it's drawbacks. I suppose you think it's perfect for all applications, including as a pedagogical aid, with no deficiencies at all.

Yes, it can be taught fairly easily and quickly. However, it is a distraction and complete waste of class time. You will be teaching prefix notation and not computer programming -- likely wasting a whole day. It also adds another stumbling block -- while I doubt they'd struggle converting 2 + 2 to + 2 2, converting 2 + 2 - 3 or anything more complicated will be a struggle without an acquired fluency. (Which they won't have after that wasted day of instruction.)

As we're talking about teaching children, you may need more than one day -- days that are wasted doing math and not programming. It's an excellent way to kill their interest!

In that case, it's at the discretion of the instructor -- not forced upon him. Though in the classes I've taught, I've never found the need to use, in an example, anything that the student has not been exposed to. (with cruft-free languages anyhow) Of course, I take great care when preparing the course to ensure this. (This has the additional benefit of forcing me to present the material in such a way that concepts build directly atop one another. I've found this to be very effective.)

It's not an either-or scenario. When you're starting from nothing, "breadth" is unavoidable -- but you needn't spend the whole course that way. If you are, you've likely stopped teaching concepts and started teaching [insert language].

While I generally don't cover functions until later, some control structures (like conditional branching) do get attention early.

I wait on functions because they're simply not important that early, and can be distracting.

Of course, we're still only talking about the first 3 weeks of a course (4, if you've got a slow class ;) ) Most of the "depth" enters in afterward as they explore common algorithms and data structures.

I'm curious, do you have much experience teaching?

This doesn't make sense to me. With old unstructured BASIC there is never a case when the student would need to encounter a DATA or GOSUB without first being introduced to it. (I don't know of any mystical routines accessed via GOSUB -- any routine you'd call is one that you've written. Could you explain this further?)

That's really what makes BASIC shine in the classroom: there is never any cruft.

Lisp and Scheme (and others, like forth) share this advantage, but have other barriers, like prefix notation, that make them less than ideal.

With most (all?) OO languages, some cruft is inevitable -- even most procedural languages offer their share (C and Pascal come immediately to mind here.)

The point, of course, is why choose some when you can choose none?

Any competent teacher will be teaching concepts -- no matter what language they use for the course.

I'm convinced that the reason many beginning students fail in the classroom is the instructor is trying to teach [language] and not programming.

Well, most structured BASIC interpreters have all the classroom advantages of unstructured BASIC plus the ability to introduce subroutines and functions (that they're distinguished is also nice) after they're already familiar with blocks.

Add to that, in many structured BASICs, line numbers are optional but still supported (they can be nice from a pedagogical perspective)

I understand why you'd make the distinction, but you can't really teach one without teaching the other to some degree. While teaching programming, the emphasis is always on problem solving, the "understanding computers" aspect is not only unavoidable but naturally blends itself into the instruction with phrases like 'the computer will ...' and 'that tells the computer to ...'.

I'd disagree, on the basis of my experience. The approach the book introduces concepts in an order I see as inappropriate for beginners -- All-in-all the book is a bit ham-fisted in it's approach. Topics don't build on (or flow into) one another and Related concepts aren't generally presented together.

This isn't really a problem if you want to learn Scheme and a bit about functional programming -- it actually works rather well -- but in the classroom, such a presentation quickly turns into a confusing mess.

"The best" is nebulous. It's certainly the best I've found for children 10+ and adults. (Though I use a structured BASIC)

I agree. Logo really is a great choice for children 10 and under.

You must be new to this reasoning and evidence thing. See, in this case, a counter example in no way falsifies my hypothesis.

Also, if you were using hollerith cards in the 80s I feel sorry for you.

The developed world had VTDs and, yes, whitespace cause no end of headaches.

Have you read any of my posts? This has already been explained.

What? Okay, you're just being contrary for no reason now. Explain to me insignificant whitespace causes ANY of the problems I've listed.

Really, when you write things like this it makes me wonder if you're a complete idiot or a really good troll.

No, it doesn't.

Meaningful whitespace is bad because it introduces errors (which are now invisible). We did learn this in the 70's. The fact that specific problems are different is irrelevant.

Ah, but they do! The honest ones just admit it. If you dig through various discussions on the subject, you'll find that even the most ardent Python advocates admit the problems that meaningful whitespace causes -- they just think that the one benefit it brings is worth the trade:

See, the only argument that is (and can be) made for the use of meaningful whitespace is that it forces developers to properly intent their code -- something every experienced programmer is likely doing anyway. (some benefit!)

It's silly, if you chance to encounter improperly intended code (a rare occurrence indeed), a quick run through a pretty-printer will take care of the problem in under a second. It'll also apply whatever formatting conventions you, not Guido, think are easiest to read.

Now, with that one "benefit" comes a host of problems, like the ones I mention above and others which you can read about yourself. Is the trade-off really worth it?

I say no.

Oh, I'm still waiting for your alleged "evidence".

Why? You quite obviously know what I mean by 'cruft' (necessary code incomprehensible to the student within the context of the material presented) and you know that I think that 0 is the only appropriate amount. It's really up to you to pick a measure if you think that some cruft is acceptable -- go with lines or characters for all it matters.

Remember that the discussion is about teaching programming concepts to children. Though even if we weren't, I find it unnecessary (and consequently less-effective) to introduce structure early in the learning process.

I'm familiar with the book and while I think it's one of the best for introducing functional programming to already competent programmers, I wouldn't use it to teach programming to beginners. Given the content, I certainly wouldn't use it to teach children under the age of 15. (This is my intuition from years of experience teaching programming at various age levels. I'm not sure that I can properly explain why I believe this to be the case.)