ID:138039
 
mob
verb test()
var x = "Yes!"
usr << x

Now, not only is it harder to tell the distinction between

mob/verb/test()

and

mob/verb_test()

but it also promotes much easier obfuscation! For example:

mob/verb test()
verb
name = "verb"


The same goes for the var/ part too... though it might be more work to type:

var/x
var/y
var/z

At least it is much easier to understand than

var x,y,z


Does anyone else agree? I have always disliked that C++ behaviour, and was pleased when I found BYOND did not do it... and now, BYOND is starting to do it! =P
Does anyone else agree? I have always disliked that C++ behaviour, and was pleased when I found BYOND did not do it... and now, BYOND is starting to do it! =P

I don't have anything against these newfangled gewgaws if the trusty old stuff doesn't break... I have to admit, though, that offhand I don't see a real compelling reason for me to adopt the new style. Any thoughts, Dantom?
In response to Gughunter
On 5/9/01 6:00 pm Gughunter wrote:
Does anyone else agree? I have always disliked that C++ behaviour, and was pleased when I found BYOND did not do it... and now, BYOND is starting to do it! =P

I don't have anything against these newfangled gewgaws if the trusty old stuff doesn't break... I have to admit, though, that offhand I don't see a real compelling reason for me to adopt the new style. Any thoughts, Dantom?

Leave me out of it! Dan just slipped this in without any consultation.

I don't expect to use it myself. I do like the:
var x,y,z
shorthand though.

I also think that the notation is fairly consistent, if you just treat the whitespace as a level of indentation, eg:
verb
test()
...
verb test()
...

I have to admit that I don't see much point in not using the / here, but it's not a big deal to me.

If the gurus object, I'm sure Dan would be amenable to removing this feature.
In response to Tom
Does anyone else agree?

Well now that I am used to the BYOND method I'm partial to and will use the old way.

BUT it is a major barrier to programmers when they see stuff they don't understand, and that syntax has in fact been pointed out to me as something other programmers don't understand, so I think it's fine to support the new way too.
In response to Deadron
ACK!
please dont do taht any more.
I too dont like these changes. i hope you can still use the old method as well (im not downloading hte patch until im sure you can)

the code works well as it is. so can you stop trying to fix somthig that isnt broken?
Can you stop messing with the commands we all know and love and instead add some of the new things we asked for? please?
In response to Mloren
On 5/10/01 3:09 am Mloren wrote:

I too dont like these changes. i hope you can still use the old method as well (im not downloading hte patch until im sure you can)

The old method will work fine, and since it is the only thing widely documented I assume that's what people should and will continue to use. This new notation just makes things a bit more compatible with existing languages, as Deadron noted. Again, if a lot of people really have that much problem with it I doubt it will be a problem to simply remove. I don't particularly care one way or the other.

the code works well as it is. so can you stop trying to fix somthig that isnt broken?

(1) Yes.

Can you stop messing with the commands we all know and love and instead add some of the new things we asked for? please?

(2) See (1).
In response to Tom
Again, if a lot of people really have that much problem with it I doubt it will be a problem to simply remove. I don't particularly care one way or the other.

Nah, as long as it doesn't break the existing ways, I don't have any problem at all with it.


Can you stop messing with the commands we all know and love and instead add some of the new things we asked for? please?

Especially first-person 3D! Mwah hah hah hah...

(Actually I think it could work pretty naturally with BYOND's existing ideas--but it would be a huge task for Dantom to code! Once they're rich from this version, though, they can hire people to help code the 3D enhancements.)

In response to Tom
As a student of computer languages, let me add my
two cents.

A language has a few notions that should be respected
in order for it to be usable.
One of them is readability, wich is how well the
code can be read.
Another is writability, wich means how easy it
is to write decent code.
A third notion is orthogonality, wich states
how much we have similar ways of doing similar things.

Taking this concepts in hand, we can consider how much
this language shortcut would impact in DM.

  1. It decreases readability, because even as it
    looks more similar to other comon languages such as C++,
    the one who is reading needs to be familiar with both syles.
  2. It enhances writability, because there are more
    ways that can be convenient for diferent coding styles.
  3. It decreases orthogonality, because, as you have
    more ways to do it, it can lead to confusion in respect to
    when you use each notation.


In summary, it depends on which of the concepts you intend
to focus. If you intend to increase writability, even
sacrificing some of the readability and orthogonality, go
for it.

In my personal opinion, I like the new adition, except for
the new way of declaring verb or proc settings, I think only
the "set" command is already enough.

Cheers,

Julio Monteiro


Tom wrote:
Leave me out of it! Dan just slipped this in without any consultation.

I don't expect to use it myself. I do like the:
var x,y,z
shorthand though.

I also think that the notation is fairly consistent, if you just treat the whitespace as a level of indentation, eg:
verb
test()
...
verb test()
...

I have to admit that I don't see much point in not using the / here, but it's not a big deal to me.

If the gurus object, I'm sure Dan would be amenable to removing this feature.
In response to Gughunter
On 5/10/01 6:24 am Gughunter wrote:
Especially first-person 3D! Mwah hah hah hah...

(Actually I think it could work pretty naturally with BYOND's existing ideas--but it would be a huge task for Dantom to code! Once they're rich from this version, though, they can hire people to help code the 3D enhancements.)

I agree that when the time comes, first person 3D could work very well within the current BYOND paradigm (ooh, neato management buzzword!). After all, it's just a different method of viewing the world. But a huge task? C'mon! The Quake I source code is freely available, so I figure it's about 10 minutes to download, plus another 5 minutes to add it to the BYOND source and recompile. Voila! ;-)
In response to Air Mapster
On 5/10/01 9:46 am Air Mapster wrote:
On 5/10/01 6:24 am Gughunter wrote:
Especially first-person 3D! Mwah hah hah hah...

(Actually I think it could work pretty naturally with BYOND's existing ideas--but it would be a huge task for Dantom to code! Once they're rich from this version, though, they can hire people to help code the 3D enhancements.)

I agree that when the time comes, first person 3D could work very well within the current BYOND paradigm (ooh, neato management buzzword!). After all, it's just a different method of viewing the world. But a huge task? C'mon! The Quake I source code is freely available, so I figure it's about 10 minutes to download, plus another 5 minutes to add it to the BYOND source and recompile. Voila! ;-)

Mapster, prior to your time on the board, you wouldn't believe the number of people who came in and said that about various features.

I remember one of them was ragging on us for not being "real programmers" cause we couldn't do the 10 minute job of putting together BYOND code that would automatically cut up an icon that was over 32x32.

I said something like "Great, since it would only take you 10 minutes and we could use that so much, why don't you go ahead and do it and post the code? We'd love you for it!"

Sadly, said person couldn't seem to find the 10 minutes.
In response to Monteiro
Great post Julio!

On 5/10/01 8:28 am Monteiro wrote:

A language has a few notions that should be respected
in order for it to be usable.
One of them is readability, wich is how well the
code can be read.
Another is writability, wich means how easy it
is to write decent code.
A third notion is orthogonality, wich states
how much we have similar ways of doing similar things.

I am a bit concerned with the third notion here. One reason I've always had a problem with Perl (and to a lesser extent C++) is that there seem to be so many shorthands to accomplish the same basic thing. DM has an inkling of this, and it does bother me a bit. I can see how this new syntax could add to the confusion a bit. On the other hand, it might just be thought of as another "indentation style" which would be consistent with the rest of the language.

As I said, I do like the
var x,y,z
shortcut, but that might just be because I'm so used to seeing that in other languages. I could do without the other stuff.

Hee hee. Looks like I opened a can of worms in my ten minutes of self gratification.

I agree with all of the comments made in this thread! In other words, I have mixed emotions about adding another way to do something which already works.

Perhaps the alternate methods for configuring verb and proc settings should go. At the time I was suddenly struck by the way <nobr><code>verb name = "Blah"</code></nobr> read so nicely, whereas <nobr><code>set name = "Blah"</code></nobr> is not as self evident. But having two ways to do it, just means the user has to be aware of both, as Julio pointed out.

The new var style, though, is going to be harder for me to live without. It is parsed almost exactly like the <code>if</code> statement where you can put a single line after it or multiple lines indented under it, so it seems quite consistent with DM syntax in general. Not only that, but it looks instantly familiar to programmers from almost any other language, whereas <code>var/x</code> must look downright odd.

But have no fear. Work on the real features continues! We have taken a bit of time to squeeze in some fairly low level things in the past few releases, because we wanted to get those in place before our final bid for stability. If you didn't find that too exciting, don't worry; this phase will pass, hopefully soon.

--Dan
In response to Dan
Hey theres an idea....
I know that changing to 3D wouldnt be easy, btu there are tons of engines already made lying around out there... how hard would it be to build a quake or half-life engine into byond?
In response to Mloren
On 5/10/01 6:44 pm Mloren wrote:
Hey theres an idea....
I know that changing to 3D wouldnt be easy, btu there are tons of engines already made lying around out there... how hard would it be to build a quake or half-life engine into byond?

I'll do it tonight!

Post these kinds of questions to babble please.