[MUD-Dev] Languages

[Chris Gray]

[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.

: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.

: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.

:> Personally, I'd much rather work with code that wasn't "spewed at blinding
:> speed" - it is much more likely to work properly, and to handle the
:> inevitable exceptional cases. I think what it comes down to is the
:
: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
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.

: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?

:> Hmm. I *think* I might know what you were getting at. No, I don't mean
:> other ways to reference locals behind the scenes - there are no
:> pointers or "reference" types. What I was trying to say was that you
:> don't need the name of a local to reference it at run time - the
:> interpreted code just needs the pointer to the current traceback
:> record, and the offset of the variable.
:
: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.

--
Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA