Command Shortcutting

[spike43884]

Can we have for commands / operators in DB3 multiple names for them...Some people remember things differently you know

[Numsgil]

This is already supported in DB3's DNA language (Sunweaver) using object macros.

For instance, you can do something like:

Code: [Select]

def superadd mul

3 4 superadd

And it'll push 12 on to the stack, same as if you called mul.

...

It can also "undefine" commands.  So you could do:

Code: [Select]

def superadd

3 superadd

And it'll leave 3 on the stack untouched, because superadd is not defined as anything (or more precisely, it's defined as an empty codule).

...

You can also redefine basic commands, because object macros have priority over everything else, including built in commands.  eg:

Code: [Select]

def add mul

3 4 add

Will push 12 to the stack, because we've redefined add to be mul.

[spike43884]

I mean though, not manually reseting some but just built in alternatives. like .dx and .aimdx and .aimright do the same, because not everyone might remember dx but some people may still prefer dx. Just alternatives built in.

[Numsgil]

I mean though, not manually reseting some but just built in alternatives. like .dx and .aimdx and .aimright do the same, because not everyone might remember dx but some people may still prefer dx. Just alternatives built in.

Why is that better than just building your own?

[spike43884]

I mean though, not manually reseting some but just built in alternatives. like .dx and .aimdx and .aimright do the same, because not everyone might remember dx but some people may still prefer dx. Just alternatives built in.

Why is that better than just building your own?

Because you can't build your own if you don't know what it originally does.
Plus, manual changes take time. Time wasting everyone hates.


OFFTOPIC: Considering you work for google, and google (and pretty much any company in the spotlight) has to like education, why not have a darwinbots schools league? It fits in to STEM, it'd be brilliant a DB schools league, various students from the school create a bot for their team, then its put into a nice big league. Of course then google might even give you a big computer to run the leagues on An with the central terminal with video outputs, we can stream the simulation straight to the students, they can have all the info at their hands, and watch it unfold. Then some quick simple programming to automate the leagues more and Boom! And before you go "No, no no, its not that good" DB is the best opensource life simulation thats there for free, and nobody else has done a life simulations schools league thats remotely notable.

[Numsgil]

Because you can't build your own if you don't know what it originally does.

I would think having multiple commands that do the same thing would make that worse.  You'd have a hard time reading code because you'd constantly find commands that you weren't familiar with and have to look up what they do.  "What's the difference between mul and superadd?" "Oh nothing, they both do the same thing." Then why have two commands at all?

[spike43884]

Because you can't build your own if you don't know what it originally does.

I would think having multiple commands that do the same thing would make that worse.  You'd have a hard time reading code because you'd constantly find commands that you weren't familiar with and have to look up what they do.  "What's the difference between mul and superadd?" "Oh nothing, they both do the same thing." Then why have two commands at all?

Reading code might be slightly more difficult, but no more difficult than if you didn't know the command in the first place, it only slightly slows down the reading of DNA, but incredibly speeds up the writing. Anyway, you could say that point and stick to it, but then DB2 added inline conditioning which is 10 times worse to someone who can't do it, then the professionals reverted to that. So primarily, balancing out the pro's and con's its a good thing really.

[Numsgil]

Reading code might be slightly more difficult, but no more difficult than if you didn't know the command in the first place, it only slightly slows down the reading of DNA, but incredibly speeds up the writing.

Without any hint of irony I'm going to tell you that reading code is harder than writing code.  And adding multiple commands that do literally exactly the same thing violates the principle of least surprise.

Again, if you want to rename all the commands, add your own, remove existing ones, etc. you can do all that with the tools in the current version of Sunweaver.  But trying to make the language as broad as possible to make as many people as possible happy is a recipe for a design without a cohesive "vision".

[spike43884]

Reading code might be slightly more difficult, but no more difficult than if you didn't know the command in the first place, it only slightly slows down the reading of DNA, but incredibly speeds up the writing.

Without any hint of irony I'm going to tell you that reading code is harder than writing code.  And adding multiple commands that do literally exactly the same thing violates the principle of least surprise.

Again, if you want to rename all the commands, add your own, remove existing ones, etc. you can do all that with the tools in the current version of Sunweaver.  But trying to make the language as broad as possible to make as many people as possible happy is a recipe for a design without a cohesive "vision".

Heres a quote from far up the page on the principle of least suprise:

A textbook formulation is "People are part of the system. The design should match the user's experience, expectations, and mental models." What is least surprising may however depend on the expected audience, e.g. end users, programmers or system administrators.

Of course as it mentions, what is least suprising may change depending on audience. Its a relatively simple rule, for example an athlete-grade training machine might have to utilise the entire athletes jargon, as an entry-grade one would have to avoid all the athletes jargon, to make it more functional and/or understandable. Of course theres the one solution, have it so its more flexible, being able to switch between jargon and non-jargon. Multiple words for the same thing.

My point dear sir, is now proven. One command does not fit all, thus multiple commands are needed. Now your constant point of reading, and especially reading being harder than writing is total nonsence. They see a command they don't know the exact term for, they can look it up seeing that superadd is the same as abs, and they now know it. But a command is much easier to understand presuming you can use a name thats memorable to its function for you specifically. The mind simply doesn't memorise an entire article word for word, but it can memorise the title which then reinforces the memory of meaning. Learning the alternative for an already known command is easy. Finally, reading certainly isn't harder than writing as even a general rule, let alone a 100% of the time rule. You see there are 3 main learning catagories/styles: Kinastetic (doing), Visual (seeing) and Audio (hearing). Reading is much harder for a kinastetic person to utilise to master, but writing the code helps them a lot more, a Visual person would benefit from reading the code, and watching the simulation, an audio person would do best from hearing someone explain it to them (audio can also extend to a digital conversation sometimes as to read you must speak what your reading in your head). Im Visual-Kinastetic & closely followed by Audio but I can promise you, reading the code is a lot easier in a lot of cases, except for when people do naughty programming and don't factor in 'allowances' or readable code (see here http://www.petesqbsite.com/sections/tutorials/tuts/writing_understandable_code.html). Its a bit like how normally programming languages have nested blocks and such. So its more organised, more readable. Now some of the structural features DB can't incorporate as it needs to be psuedo-natural atleast. But simple things like easier to understand names, makes it much easier. Its just another step on instead of having to do 10 .999 store being able to do 10 .example store

[Numsgil]

This gets in to philosophy of programming territory.  There are different schools of thought on the matter, but they're all wrong but one

I'm a big believer in DRY and once-and-only-once.  That conviction comes from years of programming in projects that adhere to that and projects that don't.  You aren't going to unconvince me of that.  It's also a fairly common attitude among pretty much everyone I've ever met or worked with.  eg: OpenGL is broken claims one of the "broken" things about OpenGL is that there's too many ways to do the same thing.  It's one of the major things Python is reacting to in its design (see There's more than one way to do it).  Here's a dev blog from foursquare where he says (emphasis not added mind you):

On the flip side, we decided not to have deeply nested URLs, e.g. users/USER_ID/tips/TIP_ID, instead opting for flat tips/TIP_ID. This led to much simpler URLs. And having only one path for, say, the details about a tip, let us avoid making developers choose between multiple ways to do the same thing. As a bonus, this explicit, DRY approach to API design makes monitoring and debugging much easier.

If you're of the mindset that the entire community of programmers has everything wrong and are doing it wrong, you're going to find no sympathy from me; I'm one of them 

...

Even if I provided 17 different ways of doing everything, it might happen that everyone that isn't you programs their bots with the "standard" instructions.  It's not going to help you reading their code.  Maybe you need help reading/writing your own code?  Maybe you're Brazilian and you want to program in Portuguese.  You can do that with the object macros.  Really the object macros are in many ways more powerful than what most proper programming languages outside of C/C++ offer.  There's no similar functionality in C#.  It was specifically left out to avoid the sort of Preprocessor hell that many developers don't like in C/C++.  I added it for Sunweaver because it was the easiest way to allow users to provide their own custom commands and extend the language, not because I think it's a grand way of organizing code.

...

Now some of the structural features DB can't incorporate as it needs to be psuedo-natural atleast.

Sure it can.  You can do it in DB2 right now, eg:

Code: [Select]

' In proximate range
10 *.eye5 >
  1 .up store
 
  ' In point-blank range
  50 *.eye5 >
    -1 .shoot store

Or in Sunweaver you can go one step further:

Code: [Select]

{eat
  -1 shoot store
}

{move
  1 up store
}

10 *eye5 >
  move call
  50 *eye5 >
    eat call


[Peter]

You might like ruby
As far I know it's the only language that got several method synonyms.* It's a easy language to learn, easy to write. May (generally) be harder to read other people's code.

*Perl got some of them too, but I think that's more because of legacy.

[spike43884]

This gets in to philosophy of programming territory.  There are different schools of thought on the matter, but they're all wrong but one

I'm a big believer in DRY and once-and-only-once.  That conviction comes from years of programming in projects that adhere to that and projects that don't.  You aren't going to unconvince me of that.  It's also a fairly common attitude among pretty much everyone I've ever met or worked with.  eg: OpenGL is broken claims one of the "broken" things about OpenGL is that there's too many ways to do the same thing.  It's one of the major things Python is reacting to in its design (see There's more than one way to do it).  Here's a dev blog from foursquare where he says (emphasis not added mind you):

On the flip side, we decided not to have deeply nested URLs, e.g. users/USER_ID/tips/TIP_ID, instead opting for flat tips/TIP_ID. This led to much simpler URLs. And having only one path for, say, the details about a tip, let us avoid making developers choose between multiple ways to do the same thing. As a bonus, this explicit, DRY approach to API design makes monitoring and debugging much easier.

If you're of the mindset that the entire community of programmers has everything wrong and are doing it wrong, you're going to find no sympathy from me; I'm one of them 

...

Even if I provided 17 different ways of doing everything, it might happen that everyone that isn't you programs their bots with the "standard" instructions.  It's not going to help you reading their code.  Maybe you need help reading/writing your own code?  Maybe you're Brazilian and you want to program in Portuguese.  You can do that with the object macros.  Really the object macros are in many ways more powerful than what most proper programming languages outside of C/C++ offer.  There's no similar functionality in C#.  It was specifically left out to avoid the sort of Preprocessor hell that many developers don't like in C/C++.  I added it for Sunweaver because it was the easiest way to allow users to provide their own custom commands and extend the language, not because I think it's a grand way of organizing code.

...

Now some of the structural features DB can't incorporate as it needs to be psuedo-natural atleast.

Sure it can.  You can do it in DB2 right now, eg:

Code: [Select]

' In proximate range
10 *.eye5 >
  1 .up store
 
  ' In point-blank range
  50 *.eye5 >
    -1 .shoot store

Or in Sunweaver you can go one step further:

Code: [Select]

{eat
  -1 shoot store
}

{move
  1 up store
}

10 *eye5 >
  move call
  50 *eye5 >
    eat call


1stly - Not all of the programming community thinks exactly like you numsigl. In every single aspect, nor do they all think like me. Don't believe your using the method 99% of people approve of, theres many methods people believe are right. We could go even deeper, why not just use binary. Its beautifally simple, and quick to run but instead we made, hundreds, upon hundreds of languages to program in, which do the same thing, translate it into binary. Why? because we think differently! YES, WE THINK DIFFERENTLY! I know it might be some sort of marvellous revelation to you, but if your still thinking about how it should certainly follow "99.999% of the programming community" with using DRY & OAOO then make every bit of DB3 in binary, without using any other language.

You see, Im a person who solidly hates Lua. Its just not really very simple or understandable to me, but I adore HTML and enjoy Python. Because people write things differently. Plus you'll most likely encounter the chance that one person may use multiple of the names for one command for when their doing a different task, like they might use a lot of rotation then .up in a pondmode bot, because your litterally going up, against the simulations gravity...but might use .forward in a non-pondmode sim, because your going forward and not against gravity.

Also, to your point alternative commands make it harder to read...Would you rather read 1000 lines of JAVA, or 1000 lines of SUNWEAVER or would you prefer to read 100000 lines of BINARY, because currently your suggesting you'd rather read the 100000 lines of BINARY.

Now I admit, and im happy to admit that theirs a chance I'll be the only one to EVER use the alternative commands, but that chance is tiny, absolutely tiny. And before you say that im talking balony, how many people do you know that write every part of all of the programming projects they ever do in binary, or even in the same language for every single part of every single project they've ever, and will ever do. That chance that all of them only program in binary my dear friend is tiny.

Finally to my statement that not all of the organisation things can/are implemented in DB2/DB3 is quite clear because we can't make an external file which is referenced to store X part of data, a bit like how you have a seperate CSS in HTML.


P.S. Responce to Peter talking about ruby: I might try out ruby some time then, i've heard of it but never used it or read its code...What is it used to program normally?

[spike43884]

Heres a simpler way to put it, if you want to do DRY then without using any sort of translator or tool to translate/interpret it for you tell me what this says in english:
01001101 01111001 00100000 01100100 01100101 01100001 01110010 00100000 01100110 01110010 01101001 01100101 01101110 01100100 00101100 00100000 01111001 01101111 01110101 01110010 00100000 01110000 01101000 01101001 01101100 01101111 01110011 01101111 01110000 01101000 01111001 00100000 01101001 01110011 00100000 01110100 01100101 01110010 01110010 01101001 01100010 01101100 01100101 00100000 01110111 01110010 01101111 01101110 01100111 00101110 00100000 01001110 01101111 01110111 00100000 01110011 01110100 01101111 01110000 00100000 01100010 01100101 01101001 01101110 01100111 00100000 01110011 01110100 01110101 01100010 01100010 01101111 01110010 01101110 00100000 01100001 01101110 01100100 00100000 01110011 01110101 01110010 01110010 01100101 01101110 01100100 01100101 01110010 00100000 01110100 01101111 00100000 01110100 01101000 01100101 00100000 01100101 01110110 01101001 01100100 01100101 01101110 01100011 01100101 00100000 01110000 01110010 01100101 01110011 01100101 01101110 01110100 01100101 01100100 00100000 01100010 01100101 01100110 01101111 01110010 01100101 00100000 01111001 01101111 01110101 00101110

[Panda]

Heres a simpler way to put it, if you want to do DRY then without using any sort of translator or tool to translate/interpret it for you tell me what this says in english:
01001101 01111001 00100000 01100100 01100101 01100001 01110010 00100000 01100110 01110010 01101001 01100101 01101110 01100100 00101100 00100000 01111001 01101111 01110101 01110010 00100000 01110000 01101000 01101001 01101100 01101111 01110011 01101111 01110000 01101000 01111001 00100000 01101001 01110011 00100000 01110100 01100101 01110010 01110010 01101001 01100010 01101100 01100101 00100000 01110111 01110010 01101111 01101110 01100111 00101110 00100000 01001110 01101111 01110111 00100000 01110011 01110100 01101111 01110000 00100000 01100010 01100101 01101001 01101110 01100111 00100000 01110011 01110100 01110101 01100010 01100010 01101111 01110010 01101110 00100000 01100001 01101110 01100100 00100000 01110011 01110101 01110010 01110010 01100101 01101110 01100100 01100101 01110010 00100000 01110100 01101111 00100000 01110100 01101000 01100101 00100000 01100101 01110110 01101001 01100100 01100101 01101110 01100011 01100101 00100000 01110000 01110010 01100101 01110011 01100101 01101110 01110100 01100101 01100100 00100000 01100010 01100101 01100110 01101111 01110010 01100101 00100000 01111001 01101111 01110101 00101110

I'm pretty sure for DRY, you would be expected to use a sort of translator/tool for that to say something in English (but nobody would write it like that in the first place using DRY) - there is reason for software and libraries having documentation, partly for everybody to agree on a standard. I agree with Numsgil here, a single standard would be better than, probably, obfuscating code (if everybody would just write things in different ways).

In any case, it would not take that long for you to learn the new commands, even if you do make mistakes on the way. Hopefully, the IDE will help you will them.

[Peter]

I don't get the issue, you can add synonyms yourself. You're better at picking the synonyms you like than Numsgil would be.

Philosophy of python is to have one obvious way to code it, isn't that the opposite of what you want. They stripped quite some functions in python 3, just because they wanted to limit the possibilities to program the same task.

I know they use Ruby(on rails) for websites, might be more. I really haven't done a lot with it.