Comment Re:Not too big of a surprise (Score 1) 709
However, he said he never spent the $30.
Ah, you are correct.
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.
This is an absolute you have no justification to be declaring.
Yep. I did not justify my assertion. You are correct.
I assume that you completely agree with the rest of my post, as you didn't raise any objections to it.
Brilliant post -- well done.
went through this same leap. Unfortunately, I also brought the bad GOTO habit from BASIC. After awhile of mysterious stack overflows in my games, I figured out that using JMP from a subroutine instead of returning from it was a very bad idea.
Wait, are you telling me that using GOTO in BASIC is what prevented you from understanding the stack when you switched over to 6502 assembly?
Sorry, I don't buy it.
Nor can I imagine why (or believe that) you'd put yourself through unnecessary pain by writing a macro assembler in unstructured BASIC without using of GOTO. (It's a pretty important, and useful, aspect of flow control in BASIC on that C64.)
Best $30 I never spent!
What did you spend $30 on? It couldn't have been the Macro Assembler cartridge (you didn't have the money) Was it the C64? Did you pick it up at a garage sale in 1996? If that's the case, how much did they want for the Macro Assembler cartridge? Why would they sell the two separately?
No, this doesn't add up at all.
How about really spend some time on teaching HTML and CSS, put them as the main characters of the class and start on Javascript later, maybe next semester?
Because it's far easier to just use a different language for the course. No new courses need to be created and no additional prerequisites are added to the current course.
A language that actually uses whitespace should.
Languages shouldn't use whitespace. I thought we had established this in the 70's
Whitespace utilization in Python uses the programmer's intuition to instantly perceive block structure.
This is the most inane defense of Python's use of whitespace I've seen to date. If I want a block, I'll delineate it myself. I don't want the interpreter 'intuiting' my intentions.
Oh, wait. It doesn't use my "intuition to instantly perceive block structure". I delineate blocks myself via indentation.
Tisk, tisk. You had me all wrapped up in your magical thinking.
This beats the heck out of scanning lines for randomly embedded (speaking spatially, now) braces.
Badly formatted code is badly formatted code. Run it through a pretty-printer -- we've had those for 30 years. Problem solved.
Mind you, it is possible to write C (and I do), for instance, nominally a free form language WRT whitespace, with meaningful whitespace. Really helps, especially later on, when you haven't seen the code for years.
Yeah, this is what virtually everyone does already. Except in that case the whitespace isn't meaningful to the compiler -- just to the programmer. This is the way it should be.
The fact that Python *requires* whitespace is simply a means to bring your intuition to the table by force, and frankly, I think it's a good idea.
It in no way brings "your intuition to the table" by force or any other means. It just makes you indent your code according to Guido's preferences.
That some folks can't, or won't, get it... that's unfortunate. For them.
There's nothing to get -- Whitespace is how you delineate blocks in Python. There is nothing mystical here. It does not magically "bring your intuition to the table".
It DOES, however, allow Python un-aware editors to introduce errors into your program. (Think: converting tabs to spaces and the like.) It also doesn't allow you to use whitespace to format for readability. (Yes, there are cases where not indenting according to structure will actually improve legibility. You can probably quite easily think of a few examples yourself.)
I get why people like Python. What I don't understand is why they feel the need to defend this particular aspect of the language.
Even if you think meaningful whitespace is great, it should be easy to understand why other people dislike it. You should also at least be willing to acknowledge that it can, and often does, cause problems (moving code between editors or sharing code on webpages or via email, just for starters).
Really, the only benefit I can see is that you'll never be forced to look at badly-indented Python code. Considering the problems it causes, I hardly think it's worth the trade.
THAT was what Dijkstra was complaining about.
Try actually reading the Dijkstra letter in question.
Now do you see how totally wrong you are?
Reality must take precedence over public relations, for Mother Nature cannot be fooled. -- R.P. Feynman
