[alicebot-archcomm] [news] Alice is ALICE is not Alice and AIML is NOT a programming language

[Kim Sullivan]

Hi Ernest,

> why don't you send some storm troops to drag me to the court in Den Haag
> and call it 'humanitarian intervention'?

I'm sorry, I should have been more thoughtful in my choice of words.

> What is it worth to put every feature in AIML some script kiddies are
> croaking for on the general mailinglist?
>
> Maybe the main reason for my sharp reaction on the general list was,
> that I just was angry about some people's (not yours, Kim) attitude of
> "Why is X not possible in A, it is working in B, so A must have it too
> right now" or shorter "I want all and I want it now".
>
> We should not "load up AIML with all kinds of stuff we might later
> regret" - as Noel remarked.
>

Yes, I'm a little hot headed sometimes, and I mistook your standpoint
(which, in this case, I agree with) for something different. I'm trying hard
to get the most out of AIML the way it is (like pseudo random sequences of
categories - you don't really need a <shuffle> tag, or a <sequence> tag or
even someting like <setnextcategory>), and only in some rare cases I would
resort to extending/modifying the language (like with the comparing of two
variables and conditions in general).

> But wouldn't naming AIML a PL imply, that it's just another PL or that
> newbies without programming skills are quenched? See the specs "1.1
> Origin and Goals" in this context.

I wouldn't actually _name_ it a PL (lots of PLs don't emphasize this aspect,
and call themselves 'description' or 'scripting' languages). There are
several features in AIML that would mislead a programmer to expect things
that simply aren't (and won't be) there, or would have no/little meaning.
There have been suggestions to introduce 'breaks' in templates, or srais
that 'wouldn't activate the same category again' or macros and stuff like
that - clearly something that a programmer would expect in a
structural/procedural program. Also, there were suggestions to treat
categories as objects (the OOP way), with acess rights, scopes and even
inheritance of some kind I think. In this regard, I think it helps not to
treat AIML as a classical PL (like Pascal, Java or C).
One of the reasons for using markup for syntax was not to scare off newbies
(esp. with HTML knowledge) - many of them aren't even realizing that they're
programming, they (should) think of it as writing web pages. AIML is (or
should be) simple enough for everyone to quickly 'get the hang of it',
programmer or not.

> If someone wants to look at AIML as PL - ok, but please avoid to
> emphasize this in public.

However, there are several aspects (especially inside the <template>, since
above that AIML behaves pretty much like every other ML) that tend to
confuse people with a strong XML/markup background. Normal users usually
don't have this problem, since they don't see markup as a way to 'describe
structured data' and therefore aren't surprised it's used to write
instructions (with deep nesting), instead of describing data (where you
usually have at least some 'atomic' elements). Many data visualisation tools
won't help with the template, I think, but something like a programmers
editor (with syntax highlighting and folding) might help.

In some implementations (like E, and even your V I think?) it is very
natural to simply use the 'native' language of the implemenation (like PHP
or perl), instead of (or in addition to) the markup. I myself have toyed
with the idea of 'compiled' AIML, which would use an approach a bit like JSP
does but in Delphi (this of course has nothing to do with the standard, but
only with my implementation).

I'm not even sure if there should be an 'official' standpoint about this -
sometimes it helps newbies to realize that its not the usual use of markup,
and sometimes it helps to point out that it's not just another procedural or
object oriented PL.

Regards,
Kim