The_Master,
There is such a thing is learning you know.
Also, now you've jumped from complaining about a programming method to dis'ing a particular person! That's a lot of aggro.
twm40799 asked for a sample and so I provided one, and also showed good natured humor in the post. BTW, twm40799 is professional (I assume), not one of the Blockly students. Only structured programming is being dissed.
I'm interested in knowing what the students are STILL struggling with to get it to work right? Example please.
You started on March 7. On March 16 you were still posting--
"The program works but I found a couple of issues."
This should have taken 5 lines, a couple address labels, and 15 minutes.
If you worked for me you would be in the doghouse, while me and Mickster would be playing Counterstrike and eating pizza.
I wrote the first program to show the OP how to have the teacher reset the LEDs. I did not have an opportunity to run the program. The program was written with the pins that were requested. When I first ran it on 3/16 I used a board that I had previously wired for a different purpose. The issues had to do with conflicts with pins on that board. I had to change some statements to deal with that. The other issues were that I recalled how things worked on the TV show and I wanted to address those issues.
Except that the OP specifically wanted to use case statements, I would not have. In prop C I would do it this way:
I'd still like to see how you would do it in Basic in 5 lines - I really am interested in seeing how it would be done.
Since I'm not a programmer, and you couldn't meet my salary demands, I don't think you have to worry about me working for you.
tom
As I said before it's irrelevant. Structured programming does not demand using some obscure, clunky, complex, confusing, graphical blocks programming tool.
Your assertions are that "the entire 'structured' thing is out of control" and that "using structured programming in the context of embedded control is completely asinine". I hope from reading my posts above you can now see that these statements are false.
My position is that an optimum programming language is a mix imperative plus modular.
This makes no sense. "imperative" and "modular" are orthogonal.
When each module of code is no more than a page or so, any spaghetti code will just be a couple short strands....
I'm all for small, simple, testable, self-contained modules. "Separation of concerns" and all that.
Fully modular coding without the forced structure. Faster to develop. Higher performance. Faster to learn.
Nobody forces the structure. We choose to structure things because that is the better thing to do. Ofcourse one should be open to bending the rules if the situation demands it.
I don't agree that spaghetti code is faster to develop. Quite likely it's harder, especially when it comes to changing it it in the future.
I debunked the higher performance claim above. It's rare to have to squeeze out the last 10% of performance. At which point it's probably time to change to assembler.
Faster to learn is a dodgy claim as well. Admittedly removing structured programming constructs from a language, or just not using them, results in less syntax to learn. Which is useful for raw beginners, which is why BASIC was invented. However after a few hours of that and moving to more complex problems then structure, and the syntactic support of the language, make life easier for the student.
This should have taken 5 lines, a couple address labels, and 15 minutes.
I wish you would show your solution, as I requested an example of your unstructured state machine idea, rather than just talking about it all the time.
Comments
I wrote the first program to show the OP how to have the teacher reset the LEDs. I did not have an opportunity to run the program. The program was written with the pins that were requested. When I first ran it on 3/16 I used a board that I had previously wired for a different purpose. The issues had to do with conflicts with pins on that board. I had to change some statements to deal with that. The other issues were that I recalled how things worked on the TV show and I wanted to address those issues.
Except that the OP specifically wanted to use case statements, I would not have. In prop C I would do it this way: I'd still like to see how you would do it in Basic in 5 lines - I really am interested in seeing how it would be done.
Since I'm not a programmer, and you couldn't meet my salary demands, I don't think you have to worry about me working for you.
tom
You keep coming back to that jeopardy thing.
As I said before it's irrelevant. Structured programming does not demand using some obscure, clunky, complex, confusing, graphical blocks programming tool.
Your assertions are that "the entire 'structured' thing is out of control" and that "using structured programming in the context of embedded control is completely asinine". I hope from reading my posts above you can now see that these statements are false. This makes no sense. "imperative" and "modular" are orthogonal. I'm all for small, simple, testable, self-contained modules. "Separation of concerns" and all that. Nobody forces the structure. We choose to structure things because that is the better thing to do. Ofcourse one should be open to bending the rules if the situation demands it.
I don't agree that spaghetti code is faster to develop. Quite likely it's harder, especially when it comes to changing it it in the future.
I debunked the higher performance claim above. It's rare to have to squeeze out the last 10% of performance. At which point it's probably time to change to assembler.
Faster to learn is a dodgy claim as well. Admittedly removing structured programming constructs from a language, or just not using them, results in less syntax to learn. Which is useful for raw beginners, which is why BASIC was invented. However after a few hours of that and moving to more complex problems then structure, and the syntactic support of the language, make life easier for the student.
Thanks.
Would you like my paypal number?
Thread closed.