OT Re: Newbie... Strict Compilation mode

[Stephen Cox]

Well..  God.. Sorry all for starting this. :)

Use what you want. I'll keep it on cause I'm used to that type of
environment. Used to declaring variables. And it's in my head.



On 5/10/09 1:09 AM, "Joe Lewis Wilkins" <pepetoo at cox.net> wrote:

> Following this thread has pushed another one of my buttons and I
> cannot resist getting on my soap-box and inserting my two-bits.
> 
> We have "all" become accustomed to protecting ourselves from
> ourselves. To the point where some of us pass laws requiring that
> everyone protect themselves. I'm talking about INSURANCE. The best
> "insurance" against having anything happen is an alert and active
> mind.  Insurance merely puts us to sleep; allowing us to be less than
> vigilant and knowledgeable within all aspects of our lives. Not
> declaring vars merely promotes sloppiness and, eventually, stupidity.
> The President is going to spend enormous sums of money promoting
> Health Insurance, when the best insurance is almost free; preventive
> medicine which we have neglected for decades. We just need to be
> diligent about all things. Education, eduction, education!!!!!!!!
> 
> Joe Wilkins
> 
>   On May 9, 2009, at 8:47 PM, Mark Wieder wrote:
> 
>> Jacque-
>> 
>> Saturday, May 9, 2009, 6:01:53 PM, you wrote:
>> 
>> Ah... I *knew* this would push Jacque's buttons... <g>
>> 
>>> 1. The main strength of xtalk is that you do not have to declare or
>>> type
>>> variables. Sticking them up there at the top of every handler removes
>>> one of the main advantages of using Rev in the first place.
>> 
>> I seriously take issue with that being "the main strength" of xtalk.
>> 
>>> 5. And finally, what's wrong with being lazy? :) The smart programmer
>>> finds the easiest way to do things. That's what Rev is all about.
>> 
>> Laziness is one of the big reasons I *do* declare my variables. If the
>> compiler is smart enough to catch all kinds of errors for me, why
>> should I go through all the debugging work at runtime? I believe in
>> letting the computer do the hard work for me, otherwise I might as
>> well just be coding the cpu's opcodes by hand.
>> 
>>> None of these things is outweighed for me by the fact that
>>> explicitVars
>>> might catch a few typos. The engine catches most of those anyway and
>>> throws an error.
>> 
>>> Back to today's response:
>> 
>>> The debugger pinpoints the exact source of the misspelling if it
>>> happens; how hard is that? I'm a pretty good typist though, so I
>>> don't
>>> get caught out too often. I suppose if you are really as bad a
>>> typist as
>>> your theoretical example, then yes, you'd want some help. ;)
>> 
>> <puts on a SNL snarl>
>> ...Jacque, you ignorant slut...
>> <returns to reality>
>> You're missing the point. The purpose of explicitVars is to catch
>> things that slip by the compiler otherwise. If it's just a simple
>> misspelling of a keyword the compiler will catch it anyway, as you
>> pointed out. But explicitVars will let you know if you've mistyped a
>> variable name when the "friendly" compiler would helpfully generate a
>> new variable instead of using the one you intended. And it will help
>> when your fingers forget to place a space after "the" and instead of
>> the variableNames ending up in a variable you end up with empty.
>> 
>>> I once took over a project from someone who used explicit
>>> variables. I
>>> stripped out all the declarations so I could read the scripts
>>> comfortably. The stack size was cut in half (!). No lie. There were
>>> all
>>> kinds of handlers in there with something like 8 lines of
>>> declarations
>>> and three lines of actual script. Waste of time and space.
>> 
>> I recognize hyperbole when I see it, but nonetheless I don't think you
>> can have 8 lines of declarations and three lines of actual script (and
>> of course someone will post some code that proves me wrong). If you
>> come across a handler like this then you have at least five lines of
>> declarations that are not being used. And then you're absolutely right
>> to strip them out <g>.
>> 
>> -- 
>> -Mark Wieder
>> mwieder at ahsoftware.net
> 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution