Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Comment Re:As a voter who normally leans Democrat... (Score 1) 1128

And does anyone have any statistics on how much Kentucky is using on education?

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.

Comment Re:Meh (Score 1) 338

The most bothersome thing about it, to me, is that too many good ideas were ridiculed for far too long before eventually being seriously considered and finally found to be true and revolutionary.

I was with you, right up until you started lying. We've had several centuries of science now - let's see you name just one such incident per year.

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.

Comment Re:ah faux news (Score 1) 338

What "global warming skeptics" don't seem to grasp is that exercising basic caution is not a bad idea.

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.

Comment Re:ah faux news (Score 1) 338

choosing to report from the center of whatever the political spectrum looks like in your country is still choosing a view point.

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.

Comment Re:ah faux news (Score 1) 338

Actually, Brontosaurus is no longer recognized, because some Camarasaurus fossils were lying at the same place as the Apatosaurus ones, so Brontosaurus actually was a misreconstruction made up from two different species.

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

Comment Re:ah faux news (Score 1) 338

To some people, it is more important who says something than what they say, truth be damned.

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.

Comment Re:ah faux news (Score 1) 338

I actually consider the facts and logic and if I've determined there is some need to form an opinion on a matter

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.

Comment Re:Not too big of a surprise (Score 1) 709

I guess I left out some details

Yes, thank you. This definitely clarifies things.

I might have had a few in my BASIC program but only to emulate IF/THEN/ELSE type logic.

GOTO was also quite handy for doing conditional iteration.

Everything else was handled by nice clean subroutines like we have in .net today. Since that lesson 30 years ago, I really haven't used GOTO in much of anything.

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.

Comment Re:Python vs. BASIC (Score 1) 709

any perceived "problem" with the language occurs only when using poorly-designed editors,

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.

It'd seem to me it's you who holds an irrational zeal against Python, apparently for bringing to light the shortcomings of your own tools.

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.

As far as learning goes, the language I'd recommend varies depending on the context, with Software Engineers starting with Pascal then moving on to Ada, Computer Scientists learning Python followed by Haskell, and school-age children with either Python or Lua and then, if they're willing, C. Python is certainly not the "be all, end all" of programming languages, but neither is it the anti-christ as you treat it.

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.

Comment Re:Python vs. BASIC (Score 1) 709

No, the problem lies squarely within poorly-designed editors, that much ought to be obvious.

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.

Are you, by any chance, the developer behind one such project? if so, I'd say fixing your own software would be far more productive than trying to hinder the adoption of a language as good and popular as Python.

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.

Comment Re:Programming should begin with OO - yes really! (Score 1) 709

Prefix notation for procedure and function application is fairly directly analogous to verb-first word order in natural language, which is what, for instance, English uses for the imperative and for many questions. Since procedure and function application maps fairly directly to either imperative commands or questions, prefix notation should be fairly easy to teach to English speakers.

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!

IME, its very common and useful for introductory courses, regardless of language, to want, fairly early on, to introduce simple concepts through compelling demonstration uses which rely on things whose implementation relies on techniques that have not been taught (and in some cases which are beyond the scope of the course.) In structured languages where this can be presented as a simple call out, this isn't distracting. Where you have to include the code directly, it is distracting.

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.)

the approach builds both breadth and depth as the course progresses, which I personally find is better than breadth-first -- e.g., covering all simple operations before starting either function definitions or control structures -- which is really the only alternative.

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?

Comment Re:Programming should begin with OO - yes really! (Score 1) 709

In that case, I would say both "zero" and say that procedural, functional, and OO languages -- which permit single-line calls to externally-implemented code that can be explained as telling something else what to do are actually are better at minimizing cruft than old-style BASIC is with mystical routines accessed with GOSUBS and arcane DATA statements.

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?

if you are teaching concepts and not the particular language and library structure

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.

I remain convinced that the relative merits of structured languages vs. something like old-style BASIC in a language to ise for that vary based on what the purpose of teaching "programming concepts" is:

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)

whether its more about teaching programming-as-a-vehicle-to-understanding-computers or programming-as-a-vehicle-to-understand-problem-solving.

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 agree with that as far as the book as a text is concerned, I was citing it as an illustration of a basic approach. I'd use the basic approach (though not necessarily either the book or Scheme specifically as the language) at any age where I wanted to teach programming-as-problem-solving.

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.

Programming-as-a-window-into-the-workings-of-a-computer I think old-style BASIC is still the most accessible language for novice programmers to use. I'm not sure the best approach for that, its not really something I've spent as much time thinking about.

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

Old-style BASIC's line-oriented structure might make it particularly strong here for younger learners, but I'm not sure that it is better than, e.g., Logo for this.

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

Comment Re:Python vs. BASIC (Score 1) 709

The fact that people don't have the problems that you insist we learned were inevitable in the 70s. You put forward a falsifiable hypothesis, and a counterexample falsifies it.

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.

How does meaningful whitespace introduce errors?

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

But it really doesn't. Non-significant whitespace has all the same problems in different forms.

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.

Comment Re:Python vs. BASIC (Score 1) 709

Well, that contradicts your original claim then, doesn't it?

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.

And the funny thing is, Python users don't actually have the problems you think they should have.

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".

Comment Re:Programming should begin with OO - yes really! (Score 1) 709

Define "cruft" concretely enough that it is possible to measure it quantitatively, and then we can discuss that question.

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.

OTOH, I think that the ease of expressing structure in functional, OO, and procedural languages makes any of those models better than old-school BASIC for teaching introductory programming in a context where the intent is to focus on designing solutions to problems

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.

The best specific implementation I've seen of an introduction of this type is the book How to Design Programs, which uses a series of successively more involved versions of a Scheme-derived pedagogical language.)

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.)

Slashdot Top Deals