[MUD-Dev] Languages

[Miroslav Silovic]

> [Miro:]
> 
> [Strong vs weak typing]
> 
> :Okay, a few examples: One of the situations that happens often is a function
> :returning either result or 'I couldn't do it'. With typed system, you need
> :to return two values explicitely. With untyped, you can return either a
> :list of (integer) 0 (assuming that result is a list).
> 
> Poor example. If a list is a first-class entity, then there will be a 'nil'
> value to represent 'no list', if that's what you need.

Okay, let me explain. Failure and empty list are *not* always the same
thing. Sometimes, empty list can be a valid result. For instance,
suppose you have a queue of objects that pass some sort of event
from one to the next, and suppose that there is also default action.
In this case, it might be desired that there is a way to turn off
default action. In this case, empty list *always* takes default action,
while failure does nothing.

Hey, ask any Scheme programmer - this is where I picked an example from. :)
(and since I use Scheme a lot, I learned to appreciate and use this
construct).

> :Another example is mixing plaintext and compiled hypertext. You can use
> :strings for plaintext and objects for pre-parsed hypertext type. It's
> :nice to be able to mix them freely.
> 
> What are you going to do with that list? Most likely you are going to
> send it to one or more clients, in which case you can have already
> expanded the hypertext thingies into their textual equivalent, and just
> return a single concatenated string. I don't have hypertext, but I do
> have all of my graphics/sound/etc. output to the custom client. I have
> builtins to send individual commands (binary encoded) to the clients,
> and to send strings to clients. They are all put together down at the
> message level, but there is no facility for bundling them up (other
> than as routines which will emit them) at a higher level. I can't think
> of anything I would do with such a bundled form that could not be done
> more efficiently at the generation stage.

You are wrong here - since I wrote parts of the Cold's hypertext system,
I'd know. The problem is that when you use object-oriented design for
hypertext, you need a way to pass it to the client objects. The problem
is that clients often want *different* output. (example: Cold supports
streaming HTML, like Pueblo, plain text, and ANSI highlighted text).
This means that you have to format hypertext for each client. And then
there should be a way to switch between hypertext and plaintext for
the same datastructure, as plaintext is much tighter, dbsize-wise.
So, for example, you can use both plaintext and hypertext for an
object description, and you *HAVE* to pass it as a raw object to
each client separately (yes, we considered pretty much every other
method we could think of. This pretty much *is* the best way). With
strongly-typed language, this is impossible to do. With ML-style
strong typing, you could use discriminated unions, though - but
I assumed you had something like C/C++ in mind when you talked about
strong typing, and both have jokes of typesystems.

> :Much harder example: consider a list of contents in a room. In strong
> :typed system, you will have to decide on their representation in advance.
> :But in a dynamically typed system, you could use integers (or symbol types)
> :to refer to commonly used objects (say, prepackaged weapons). Or you
> :could use objects from some lightweight class to refer to classes of
> :very similar objects, and still have the option of doing heavy-weight
> :things.
> 
> Ah, but as mentioned below, I only have one type of 'thing' - there is
> no heavy-weight versus lightweight. The idea never occurred to me, so
> I guess I didn't bump into anything that really needed it. As for using
> just an integer in a contents list, well that sounds like stretching it
> a bit - even in a combat MUD, you would need to know whether it was a
> weapon's attack points or armour defense points, etc. You would also
> need some way to describe it when the player does "take inventory".
> If you just want to attach an integer to the player, then use a property
> for that - there is no reason to try to jam everything into the list
> of what is being carried.

Of course there is: if you can do it, it's *MUCH* more elegant than the
alternative, which is managing 3-4 properties to deal with a single
concept. :)

As for the description, you miss the point again - for an item, you'd
create a master object, and then keep just 3-4 integers in the contents
list, basically object type and its age (if objects are wearing off with
use). Everything else can be stored on the master object. Of course,
I don't like MUDs with gather-equipment-then-go-out-and-kill centered
game all that much, but this is very valid option for them. :)
Remember, most LPs have problems precisely with this issue - when the
number of things grow high, their db explodes. This very much fixes
this issue, and you can /still/ make all the equipment permanent (i.e.
not lost in reboots).

> :You misunderstand. I refer to *FAST* development of robust code. Dynamically
> :typed languages, with some debugging facilities, won't let you get away
> :with too much, and they don't pester you with figuring declarations in
> :advance (again, I /know/ that ML doesn't either. But ML is also
> :non-trivial to implement from scratch).
> 
> Perhaps I'm a pessimist, but I think that "fast development of robust
> code" is an oxymoron - there ain't no such thing. Over the years, I've

You mean, you haven't seen such a thing? :) It's impossible in C, I
agree with that much.

> come to the conclusion that the most important feature a bunch of code
> can have is that of how maintainable it is. That is strongly tied to how
> readable it is. All code of any merit will be maintained, so I always
> write code with that in mind. If the code doesn't happen to have bugs,
> then you will be wanting to change what it does in some way.

I agree with this, though. Readability is important, but semantics
is also important - you can think of it as 'mental readability'.
The most important aspect of any development environment is its
effectiveness in removing the interdependancies of the modules.
(it can be measured by number of modules that must be changed after
a change in one module. Any change can provoke chain reaction, and
if average number of changes after one module was changed exceeds 1,
this will pretty much always be the case and that's the point where
program becomes unmaintainable).

I found that dynamic typing greatly helps here, because it allows you
to write functions according to what they /do/, regardless of what
kind of arguments they take.

> :You're certainly right here - it depends on individual experience. I
> :have great experience with dynamically typed systems (I hope you mean
> :'dynamically typed' as opposed to 'weakly typed' - those are not the same).
> 
> Can you clarify the differences for us?

Weak typing means that types are hidden from the programmer. Dynamic
typing means that types are tied to data. Strong typing means that
types are tied to the syntactic entities (such as variables, object
properties, return type declarations for functions etc).

MUSH is weakly typed, MOO is dynamically typed, for example.
Both C and ML are statically typed, and it turns out that in ML,
static typing is not evil (you don't see it, since ML figures most
variable types from the context, and then cross checks them during
compilation, and it also has mechanisms to deal with all 3 examples
I gave above).

> :Uhhh, okay, I misunderstood a bit - it's not that unsafe. But again,
> :why do you need it as part of the /language/ as opposed to part of the
> :language /implementaion/?
> 
> Umm, "its not that unsafe"? What is unsafe at all? And no, the fact that
> I can efficiently implement the language isn't necessarily part of the
> specification of the language, but it is certainly something that I will
> be concerned about just as much as the details of the language spec.

Don't worry about it too much. If Scheme can be compiled to run about
as fast as C, then anything else can. :)

To tie to your previous argument, the best way to design software
that is easy to maintain is to separate design from implementation.
In this particular case, language design affects *everything* else
you do, and programming language theory is advanced enough that you
can get pretty much everything to run fast (even tcl!)

	Miro