On 2018-03-28 15:45, Mike Kerner via use-livecode wrote:
Heck no. I spend way too much time in environments that were written
make the complier-writer's job easier and have 50-100 lines of headers.
It's annoying to the extreme.
Heh - I'm not sure that the necessity to predeclare things in many
languages can just be put down to 'making the compiler writer's job
easier' - even if you go back 'just' 15 years, computers were nowhere
near as powerful as they are today and most of the languages which exist
today have a history which goes back waaaay further.
If things are not pre-declared then you need at *least* two passes to
compile a program. Each pass requires a linear traversal of the input to
the pass. If you require the programmer to pre-declare then you can
compile in a single pass in many cases (a technique called
syntax-directed translation). If you don't pre-declare then the first
phase has to parse all the syntax into structures without knowing how
they fit together, and then you have to iterate over those structures
defining the 'names' in appropriate scopes and *then* you have to
iterate over those structures again to link up the uses of the names to
(You can merge the declaration and parsing phases - but not the
declaration, parsing and definition phases - hence why you have a
minimum of two passes in a language which does not require
Of course, in a dynamic environment like LiveCode where code is split up
and insulated into multiple distinct much smaller texts, and you can
defer action until use, pre-declaration is not really required (and
indeed it is not) - you can amortize the cost of the notional passes
over the time the program is running rather than having to do it all
ahead of time.
Nothing makes code less readable than re-using i, j, k, l, and m
you don't feel like using a readable loop counter because you'll have
fix the declaration.
I must confess I still use i, j, k etc. type variable naming - but only
when I want the index and element in numeric arrays or if I'm writing
code which is doing maths where the equations use such index notation:
repeat with i = 1 to the number of elements in tVar
-- now I can mutate the elements of tVar as it loops
I'm not sure why I've got into that habit though - its not really a good
one! Although I don't think it does much harm if the loops are only two
or three lines long.
Of course, if you happen to have an non-optimizing lower-level compiler,
then re-using variables can make a huge difference to code performance
as you can be more sure a register will be used (assuming the data type
is appropriate) - that being said 32-bit intel architectures have never
really had that issue as they have virtually no registers anyway!
(Fortunately something which the 64-bit variant has fixed!).
I want the best of both worlds, and mostly I want the machine to do the
work, not me. I'm busy.
Indeed, the work has to be done at some point, by somebody/thing - the
balance is whether you want to pay the cost:
1) waiting for things to compile (a full recompile of the engine on
Mac OS X used to take 15-20mins when I first got it; although the record
was apparantly 8 hrs on the AIX box MetaCard used to have - and C/C++
*requires* predeclaration for most things).
2) over the lifetime of the execution of the program (or at the start
if you use a lot of code at startup)
3) by the programmer whilst writing the code
That all being said, variable analysis could be done better in all
languages I think - although it isn't the easiest of problems or things
to get right. Python I think might be *slightly* better than LiveCode's
(its somewhere between explicitVars = true and explicitVars = false -
and doesn't require declaration). On the other hand, Python doesn't have
a mode where you can have bare literals (which require significant
context analysis to work out whether they are variables are not unless
you do all the work whilst executing the code - which is essentially
what LiveCode does when explicitVars are false - so you pay for that
with a performance cost and not knowing whether you've made an error
before you run).
I think it would be generally true to say that most programming
languages are designed to keep any context-sensitive information
required compile/execute them to the bare minimum - and any which is
required can be collected in very fast and efficient ways. For humans
this is very unintuitive though - if nothing else, humans are generally
quite good at very quickly guessing at the correct context of things
when there is a paucity of information - computers may have caught up a
bit speed wise to allow greater contextual awareness (just because they
are faster with more storage/memory) but programming languages perhaps
My general feeling that there is a better balance lurking - somewhere
between Python and LiveCode's non-explicit-variables mode:
1) Python does not require pre-declaration of variables, and is pretty
good at determining when you mis-spelt a variable - however all literals
must be quoted.
2) LiveCode does not require pre-declaration (in expliciVars = false
mode), and allows you to unquote literals as long as they are not also
variables in the same context - but it cannot tell you if you've
mis-spelt a variable.
The problem here is finding that balance.
P.S. We are also, of course, blessed with the fact these days that you
can have readable variable names at all - I think the VMS C compiler
still had an 8 char limit on identifiers until some hideously recent
P.P.S. Even with the machines we do have today, I'm not sure what not
having to predeclare things in C would do the speed of compilation of C
- so in some cases we just have to live with the slight inconvenience :)
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription