[713] in Coldmud discussion meeting

root meeting help first first in chain previous in chain previous next last

Re: more blah blah blah

daemon@ATHENA.MIT.EDU (Tue Mar 14 22:12:45 1995 )

From: jeffpk@netcom.com (Jeff Kesselman)
To: coldstuff-l@MIT.EDU, coldstuff@MIT.EDU, brandon@avon.declab.usu.edu
Date: Tue, 14 Mar 1995 19:06:30 -0800 (PST)
In-Reply-To: <m0roetf-000KcEC@serial> from "Robert de Forest" at Mar 14, 95 04:16:59 pm

> Sorry about the serial.YOUR.SITE.HERE, I'm not root on serial, but I'll pass
>  on the problem to someone who is...or he'll see me mention it here since he's
>  on the list.
> I don't intend to release a ColdMUD with an assignment expression. Brandon
>  will be releasing my change to his ColdX server. Based on these grounds I
>  think arguments based on 'C-- should be like C' are moot...or something. I
>  don't think we should restrict ourselves this way.

I actually, if it were the other way around I;d drop the point, but I;m 
VERY concerned about ColdX.  I see brandon doing development very much in 
the direction I'd like to see the server go. As such, I'm particualrly 
concerned tha this particualr banch of the cold-tree remain as accessible 
to newcopmers as possible, and to me C compatability is a new-comer 
accessability issue.

> A lot of what I'm saying may seem obvious or pointless but I want to stress the
>  idea that we get to choose every detail of the changes we make ourselves. We
>  should make the decisions based on goals and needs rather than history.

I'm not disagreeing. I just happent to think that ease of learning ColdC 
shoudl be a goal.  I assume we WANT this to become a general purpose 
tool, not just something for the amusement of the immediate group here 
(certainly thats the idea my book proposal was based on.)  In order to 
make it appeal to the widest possible audience, C compatability is a good 
thing, IMO.

> Some of you will say we _need_ to stay compatible to make the transition from
>  other languages as smooth as possible for new programmers. I totally agree. I
>  also feel there are enough differences already to make changes like this not
>  so crucial. 

Okay, one piont at a time.  I put forth three rules a ltitle whiel back 
fopr compatability.  I hope every one had a chance to look them over, 
though i havent had any comments back yet.  The fundemental concepts 
behind them is that like-functionality shoudl be expressed with 
like-synrax, varient-functionality should be expressed with varient 
syntax.  Thsi makes it obvious to the ewn comer what he does or doesn't 
understand.  break the frist rule, and you have him having to learn 
needless "translations" to read the code.  break the other and you will 
"trick" him into misinterpreting code.

> On top of that, people will be coming to ColdX from languages
>  other than MOO, C, and Pascal, and I suspect a large portion will come with no
>  experience.

C is still the closest thing to a lingua-franca the comp. sci. community 
has.  Its the clsoest to a standard we've ever reached.  I asume that 
this is why ColdC was originall ybased on C.  Otherwise, it proboboly 
should have been based on a more object oriuented language like Modula2 
or Smalltalk.

> All this rambling is to add weight to my assertion that '<-' is the best
>  best operator to use for assignment in the ColdX server. Its meaning agrees
>  fairly well with its visual structure. It does not in any way appear to be
>  a comparison. It suggests modification (through motion).
> I address the drawbacks as follows:
> "It's too different" - ColdX itself is very different. To keep '=' or change to
>   ':=' might suggest more similarity than is actually there (to whatever
>  language people come from).

As I said, sugegsting similarity where the functionality IS similar is 
good. Suggesting simialrity wher the functionality is different is BAD.  
Suggesting dissimilarity wher the function is similar is ALSO BAD IMO.

If we were starting from scratch with a  new language I'd be all for <-, 
I actually like it alot BUT I consdier the comaptability and learnability 
issues more important.

Jeff Kesselman