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 <[email protected]> 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
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
