Parser, again!

On 23/12/13 15:03, dp wrote:
> On Sunday, December 22, 2013 2:35:45 PM UTC+2, Tom Gardner wrote:
>> On 22/12/13 12:15, dp wrote:
>>> Ah, on that the devil is doing quite well I think. I write very
>>> few comments in command scripts for example (usually a header explaining
>>> how to use the script). A comment line here and there inside, may be.
>>> And the script language is (well, has become over the years) not
>>> all that easy to read (variable names which can be made up of variables,
>>> partial variable extraction etc.). But my scripts tend to be what,
>>> tens of lines, a few hundred at most (if I ever wrote one that long,
>>> not so sure; over 100 yes, over 200-300 - don't know).
>>
>> Sounds like I wouldn't want to look (let alone maintain) that code!
>
> Hah, well, I thought it would sound like that. But it is not. Generally
> I think of writing scripts and other very high level sort of thing
> not as of "programming" (which is of course wrong but this is how I
> feel about it).

I've seen too many people not realise that they are in the
process of falling into that trap (and in some cases, not
realise it when they were in it!).

> If you know the script language

And that's the problem with /all/ "little languages", whether
they are interpreted, compiled, expressed in XML or ASCII.

Worst example I've seen?
if (FOO) {
   ...
}
where FOO was defined elsewhere and macro-expanded
using /many/ levels of macros before being compiled.
And such if-then-else statements were nested up to
10 (!) levels deep.

Why have FOO as a macro? "The source code is kept in
a repository, but FOO is not code and is changed by on-site
installation engineers." I never succeeded in getting
them to even understand that FOO was actually part of
the source code, let alone anything useful.

The "little language" issue is , of course, soluble if
the creator is also the only maintainer.


> Hieroglyphic I suppose but does it look that scary? I would hope
> not (but I don't really know... :-) ).
> Things can be (and do get) larger of course but I do not remember
> having had trouble getting back into one of these uncommented
> scripts last 20 years.

I have no reason to doubt it. Has anyone else had to modify
the code?


>> Macros and templates in most (all?) languages appear to be a point
>> of irritation to extent that they become painful.
>
> In vpa - having control over the whole thing, i.e. when I have needed
> something which the toolchain...

Which is the other problem with "little languages" - you can't
leverage the stunning analysis/creation tools available for
mainstream languages and environments.

I've seen a project spend several man-years creating an SDL-to-C
tool, only to have potential customers reject it because nobody
was prepared to maintain the toolchain. IMHO that rejection was a
very reasonable decision!

On Monday, December 23, 2013 6:33:50 PM UTC+2, Tom Gardner wrote:
> On 23/12/13 15:03, dp wrote:
> > On Sunday, December 22, 2013 2:35:45 PM UTC+2, Tom Gardner wrote:
> >> On 22/12/13 12:15, dp wrote:
> >>> Ah, on that the devil is doing quite well I think. I write very
> >>> few comments in command scripts for example (usually a header explaining
> >>> how to use the script). A comment line here and there inside, may be.
> >>> And the script language is (well, has become over the years) not
> >>> all that easy to read (variable names which can be made up of variables,
> >>> partial variable extraction etc.). But my scripts tend to be what,
> >>> tens of lines, a few hundred at most (if I ever wrote one that long,
> >>> not so sure; over 100 yes, over 200-300 - don't know).
> >>
> >> Sounds like I wouldn't want to look (let alone maintain) that code!
> >
> > Hah, well, I thought it would sound like that. But it is not. Generally
> > I think of writing scripts and other very high level sort of thing
> > not as of "programming" (which is of course wrong but this is how I
> > feel about it).
> 
> I've seen too many people not realise that they are in the
> process of falling into that trap (and in some cases, not
> realise it when they were in it!).

I think I have witnessed that, too. But I can't say I have
fallen into the trap, not during last 2+ decades at least.
Except the "feeling" this is not real programming I also
have a good idea when I write something I might use again
one day and when - not. Most of time things are to be reused
so I do things in a reusable way (not always consciously).
But there are times - e.g. writing a script named "test"
which is to do some highly specific operations to allow me
to debug something etc. (and usually gets deleted shortly).

> 
> > If you know the script language
> 
> And that's the problem with /all/ "little languages", whether
> they are interpreted, compiled, expressed in XML or ASCII.

Well of course, I have accepted that at the very start of the
whole now nearly 20 year old DPS effort. I think under the score
my work has benefited - I could not have been half as productive
had I relied on software not under my control (and not having
to maintain the entire house in working order which in turn has
kept me in good shape, the last perhaps more important than it
sounds).

> Worst example I've seen?
> if (FOO) {
>    ...
> }
> where FOO was defined elsewhere and macro-expanded
> using /many/ levels of macros before being compiled.
> And such if-then-else statements were nested up to
> 10 (!) levels deep.
> 
> Why have FOO as a macro? "The source code is kept in
> a repository, but FOO is not code and is changed by on-site
> installation engineers." I never succeeded in getting
> them to even understand that FOO was actually part of
> the source code, let alone anything useful.

This matches my observations (not many) on how people
misuse macros. Macros should be used only if not using
one would be impractical. It is hard to give a recipe of
course, a macro may be "practical" and be anywhere
between 2 and 2k lines.... :D .
One example of "good" macro usage I have is when I
needed to assemble some old 68HC11 code; I just implemented
the hc11 assembler using macros in A32 (my 68k predecessor
of vpa, produces cpu32 code). Took a whole day IIRC.
Another, somewhat harder to do example was implementing
the instruction set of a smart DMA controller (that on the
mpc5200B). In the latter case I had to invent also some
mnemonics I think, it took more than a day since I was
100% unfamiliar with the DMA and had to understand it etc.
during the process. But it was very "enabling" overall :D .

> The "little language" issue is , of course, soluble if
> the creator is also the only maintainer.

That has been the underlying assumption when I started it
all these years ago (I started DPS using 68k assembler in 1994
and did the vpa thing about 10-12 years ago when I migrated
the code to PPC (now (again) power...)) .
But I suspect any programming language has started if not under
the same assumption at least in a similar way.

> 
> > Hieroglyphic I suppose but does it look that scary? I would hope
> > not (but I don't really know... :-) ).
> > Things can be (and do get) larger of course but I do not remember
> > having had trouble getting back into one of these uncommented
> > scripts last 20 years.
> 
> I have no reason to doubt it. Has anyone else had to modify
> the code?

Not really. I did have a customer who wrote his own scripts
without any prior DPS experience though. Most other customers
expect "customer support" if something like that is needed though :D .

Dimiter
 (somewhat surprised to discover being distracted by
the expectation of a football game which starts after an hour...
have I really become a real Arsenal supporter? :D :D )

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/