[MUD-Dev] Properties of computer languages

[Hans-Henrik Staerfeldt]

On Wed, 16 Jun 1999, Caliban Tiresias Darklock wrote:
>
> I'm in the process of redesigning the macro language of my game, and I
> recall seeing at one time a list... a very short list... of things that=
 a
> computer language absolutely required. Sort of a bare-bones "what you n=
eed
> to do everything you need to do in any given program". Two of the thing=
s on
> the list were conditionals (if/then/else) and iteration (for/next and
> do/while). There were either two or three other things listed, but I do=
n't
> remember what they were. Does anyone here have a memory spark going off=
 as
> to what list I'm talking about and where I can find it? I think one of =
the
> other things was something along the lines of subroutine/function decla=
ration.

To all the the answers taking a turn into the computability area of
languages, .. c'mon guys :-) you know this is not what he's looking for!
(although it might be interresting, i know i have programmed in lambda=20
calculus, actually accomplishing a multiplication function after an=20
hour ... uck!).

Anyway, since i did some HCI work with evaluation of computer languages
i might give a few hints (in the opposite corner). There are, in my opini=
on
one important factor in the design of programming language;

  The ability for the constructs of the programming language
  to easily express the mental models of the problem that
  the language is used to solve.

Now, if you are going to make your own programming language, i propose
that you foremost examine the sort of problems that is to be solved=20
with it. Take a declarative programming language as Prolog. Here the=20
constructs are declarative logic, and in my oppinion, prolog very nicely=20
hides all the messy details of pattern matching and the like from your mi=
nd.=20
For many tasks, you do not have to think hard about how to present your=20
knowledge to prolog. However, to other tasks, prolog stink. Where the=20
mental models of the problem conflict with the constructs of the language=
,=20
you have to 'bend' your understanding into expressing it with the=20
programming language you use.=20

Another factor here, is that ofcause you get better at this with training.
Therefore, it would be a bad idea to trust your own judgement in 'how
the world is percieved' bu the programmer. You will be influenced by you
own (and very accurate) perception of how the world works. However, it mi=
ght
not at all be how the builders or players percieve what is going on.

You should rather ask a builder (or whoever is going to use the language)
how they percieve the game, and try to express their mental model in the
programming language paradigm. Ofcause if the builders are all with
hard experience in C/Java programming, by all means do not choose a=20
declarative programming language. But if the language is to be used to=20
solve AI problems, i would choose a functional or declarative language.

If the language supposed to be control and monitoring of sorts, perhaps
a dataflow oriented language would be best.


For a simple imperical language, i'd personally prefer C-style (as im
most trained in that). Make sure you get=20

  variables
  arrays    (preferably dynamic)
  functions
  if/then/else/switch
  while/for
=20
.. and a nice interface to the game.

  seconday, you might want to experiment with user defined structures,
  but this depends on what tasks the language is used for, weather it
  is really needed.


Secondary to the design, is that the programmer should have some easy
measure for the complexity if the program. In some languages, this is
done less well (like prolog), but it is always nice to be able to
guess how efficient your program is.


Hans Henrik St=E6rfeldt   |    bombman at diku.dk    | work:  hhs at cbs.dtu.dk=
      |
address:                |___  +45 40383492    __|__       +45 45252425   =
  __|
 Dybendalsvej 74 2. th, | Scientific programmer at Center for Biological =
    |
 2720 Vanl=F8se, Danmark. |  Sequence Analysis, Technical University of D=
enmark|




_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev