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 to
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 the definitions.

(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 pre-declaration).

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 because you don't feel like using a readable loop counter because you'll have to
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
  end repeat

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

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.

Warmest Regards,


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

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 

Reply via email to