Thoughts about Functions, Pseudocode & Natural Language

[Graham Samuel]

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 <richmondmathewson at 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode