And then there’s the well-known Forth construct: ComeFrom . . . .Jerry > On Sep 12, 2015, at 2:07 AM, Graham Samuel <livf...@mac.com> wrote: > > Richmond, I was actually programming in the 1960s in languages that had ‘go > to’ but very few or maybe no other control structures. It was a mess and I > made a great many unnecessary mistakes, admittedly not helped by my lack of > training and experience (none was available where I was working!), the lack > of comment capability in early assemblers and indeed the limited instruction > sets in early computers. > > The problem of ‘go to’ is the problem of going back to where you came from: > subroutines (procedures) obviously take that problem away, so ‘go to’ is > vastly different from ‘gosub'. The classic exposition of the ‘go to’ problem > AFAICR is Edgar Dijkstra’s 1968 paper "Go To Statement Considered Harmful”. > Google will take you there if you’re interested. Not everyone agreed with > Dijkstra even at the time, but he was certainly on to something. You might > also give some thought to the idea of if/then/else and case statements being > other forms of disciplined control structure. When I started programming, I > used languages in which no such pre-defined structures existed. I think we’ve > made some progress since then, no? > > Your other issue - the nearer you are to logically expressed natural language > / pseudocode, the easier it is to find out what a program is doing, I > certainly agree with. This is a genuine dilemma, since there’s a lot > inherently complex stuff out there, and it’s getting worse by the minute, and > incorporating it in a ’natural-language-like’ form is a huge challenge and > one where success is not at all guaranteed. The aim of xTalk languages IMHO > is to remove unnecessary obscurity and complexity of vocabulary, syntax and > grammar in computer languages so one can get to the real point - but that in > itself doesn’t make programming simple, since the actual task and logic of > most worthwhile programs is inherently complex. > > Just a couple of eurocents from me. > > Graham > > >> On 12 Sep 2015, at 10:24, Richmond <richmondmathew...@gmail.com> wrote: >> >> Last night I was reading "C++ How to Program" from 1998, for no better >> reason than that I had left my novel >> at work . . . >> >> Oddly enough bits of it proved thought-provoking: >> >> "During the 1960s, it became clear that the indiscriminate use of transfers >> of control was the root of much >> difficulty experienced by software development groups." >> >> "The notion of so-called /structured programming/ became almost synonymous >> with "/*goto* elimination/." >> The research of Bohm and Jacopini had demonstrated that programs could be >> written without any *goto* statements." >> >> [Which is rather odd as from 1975 to 1985 all my programming seemed to >> revolve round subroutines.] >> >> When I read this I thought of a *function* in LIveCode, and thought that a >> *function* was a /transfer of control/. >> >> The authors of this book don't actually bother to explain why /transfer of >> control/ is supposed to be a bad thing. >> >> But they do say this: >> >> "structured programs are clearer, easier to debug and modify, and more >> likely to be bug-free in the first place." >> >> I actually find that statement pretty contentious. Particularly "more likely >> to be bug-free in the first place." The authors >> do not give examples and explanations as to why this might be true. >> >> The other thing is that programs written without transfers of control would >> seem to necessitate the needless *repetition* >> of code-blocks that, if hived-off into a *function*, can be written once, >> and control can be transferred to them when and >> if that functionality is required. >> >> Certainly calling a *function* in *LiveCode* seems no different from using a >> *goto* or *gosub* statement. >> >> ---------------------------------------------------------------------- >> >> Further on I came across this: >> >> "Pseudocode is often used to "think out" a program during the program design >> purpose. >> The the pseudocode is converted to C++." >> >> And it occurred to me that *LiveCode scripting* is considerably nearer to >> what these authors call 'pseudocode' than C++ is, >> and wondered if: >> >> The closer a programming language approximates to pseudocode the easier it >> becomes to use. >> >> At which point I started wondering if LiveCode, from its starting point in >> HyperCard and MetaCard hadn't, subsequently, >> moved further away from the pseudocode 'ideal' and further towards a more >> 'traditional' programming language with, >> as it has become more sophisticated and powerful, the introduction of stuff >> that looks less like natural language and >> more like a computer language? >> >> ---------------------------------------------------------------------- >> >> Certainly, from the point of view of teaching LiveCode to school children, >> the closer LiveCode is to both English and >> 'pseudocode' the easier the job that is involved turns out to be. >> >> Richmond. >> _______________________________________________ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your subscription >> preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
