RH's concluding paragraph: > > Your real problem in this discussion is that you > cannot for the life of you, understand artistry. You > didn?t understand it in our ?particular? discussion > and you don?t understand it now. In fact, you don?t > comprehend it so much that you still think I am doing > some sort of a trick. > I cannot for the life of me understand how RH arrived at his 'concluding paragraph' about artistry and stuff from all that went before. It is true that I am not expert at s/w programming - but I have admired 'artistry' in the writings of various high-level s/w designers.
(RH's post is copied below my signature for ready reference).
GSC ("Still Shoveling! Not PUSHING!! Not GOADING!!!") > On Mar 2, 2014, at 1:03 PM, Joe Niederberger > <firstname.lastname@example.org> wrote: > > > Its a simple matter of knowing what the term-of-art > "structured programming" means in the usual contexts > its employed in. Hansen *never* wants to use words > with their usual meanings in the usual contexts. I > think its simply lack of education. When called, he > gets bizarrely elaborate, as do many of his kindred > spirits. > > Do you understand what you are asking me to do? You > are asking me to discard decades of experience and > hundreds of thousands of lines of code, so that I can > adhere to a puny school-taught notion of structured > programming. What happens when someone asks you "How > did they code without the GOTO statement?? > > For example. The following is a typical case of an > IF/THEN/ELSE structure, in a language without blocks. > > 100 IF x < 10 THEN GOTO 200 > 110 GOTO 300 > > 200 Statement 1 > 210 Statement 2 > 220 Statement 3 > 230 GOTO 400 > > 300 Statement 4 > 310 Statement 5 > 320 Statement 6 > > 400 ? > > Do you see how you have to hop over the (logical) > blocks of code with goto statements? You cannot write > structured IF/THEN/ELSE patterns without goto > statements in a language that doesn?t support blocks. > And your reward for using best practices? You get to > keep track of hundreds of labels and god forbid you > have to add more statements or refactor things a bit. > But as Lou pointed out, that is what a (good) > programmer did because, as tedious as it was, that > was still the best way to break a problem down, into > a series of steps. Assembler was tons worse. > > Add BEGIN/END and things change enormously for the > better? > > IF x < 10 BEGIN > Statement 1 > Statement 2 > Statement 3 > END > ELSE BEGIN > Statement 1 > Statement 2 > Statement 3 > END > > The same structure but behind the scenes the compiler > is doing all of those GOTOs for you. You don?t have > to worry about a bunch of labels. Talk about a load > lifted! And we didn?t even get to the local scope you > now have. You don?t have to declare dozens of TEMPnn > and DUMMYnn variables because now you can keep using > the same meaningful names in block after block > because they are now in their own scope. > > I don?t see what I have said as being overly > elaborate. I have a lot of experience and a lot more > on this subject than what I displayed here. I lived > all of this. Asking me to trade all of that for your > notion of structured programming is impossible at > this point. I am also flummoxed that you keep calling > me uneducated, but used to it, so don?t stop. > > Your real problem in this discussion is that you > cannot for the life of you, understand artistry. You > didn?t understand it in our ?particular? discussion > and you don?t understand it now. In fact, you don?t > comprehend it so much that you still think I am doing > some sort of a trick. > > Bob Hansen