Thoughts about Functions, Pseudocode & Natural Language

[Richmond]

On 09/12/2015 12:07 PM, Graham Samuel 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.

Well, I started with MiniFORTRAN and then FORTRAN IV in 1975 . . . up to 
my ears in GOTO statements.
>
> 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 difference is something I hadn't reflected on: not having a decent 
setup for playing around with BASIC to hand.

Sometimes I wish I could find a way to ship my BBC Micro and its 
non-standard monitor over here from my attic in Scotland just so I could
relax in front of a black screen occasionally: it has BBC BASIC on a ROM 
chip and the things boots up in the blink of an eye.

You are quite right.

> 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?

That does not stop me thinking that a *function* in LiveCode is very 
close to a *subroutine* in a 'traditional' program:
not that that is intended as a criticism.

>
> 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.

Of course. But teaching children to think through the logic involved in 
programming is made a lot easier when they don't also have
to navigate the complexities of a 'traditional' computer language.

I do tend to teach the logic of programming (however naturalistic the 
language in LiveCode may be) by messing around with physical
objects on a table; then writing pseudocode next to the objects (nothing 
quite like having a wipe-clean table and a pack of washable
board-markers!), before considering LiveCode: keeping children away from 
the keyboard and the computer is about half of the
struggle.

I think I began to feel a bit queasy when I attended the Edinburgh 
conference about 6 years ago and saw Benjamin Beaumont demonstrate
the Graphic Effects: and I don't mean that either Ben Beaumont or the 
Graphic Effects made me feel queasy; it was the syntax involved to
code the Graphic Effects (rather than just use the Props palette).

I think that may be the moment when LiveCode began to depart from the 
fairly natural language it had inherited from HyperCard: it may
have been necessary, or it may have been that the work to effect that 
stuff using fairly natural language was just a lot of hard work for
too little return: especially as I don't seem to see many people paying 
the Graphic Effects much attention (my Devawriter depends on
them for user feedback).

>
> Just a couple of eurocents from  me.

Well, as 2 Eurocents is 4 Bulgarian Stotinki . . .  :)

Best, Richmond.

>
> 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
>
> _______________________________________________
> 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