Re: C/C++ lua_stackdump lib - feedback welcome

[Francisco Olarte <folarte@...>]

Hi Sean:

On Tue, Oct 11, 2016 at 11:07 PM, Sean Conner <sean@conman.org> wrote:
>   I was programming in assembly language long before I came to C.  Assembly
> code is very vertical in nature and thus, I got used to it.  And when I came
> to C, I carried over my predilection for vertical code.

I did pass through assembly to ( I think it was something like
FORTRAN/B3700 assembly/COBOL/Honeywell Bull
BASIC/(TRS80/AppleII/Amstrad)Basic/Microsoft M80+appleII
assembly/TurboPascal+BDS C or something similar.

>   I never did like having the brace at the end of a line as I found it got
> lost, and it made it difficult (to me) to visually match braces [1].

Like using this gmail thingo makes it difficult for me to read your
notes :( ( my fault ;-> ).

 Anyway, I do not visually match braces, as I always use them for
multiline constructs, so I consider for(;;){ to be the FOR-START, as
lua has for .... do. The only place I ( very rarely ) omit braces is
on one-line constructs ( like while(get_record()); to flush a buffer
on errors, and normally I do {\n} instead of ; just for coherency.
Over the years I've found the extra typing is worth it as it saves
brain cycles when parsing ).

>> I normally prefer to split the code in chunks I
>> can scan confortably ( and I cannot scan more than about .4/.5 m ) for
...
>> detail, and the last brace is the closer, being a brace or an end like
>> in lua is just a detail).

>   So you must love Pytho which did away with such cluttering detail.

  No, I dislike not having 'end' / '}', I need something serving as
FOR-END, IF-END, WHATEVER. I just do not like multiline separators,
for me 'if () {' parses as a token, '} else {' and I need the '}' to
close it properly.




>   Also, a question, do you do:
... This one, although I wrap it on long arguments.
>         int main(int argc,char *argv[]) {
>   Just curious as to where you might break your own pattern 8-P

I normally do not, as I just let indent/emacs do the work.

> [1]     Yes, I know---most text editors can match the pairing characters.
>         But at the time I was using an editor that lacked that feature (or I
>         never found it).

Pairing always fail when you need it most.

> It stuck.  Much like my preferring print() style
>         debugging as a way to work around lack of good debuggers for the
>         language du jour. [2][3]

That's nice, but a pain to remove the print code. AAMOF I worte myself
a perl module to put debugging code in comments which could be removed
by the absence of an ENV VAR or just switching s 'use' to 'no'. I
supose some day I'll do something similar in lua has it seems in can
be done ( by the existence or things like moonscript and friends which
fudge the source ).

> [2]     I first worked with Java back in 1996, back when it was just fresh
>         from Sun, no debuggers, and only one book available on it.

Yeah, when Java was really slow.

> [4]     About the biggest change is that I no longer put parenthesis around
>         values being returned.  I used to do:
>                 return (foo);
>         Now I do:
>                 return foo;

I forced myself to do that to remember its an 'operator' or whatever
you call it, not a function, and to avoid the nasty 'retrun(x)' hidden
deep in lua-like ( no declaration needed ) languages.

Francisco Olarte.