However, to be frank: These kind of bugs are unacceptable. If this were Microsoft, everyone would be laughing and scolding, but since it's Apple I'm sure we'll get excuses....
Why would anyone make excuses? This will revolutionize the way we think about being on time -- You anti-Apple zealots are so predictable.
Like every game-changer Apple creates, you'll ridicule this as 'stupid' or 'an inexcusable bug' until this unimaginably innovative concept starts showing up on your iPhone wannabe Android "smart" phones as other handset manufactures begin the next round of catch-up.
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.
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?
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.
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.
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.
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?
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.
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.
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?
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.
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.
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".
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.)
If you want a conditional, you send an #ifTrue: message to an object with a block (closure) as the argument. The receiver is typically either the True or False singleton, which implements its #ifTrue: method by either sending a #value message to the argument or ignoring it. You can build additional loop constructs on top of it.
Great... so... how does this make programming easier? More importantly, how does this make Learning to program easier?
The notion of an object is trivial to understand.
Yeah, but that alone does not a programmer make.
An object is a simple (special purpose) computer. It receives messages, does some computation, and sends messages to other objects. If you understand what a computer is, you understand object orientation.
See, they don't understand "what a computer is" in the sense you mean here. That's a bit of a problem from an instructional standpoint.
It's just about decomposing your problem into smaller components,
This is good, but it's not an advantage that OO holds over procedural languages in either teaching or practice. (Quite the opposite, really.)
each of which is implemented as a (model of a) special-purpose computer.
Which is great -- for already competent programmers.
Trying to teach OO as a special case of procedural programming is a recipe for disaster.
That certainly would be. Who is advocating this?
I'd much rather OO be taught as a design technique -- not the "one true way" the purists advocate.
While I agree that OO has it's place, it's no panacea -- and is most definitely an unnecessary barrier to learning the fundamentals of programming.
I thought we had established that editors shouldn't fuck up with tabs and spaces in the '70s. Guess we didn't.
You have quite the imagination.
I do acknowledge that its whitespace-aware design may cause problem with some editors. What I don't acknowledge, however, is the idea that the blame for that problem lies on Python.
What? If it's Pythons "whitespace-aware design" that "may cause problem" I'd say that the blame lies squarely with Python.
OO languages like Smalltalk (for class-based OO) or Self (for prototype-based OO) and those inspired by them (like Ruby and JavaScript) that haven't, somewhere along the line, tried to wed OO structure with an existing static procedural language, don't really feature much boilerplate cruft that needs to be included in simple programs before beginning to introduce basic concepts.
So... how much cruft do think is acceptable? I think any amount is too much, for the reasons stated above.
Dijkstra was complaining about the first versions of BASIC which had line numbers and didn't have any flow control like IF-THEN-ELSE or WHILE-ENDWHILE
Why would Dijkstra complain about a version of basic that never existed? The first version at Dartmouth had IF-THEN-ELSE, just not block IFs. (It would appear that you're somewhat misinformed. I recommend you read the Dijkstra letter and speech I link to elsewhere in the discussion.)
As for railing against GOTO -- It was Wirth, not Dijkstra, that titled that infamous letter "GOTO considered harmful". (Which greatly upset Dijkstra) Dijkstra only suggested that GOTO should be avoided in structured languages.
You'll note that Wirth went as far as to eliminate break statements from Modula-2 and Pascal for the same reasons Dijkstra used against goto in the aforementioned paper. It had nothing to do with "spaghetti" code.
Oh, and the best you can come up with is an argument from authority? How about a real reason?
Keep in mind that only bad programmers wrote "spaghetti" code. That's certainly not the fault of GOTO. You don't hear people complain about "spaghetti" assembly code, do you?
(Bad programmers today write even more indecipherable OO "spaghetti" code without giving GOTO a second thought.)
The fact that Python users don't have the problems with whitespace that FORTRAN users did.
No, they have a host of new and different problems caused by the use of meaningful whitespace.
Problems moving between editors, problems sharing code via webpages and email, even problems moving chunks of code around in the source file (even the best python-aware editor will often need to make guesses about indentation.)
Simply using the wrong editor can introduce error into the source file -- that can be especially frustrating when those errors can be completely invisible.
I agree with the point about "magic-just-ignore-this code". But that comes from teaching non-OO programming in an OO language.
I suppose with the right language and lots of instruction before you start writing code, you could avoid some magic code. I just don't see why you'd *want* to start with it. It seems foolish to me to teach OO design before the student has a solid grasp of the fundamentals of programming.
Try drawing up a few lesson plans and I think you see what I mean.
My point is the OO is as much - maybe more - of a basic concept as iteration and branching.
I don't we'll find much common ground here. I can't even conceive of how OO could in any way be as or more fundamental than iteration and branching. (I honestly don't understand how you could reach this conclusion. I'd be interested if you had a way to explain this to me.)
I view OO in terms of design. (You can write OO code in non-OO languages, from a design point of view.) In that sense, it can be quite useful when applied to specific types of problems -- but in no way is it essential. (certainly not as essential as iteration or branching) I'd go as far as to say that the OO way can even be a very poor way to design an application.
I'm reminded of a question posted on a discussion board about writing a chess program. The submitter was working on a way to represent the board. He was toying with a 'piece centric' approach. (See this page for a better understanding of the problem. Board representation involves more than just a data structure.)
One of the replies was from a "pure OO" advocate, who suggested that a piece class be created from which specific piece classes (pawn, biship, etc.) could be derived.
Now, in a chess program, potentially millions of boards will be created, evaluated, and discarded as the computer attempts to determine its next move. Using the OO approach, in this case, is quite obviously the wrong thing to do.
Now, you might rightly say that this is OO misapplied (and it is), but how is a programming novice able to identify this?
A programmers first 'hello world' should be taught as giving a string object to the system object.
Again, I would disagree. It just seems too far away from what's actually happening in the computer -- and completely useless outside of the OO approach. (Which, as illustrated above, is not always the most sensible way.)
One surprising advantage of unstructured BASIC as a teaching tool is that the approach you take to structuring your programs is reasonably close to the way you'd structure a program in assembly. So close, in fact, that even in this discussion you'll find that many micro users made the leap from BASIC to assembly without difficulty.
There is no direct connection from the OO way to the machines way -- not that I expect many people to work in assembly in this modern age -- but I can see how it could hamper a transition to an imperative language. (Granted, this would be a disadvantage for declarative and functional programming as well.)
giving a string object to the system object.
I was never comfortable with strings being objects, though being an aggregate structure I could at least understand it -- the idea that scalars should be objects is just insane!
When I see things like this, it makes me think that the "pure OO" movement has taken the 'everything should be an object' mantra just a bit too far.
Please understand that I'm not anti-OO in any way. OO design is excellent for simulation or any similar design case where you have otherwise discrete components which can be seen as communicating with one another. It's just not all that useful (and potentially detrimental, as in the chess example) in other design cases.
That said, OO design, being non-essential, should wait until after the student has a solid grasp of programming fundamentals -- an advantage which imperative programming languages hold as teaching aids over OO languages for reasons stated earlier.
Slashdot Mirror
However, to be frank: These kind of bugs are unacceptable. If this were Microsoft, everyone would be laughing and scolding, but since it's Apple I'm sure we'll get excuses....
Why would anyone make excuses? This will revolutionize the way we think about being on time -- You anti-Apple zealots are so predictable.
Like every game-changer Apple creates, you'll ridicule this as 'stupid' or 'an inexcusable bug' until this unimaginably innovative concept starts showing up on your iPhone wannabe Android "smart" phones as other handset manufactures begin the next round of catch-up.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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".
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.)
However, he said he never spent the $30.
Ah, you are correct.
If you want a conditional, you send an #ifTrue: message to an object with a block (closure) as the argument. The receiver is typically either the True or False singleton, which implements its #ifTrue: method by either sending a #value message to the argument or ignoring it. You can build additional loop constructs on top of it.
Great... so... how does this make programming easier? More importantly, how does this make Learning to program easier?
The notion of an object is trivial to understand.
Yeah, but that alone does not a programmer make.
An object is a simple (special purpose) computer. It receives messages, does some computation, and sends messages to other objects. If you understand what a computer is, you understand object orientation.
See, they don't understand "what a computer is" in the sense you mean here. That's a bit of a problem from an instructional standpoint.
It's just about decomposing your problem into smaller components,
This is good, but it's not an advantage that OO holds over procedural languages in either teaching or practice. (Quite the opposite, really.)
each of which is implemented as a (model of a) special-purpose computer.
Which is great -- for already competent programmers.
Trying to teach OO as a special case of procedural programming is a recipe for disaster.
That certainly would be. Who is advocating this?
I'd much rather OO be taught as a design technique -- not the "one true way" the purists advocate.
While I agree that OO has it's place, it's no panacea -- and is most definitely an unnecessary barrier to learning the fundamentals of programming.
I thought we had established that editors shouldn't fuck up with tabs and spaces in the '70s. Guess we didn't.
You have quite the imagination.
I do acknowledge that its whitespace-aware design may cause problem with some editors. What I don't acknowledge, however, is the idea that the blame for that problem lies on Python.
What? If it's Pythons "whitespace-aware design" that "may cause problem" I'd say that the blame lies squarely with Python.
OO languages like Smalltalk (for class-based OO) or Self (for prototype-based OO) and those inspired by them (like Ruby and JavaScript) that haven't, somewhere along the line, tried to wed OO structure with an existing static procedural language, don't really feature much boilerplate cruft that needs to be included in simple programs before beginning to introduce basic concepts.
So... how much cruft do think is acceptable? I think any amount is too much, for the reasons stated above.
Do you mean this speech? or this letter? (Dijkstra's unsubstantiated list of aphorisms.)
Oh, yeah. Neither of them mention GOTO -- that's just in the one letter I linked to above.
Funny that it doesn't mention BASIC at all...
It looks to me like the GP is still wrong.
Dijkstra was complaining about the first versions of BASIC which had line numbers and didn't have any flow control like IF-THEN-ELSE or WHILE-ENDWHILE
Why would Dijkstra complain about a version of basic that never existed? The first version at Dartmouth had IF-THEN-ELSE, just not block IFs. (It would appear that you're somewhat misinformed. I recommend you read the Dijkstra letter and speech I link to elsewhere in the discussion.)
As for railing against GOTO -- It was Wirth, not Dijkstra, that titled that infamous letter "GOTO considered harmful". (Which greatly upset Dijkstra) Dijkstra only suggested that GOTO should be avoided in structured languages.
You'll note that Wirth went as far as to eliminate break statements from Modula-2 and Pascal for the same reasons Dijkstra used against goto in the aforementioned paper. It had nothing to do with "spaghetti" code.
Oh, and the best you can come up with is an argument from authority? How about a real reason?
Keep in mind that only bad programmers wrote "spaghetti" code. That's certainly not the fault of GOTO. You don't hear people complain about "spaghetti" assembly code, do you?
(Bad programmers today write even more indecipherable OO "spaghetti" code without giving GOTO a second thought.)
This is your evidence?
The fact that Python users don't have the problems with whitespace that FORTRAN users did.
No, they have a host of new and different problems caused by the use of meaningful whitespace.
Problems moving between editors, problems sharing code via webpages and email, even problems moving chunks of code around in the source file (even the best python-aware editor will often need to make guesses about indentation.)
Simply using the wrong editor can introduce error into the source file -- that can be especially frustrating when those errors can be completely invisible.
You want to get your religion from ancient books, go ahead. Those of us who are more scientifically minded will look to the evidence.
Okay, make your case. If you have evidence, as you claim, present it. I'm willing to evaluate it objectively.
I agree with the point about "magic-just-ignore-this code". But that comes from teaching non-OO programming in an OO language.
I suppose with the right language and lots of instruction before you start writing code, you could avoid some magic code. I just don't see why you'd *want* to start with it. It seems foolish to me to teach OO design before the student has a solid grasp of the fundamentals of programming.
Try drawing up a few lesson plans and I think you see what I mean.
My point is the OO is as much - maybe more - of a basic concept as iteration and branching.
I don't we'll find much common ground here. I can't even conceive of how OO could in any way be as or more fundamental than iteration and branching. (I honestly don't understand how you could reach this conclusion. I'd be interested if you had a way to explain this to me.)
I view OO in terms of design. (You can write OO code in non-OO languages, from a design point of view.) In that sense, it can be quite useful when applied to specific types of problems -- but in no way is it essential. (certainly not as essential as iteration or branching) I'd go as far as to say that the OO way can even be a very poor way to design an application.
I'm reminded of a question posted on a discussion board about writing a chess program. The submitter was working on a way to represent the board. He was toying with a 'piece centric' approach. (See this page for a better understanding of the problem. Board representation involves more than just a data structure.)
One of the replies was from a "pure OO" advocate, who suggested that a piece class be created from which specific piece classes (pawn, biship, etc.) could be derived.
Now, in a chess program, potentially millions of boards will be created, evaluated, and discarded as the computer attempts to determine its next move. Using the OO approach, in this case, is quite obviously the wrong thing to do.
Now, you might rightly say that this is OO misapplied (and it is), but how is a programming novice able to identify this?
A programmers first 'hello world' should be taught as giving a string object to the system object.
Again, I would disagree. It just seems too far away from what's actually happening in the computer -- and completely useless outside of the OO approach. (Which, as illustrated above, is not always the most sensible way.)
One surprising advantage of unstructured BASIC as a teaching tool is that the approach you take to structuring your programs is reasonably close to the way you'd structure a program in assembly. So close, in fact, that even in this discussion you'll find that many micro users made the leap from BASIC to assembly without difficulty.
There is no direct connection from the OO way to the machines way -- not that I expect many people to work in assembly in this modern age -- but I can see how it could hamper a transition to an imperative language. (Granted, this would be a disadvantage for declarative and functional programming as well.)
giving a string object to the system object.
I was never comfortable with strings being objects, though being an aggregate structure I could at least understand it -- the idea that scalars should be objects is just insane!
When I see things like this, it makes me think that the "pure OO" movement has taken the 'everything should be an object' mantra just a bit too far.
Please understand that I'm not anti-OO in any way. OO design is excellent for simulation or any similar design case where you have otherwise discrete components which can be seen as communicating with one another. It's just not all that useful (and potentially detrimental, as in the chess example) in other design cases.
That said, OO design, being non-essential, should wait until after the student has a solid grasp of programming fundamentals -- an advantage which imperative programming languages hold as teaching aids over OO languages for reasons stated earlier.