Darwinbots Forum
Code center => Darwinbots3 => Topic started by: spike43884 on March 29, 2015, 07:51:23 AM
-
Can we have for commands / operators in DB3 multiple names for them...Some people remember things differently you know :P
-
This is already supported in DB3's DNA language (Sunweaver) using object macros.
For instance, you can do something like:
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:
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:
def add mul
3 4 add
Will push 12 to the stack, because we've redefined add to be mul.
-
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.
-
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?
-
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 :D 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.
-
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?
-
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.
-
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 (http://www.joelonsoftware.com/articles/fog0000000069.html). And adding multiple commands that do literally exactly the same thing violates the principle of least surprise (http://en.wikipedia.org/wiki/Principle_of_least_astonishment).
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".
-
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 (http://www.joelonsoftware.com/articles/fog0000000069.html). And adding multiple commands that do literally exactly the same thing violates the principle of least surprise (http://en.wikipedia.org/wiki/Principle_of_least_astonishment).
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 (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
-
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 (http://en.wikipedia.org/wiki/Don%27t_repeat_yourself) and once-and-only-once (http://c2.com/cgi/wiki?OnceAndOnlyOnce). 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 (http://www.joshbarczak.com/blog/?p=154) 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 (http://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_do_it)). Here's a dev blog from foursquare (http://engineering.foursquare.com/2011/07/08/apiv2-woulda-coulda-shoulda/) 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 >:D
...
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 (http://jacquesmattheij.com/C+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:
' 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:
{eat
-1 shoot store
}
{move
1 up store
}
10 *eye5 >
move call
50 *eye5 >
eat call
-
You might like ruby (https://www.ruby-lang.org)
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.
-
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 (http://en.wikipedia.org/wiki/Don%27t_repeat_yourself) and once-and-only-once (http://c2.com/cgi/wiki?OnceAndOnlyOnce). 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 (http://www.joshbarczak.com/blog/?p=154) 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 (http://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_do_it)). Here's a dev blog from foursquare (http://engineering.foursquare.com/2011/07/08/apiv2-woulda-coulda-shoulda/) 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 >:D
...
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 (http://jacquesmattheij.com/C+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:
' 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:
{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?
-
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
-
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.
-
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.
-
You see, Im a person who solidly hates Lua. Its just not really very simple or understandable to me
Wow, you're so wrong haha :P Lua is one of the most elegant languages I've ever come across, because it's managed to create a very expressive language from a very simple set of rules, and it embeds very cleanly in other code. I was thinking as a long finger project there could be a version of Lua for the DNA language (over, say, Python) because it maps pretty well to things like codules.
What don't you like about Lua? Just syntax around how you define tables and metatables? Or something more foundational?
...
For DRY, it's about repetition (or rather, the lack of it), not simplicity or primitiveness or whatever else. The choice of language is completely orthogonal to not repeating yourself, so I'm not sure what you're getting at around binary. (Also, no one programs binary, that's so 1952. You'd program in Hex. Way more compact :P)
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.
You mean like #include or Import or etc. that other languages have? Sure, we could add that. I'll think through what makes the most sense and set up a todo item on it.
-
You see, Im a person who solidly hates Lua. Its just not really very simple or understandable to me
Wow, you're so wrong haha :P Lua is one of the most elegant languages I've ever come across, because it's managed to create a very expressive language from a very simple set of rules, and it embeds very cleanly in other code. I was thinking as a long finger project there could be a version of Lua for the DNA language (over, say, Python) because it maps pretty well to things like codules.
What don't you like about Lua? Just syntax around how you define tables and metatables? Or something more foundational?
...
For DRY, it's about repetition (or rather, the lack of it), not simplicity or primitiveness or whatever else. The choice of language is completely orthogonal to not repeating yourself, so I'm not sure what you're getting at around binary. (Also, no one programs binary, that's so 1952. You'd program in Hex. Way more compact :P)
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.
You mean like #include or Import or etc. that other languages have? Sure, we could add that. I'll think through what makes the most sense and set up a todo item on it.
See you see Lua as nice to program in, for me its overcomplicated. >PROOF< of my point. And im talking about binary because if were going to take DRY really seriously, lets start programming in binary again, nothings wrong with it. Its fast and efficient. I mean DRY wants you to only have one way to do something, so in binary you could make a big 'A' but instead you choose to use a second system by using C# to make a big 'A' appear on the screen, or maybe you'll use Lua to make a big 'A' on the screen...But thats using a 2nd, or 3rd method and not the original. Thus, you are violating the principles of DRY.
DRY is just a mere little idealism which only works if all humans were completely, to a genetic level identical and experienced exactly identical experiences. Currently cloning technology for humans is unavailable, so DRY isn't going to be at all successful yet. Theres over 2000 different programming languages (ONLY INCLUDING HIGH LEVEL ONES). Its complete proof of my point, stop being like a politician and throwing silly little puns and jokes to skirt around that you are merely, and completely wrong. DRY, does not work - at least in the present day. Now we wouldn't need many alternatives, maybe one full set of alternatives.
Heres some even more major proof of how majorly wrong DRY is, now don't get me wrong im not the biggest fan apple macs but this is just proof that DRY is wrong. Apple has become one of the biggest computer manufacturers, and apple macs sell incredibly fast...Yet they don't use your standard shortcuts that are tried and tested, for example on an apple mac i've used theres a ctrl key, but for shortcuts you need to use the cmd key instead.
How many more hundred examples do I have to give you before you give up.
-
ok so i've read the DRY link just enough to understand what's going on with it. now i'm going to ask, what in your own mind does DRY mean?
can you both do this without using any links nor in any way target one another in your descriptions please.
i only ask this because there is a misconception or miscommunication somewhere and often times there needs a 3rd neutral party to help solve the issue.
-
ok so i've read the DRY link just enough to understand what's going on with it. now i'm going to ask, what in your own mind does DRY mean?
can you both do this without using any links nor in any way target one another in your descriptions please.
i only ask this because there is a misconception or miscommunication somewhere and often times there needs a 3rd neutral party to help solve the issue.
DRY, to me from the link and from numsigl's description is pretty much, there should only be one way to do something.
Im just arguing with many examples showing that virtually nobody in the world actually uses DRY properly. Because to the very core level, then we should always be doing every bit of programming in binary, because using various programming languages is secondary, and tertiary methods of doing these things, especially high level languages. And thus my point that multiple methods is better, even if it be a few methods its much better. And with my point of command shortcutting, alternative commands aren't a different system, just a different...domain? Whereas the current alternative which DB2 uses which is inline conditioning is an alternative, certainly harder to read and write, yet its still used. Plus, he's pointing out that it'll be harder to read, but im not suggesting completely ridiculous alternatives which you really need lots of technical knowledge to understand like those in inline conditioning, you'd just have to quickly check which name its partnered with in the wiki. Reading thus stays the same difficulty as without alternative commands, and writing becomes easier...and quicker.
Heres another example, im a keen player of "minecraft" which you may have heard of, its got many plugins to add commands...and one of these plugins lets you use colours in chat and signs and names, but the standard command to access the infomation on the colours is /info colors which is the american way of spelling it, but when im typing I generally use my native language, which is UK english...so I kept typing /info colours by accident, and so did some other people on the server...Now this was only a few people making the mistake, in a over 200 player network, but the owner still introduced the shortcut /info colours...both are understandable when you read it, whatever version of english you use, but yet the /info colours is much easier for us british people and the /info colors was much easier for the americans...Its a simple example, which is very relevant and proves my point.
-
And im talking about binary because if were going to take DRY really seriously, lets start programming in binary again, nothings wrong with it. Its fast and efficient.
It can be fast and efficient (but not always) to run the code but not to write it. This is one of reasons you have different languages.
whatever version of english you use, but yet the /info colours is much easier for us british people and the /info colors was much easier for the americans...Its a simple example, which is very relevant and proves my point.
This argument is relying on the new commands making sense. I would argue that this is something that with the command "colour", it is something which is a lot more instinctive for users and is "built in" for them (and would probably just give a piece of mind to the server admin because people would have been complaining about it). However, once you learnt that "color" is correct, you can just learn to use it.
In the case of DarwinBots3, having multiple commands for the same thing would create a lot of extra work for the developers, us. It may be easier for you but it requires extra documentation and code. This increases the cost of development and maintenance and gives a higher probability for mistakes (e.g. dx representing 31 and aimdx representing 32, accidentally), as two examples of problems with doing this. If there's fewer commands, there's fewer things to look up for people who understand the original system, making it difficult for them to learn the code. If the documentation is good (which it hopefully will be) then you can just read the documentation.
Developers have to weigh up the usability for different users; what you're suggesting decreases usability for most other users, especially newer ones, and would likely only improve your experience.
-
In machine language you would repeat yourself quite often, often more efficient to duplicate a method than referencing it with a pointer. It's all about not having to do those steps yourself. Read the link about DRY again.
-
In machine language you would repeat yourself quite often, often more efficient to duplicate a method than referencing it with a pointer. It's all about not having to do those steps yourself. Read the link about DRY again.
Who is this aimed towards?
-
Sorry, aimed at spike.
-
I know it takes extra typing, but only one set of alternatives won't be that hard. Anyway, im not sure how your currently linking commands to memory address's but in a .txt file you could fit in alternatives dead easy, along with standard commands then just reference a line on the txt file.
Command,Alternative Command
Command,Alternative Command
each line just responding to the memory address of the same number...you could even do
Address,Command,Alternative Command
Address,Command,Alternative Command
to make it easier to remember. So writing the actual code shouldn't be much harder, especially with only 1 set of alternatives.
My point about color and colour is very relevant actually, its naturally built in. To people who have mastered DB as a language, then things like .dx and .aimdx and .sx and .aimsx are built in, you could recall it off the top. But for example, I haven't a clue which way .dx turns and which way .sx turns, Im just able to comprehend that they turn. sx and dx make no relevance to what I already know, or what most people already know. But lets give an example, in the format of that .txt list of commands I was talking about, (without using address in the actual file yet):
.dx,.left
.sx,.right
Now if your still really concerned about it taking longer to write, just send me a link to the current DB3 commands and just a quick link to the definitions of them and I'd personally write it.
Before you start moaning over its harder to read, it can be harder to read if we chose ridiculous ones, yes...But it can also be much easier to read, and lets use the .dx .left example here, Now normally you'd have a paragraph blabbering on about the function of .dx and you could keep that in for further referencing, but you could also have at the top of the page ".dx does the same as .left" which I'd more likely remember than a whole paragraph.
Then I'll give a quick simple example with animal_minimalis using current code, and just some off the top of my head alternatives:
Standard Commands:
'Animal_Minimalis
'By Nums
'Good For newbies to base bots off or learn DNA from
'Gene 1 Find Food
cond
*.eye5 0 >
*.refeye *.myeye !=
start
*.refveldx .dx store
*.refvelup 30 add .up store
stop
'Gene 2 Eat Food
cond
*.eye5 50 >
*.refeye *.myeye !=
start
-1 .shoot store
*.refvelup .up store
stop
'Gene 3 Avoid Family
cond
*.eye5 0 =
*.refeye *.myeye = or
start
314 rnd .aimdx store
stop
'Gene 4 Reproduce
cond
*.nrg 20000 >
start
10 .repro store
stop
end
Alternative Commands:
'Animal_Minimalis
'By Nums
'Good For newbies to base bots off or learn DNA from
'Gene 1 Find Food
condition
*.eyemiddle 0 >
*.enemyeye *.myeye !=
startcode
*.enemyvelocityleft .left store
*.enemyvelocityforward 30 sum .forward store
stopcode
'Gene 2 Eat Food
condition
*.eyemiddle 50 >
*.enemyeye *.myeye !=
startcode
-1 .attack store
*.enemyvelocityforward .forward store
stopcode
'Gene 3 Avoid Family
condition
*.eyemiddle 0 =
*.enemyeye *.myeye = either
startcode
314 random .left store
stopcode
'Gene 4 Reproduce
condition
*.energy 20000 >
startcode
10 .reproduce store
stopcode
enddna
Most of those alternatives are longer, but reading it...Most of them make quite a bit of sense don't they. The commands are much closer to english... Yet someone new to DB wouldn't have a clue what "NRG" was, is it some sort of sound the bots make?? But oh yeah, "energy" that stuff, I know that! and when they see that "NRG" is the same as "ENERGY" they don't need to read an entire paragraph do they? Now I might not use all of these personally, but .left i'd certainly use, expanding rnd to random I'd use...ABS you could call REDUCE because it reduces it to one of 3 values. Try to put yourself in the shoes of 'imbecile' thats never touched DB before. I know for certain when I started, the first 4 weeks or so that when I first glanced at the language it was so weirdly done, with weird names for simple things that I just stuck to putting random bots in evolution sims (Sidenote: can you bring back ebola to DB2 please, its amazing for evolution sims)
-
I know it takes extra typing, but only one set of alternatives won't be that hard.
Now if your still really concerned about it taking longer to write, just send me a link to the current DB3 commands and just a quick link to the definitions of them and I'd personally write it.
These both require future maintenance and can increase the number of locations in the code that errors can appear. If you decide that once you've put them in that you're no longer going to maintain them, it's up to somebody else to do it. What difference is there for you by doing this compared to
I know it takes extra typing, but only one set of alternatives won't be that hard.
.attack
Well, rather than the original shoot, I want shot instead but Numsgil wants strike. Which ones do we include?
Try to put yourself in the shoes of 'imbecile' thats never touched DB before. I know for certain when I started, the first 4 weeks or so that when I first glanced at the language it was so weirdly done, with weird names for simple things that I just stuck to putting random bots in evolution sims
By adding more variable names, new DBers are going to be further confused. There can be two bots written in 2 different ways that does the exactly same thing (especially in terms of stack manipulation, etc.), it doesn't make it easier for them at all.
Your concerns are not irrelevant or invalid; the variable names can be very obscure at times and I guess this will be something considered in DB3. Since it's completely separate to DB2, no variable names are required to be carried over from DB2. In the end, the
Despite this, a design decision has been made and it's not going to change. One of the biggest problems with DB2, in my opinion, was the amalgamation of different design decisions without communication between the start and the end. The concepts of DRY are being used despite your disagreements and it's clear that a large proportion of this community (currently 3 against 1 in this thread) agrees with this decision.
I'm going to put two points that will hopefully end this argument: it really is Numsgil's decision and we can only offer our opinions and discussions towards features (since he has been the developer for how many years); the feature you have requested is within DB3 (somewhat) and you have to compromise somewhere.
-
You can see all the current Sunweaver commands here: commands (http://svn.darwinbots.com/Darwinbots3/Trunk/Modules/Sunweaver/Source/Commands/). Note that's a pretty short list. I'll probably add cos to it, but otherwise it's pretty close to a final draft.
For .sx and .dx, they're abbreviations from Italian (sinastra is left, destra is right). Because the original author of Darwinbots is from Italy. If you don't speak Italian that's pretty confusing. But if you speak Italian it makes sense (presumably :P). Ah you say, that's your point. But we can't make it not confusing to everyone. If everything was in plain English that isn't going to help the guy that speaks Japanese. They might know English well enough for most things but I'm sure they don't know the word for venom or reproduction off the top of their head. Ah, but what if we just add all the japenese words/characteres for things in there too? We could do something like:
5 .毒を作る
But now if you come across a bot that looks like that as an English speaker you're going to have to go look stuff up. I certainly don't speak Japanese. So it doesn't help reading other people's bots.
Ah you say, but it's the bot writing that I want to make easier. But trying to make the language suit itself to everyone is an impossible challenge. Ask 10 different people what their ideal language would look like and you'll get back 12 different answers. By accepting that some things are going to be a little shitty for everyone we can at least work towards making the single way of doing things less shitty.
Is there an American bias going on here? Yes, absolutely. I happen to be American. But most programming languages have an American bias. Not even just an English one, but an American one. That's why it's "color" and not "colour" in HTML. Would HTML be better if it supported "colour" too? But then why stop there? Why not support all languages. Why not 色 and রঙ?
I don't mean that as a rhetorical straw man argument, either. The current computing landscape is so dominated by an American way of thinking (and not just American, but a West Coast way of thinking) that it's entirely possible that there's a thought monoculture going on and all sorts of interesting solutions to problems are simply never created because we're so locked in to thinking of problems in one specific way. Sapir-Whorf hypothesis (http://en.wikipedia.org/wiki/Linguistic_relativity) and all that.
But I'm not going to solve the problem of cultural American imperialism. I just don't have the time or nrg (;)). So I'm going to apologize upfront for any cultural imperialism I bring with me to the table, and defend myself by simply saying that it's the way things are (in the world at large). Things could be in Japanese. Or British English. Or Swahili. But trying to do all at once is too much. An arbitrary choice has to be made, so I made it. And it's a pretty defensible choice because I can point to all the other American English dominated computer languages out there. Which is itself indefensible cultural imperialism. But there you go.
...
Now rant aside, you can make your own sysvars aliases in DB2 already, and if you haven't you should look in to it. See def (http://wiki.darwinbots.com/w/Def). You can't make your own commands in DB2, but try playing with it and see if you can articulate what you don't like about it. If it's that you have to copy+paste it in to every new bot, we can look at #include/Import for Sunweaver. If it's that you don't want to have to write it the first time, I'll write you one to get started. But I'm not you and I don't know how you think, so the probability that it's going to be something you like is vanishingly small. If it's something else, let me know.
You should also try playing around with the new language, because while it's superficially similar there's enough differences to make things... different :). There's the (old) command line interpreter stickied which you've already posted in so I'm sure you've found it. I can also try and get Panda's IDE as a distributable and you can try writing DNA in that (no way to "execute" it at present, but it'll tell you about syntax errors). If there's specific usability problems you have in Sunweaver I'll try to think them over and fix them. I'm assuming at the least you're comfortable with the bool and int stack concepts from DB2? And about reverse polish notation?
-
So I'm going to apologize upfront for any cultural imperialism I bring with me to the table, and defend myself by simply saying that it's the way things are (in the world at large).
I don't think you need to apologise about this; I suppose you could express a desire for it to be different. It's the current standard that majority work towards. If we came to have an international community (further than American vs. British English) then the documentation could also become focused towards other languages. We lack both the need and motivation to do that since we're quite a niche community.
-
I know it takes extra typing, but only one set of alternatives won't be that hard.
Now if your still really concerned about it taking longer to write, just send me a link to the current DB3 commands and just a quick link to the definitions of them and I'd personally write it.
These both require future maintenance and can increase the number of locations in the code that errors can appear. If you decide that once you've put them in that you're no longer going to maintain them, it's up to somebody else to do it. What difference is there for you by doing this compared to
I know it takes extra typing, but only one set of alternatives won't be that hard.
.attack
Well, rather than the original shoot, I want shot instead but Numsgil wants strike. Which ones do we include?
Try to put yourself in the shoes of 'imbecile' thats never touched DB before. I know for certain when I started, the first 4 weeks or so that when I first glanced at the language it was so weirdly done, with weird names for simple things that I just stuck to putting random bots in evolution sims
By adding more variable names, new DBers are going to be further confused. There can be two bots written in 2 different ways that does the exactly same thing (especially in terms of stack manipulation, etc.), it doesn't make it easier for them at all.
Your concerns are not irrelevant or invalid; the variable names can be very obscure at times and I guess this will be something considered in DB3. Since it's completely separate to DB2, no variable names are required to be carried over from DB2. In the end, the
Despite this, a design decision has been made and it's not going to change. One of the biggest problems with DB2, in my opinion, was the amalgamation of different design decisions without communication between the start and the end. The concepts of DRY are being used despite your disagreements and it's clear that a large proportion of this community (currently 3 against 1 in this thread) agrees with this decision.
I'm going to put two points that will hopefully end this argument: it really is Numsgil's decision and we can only offer our opinions and discussions towards features (since he has been the developer for how many years); the feature you have requested is within DB3 (somewhat) and you have to compromise somewhere.
Oh I don't mind some-what of a compromise but crucially numsigl hasn't expressed any sort of willingness to a compromise. Im going to primarily tackle the point about New DB'ers being confused... The current names are confusing to new DB'ers and every name will need a little bit of learning, yet using completely new and different names to DB2 only will confuse the classic DB2'rs so if you don't have alternatives you have to make a choice between possibly losing the few remaining DB2'ers as they might not want to learn it again, or keep it forever more complicated for new DB'ers. *Roughly* one set of alternatives fits both sets of people, presuming they've learnt one set of commands...they just need to see which command that responds to in their set, you could have a 4 column table showing all the commands. Column 1 shows the primary name for it, Column 2 just gives a line of code with that primary name just to show how it may be used, Column 3 shows the secondary name for it, and Column 4 just gives a line of code with that secondary name just to show how it may be used. Then they just quickly glance at the table, Oh yeah ".strike" responds to ".shoot"
Plus, im confused what your getting at with your point of "maintaining it". It requires, well not really much more maintenance than the traditional single set of commands...You just have the alternative set reference the primary set?
Now to tackle nums point of "we can't cover everyone" is correct, im agreeing there but heres a bit of business to you, some actual business logic and not the mock-up plans that businessmen make normally. We can cover our primary groups of people. You say about well it wouldn't cover people that speak japanese, yet I haven't seen a post in the forums in japanese, currently all posts I've seen in the forums are in english (one form or another) or russian (yes, a few russian posts here and there) so we can identify those are our primary 2 groups. Now we can also note that the wiki is in english, and has a tutorial in russian backing up this assumption. Ok, now we can wittle it down further that a lot more of the current resources are in english. Putting languages a side of a moment, we have groups of learning styles people prefer, plus how experienced they are in programming languages and which programming languages they're experienced in this will effect how things would be described to make sense to them. Now to start we can have one set of alternatives, for a key point, we'll then have a system which we can see works code-wise for referencing alternative names...Then we have to tackle a command set for the biggest groups of learning styles/most popular programming languages to show some similarity in the names to what they would use...We can group similar ones together to save work. We primarily need to target these sets to work for people who speak english (of one form or another) and who speak russian. Lets say because english is the most notable language used in DB so far that the primary commands, and the secondary set are for english users, then if at a later date a tertiary set is created we can target russian-speaking individuals.
As in business, or many other thing as business is related to a lot of things in its philosophy, if you can't cover everyone, cover the most important people. Lets give a (some-what unrelated) example which can follow this hypothesis:
Your running a prison thats slightly understaffed, you have 3 sectors in this prison, Sector C - Which houses people who have committed fraud or similar offenses. Sector B - Which houses juvenile crimials and Sector A - Which houses people who have committed violent crime. A mass breakout is underway and you can only be certain to cover 2 sectors, if you attempt to cover 3 its almost certain criminals from all of the sectors will escape. Which two sectors do you choose? Well, of course its going to be Sector's A and C. Why? Well, Sector B houses juveniles which haven't likely commited crimes as major as sector A, but then why not let Sector C free? Well, because they could disapeer, they're crimes are often behind computer screens or on the black market so they're harder to catch.
Prioritising groups of people! This idea everyone is equal is a good idea to follow in social aspects, but realistically for marketing, or communicating that needs to be thrown out the window. I do know about def, but its nicer with the sometimes limited space of commands to reserve that for extra value storage, plus as i've stated before, you need to know what the original command does to be able to use def to make an alternative! Now if your going to be lazy and not even consider an alternative of any form, then an extra folder would be good then you can store .txt files in there and then you can have your alternatives in there. Im confortable with reverse polish notation but when I was new to DB2 it was a hell-hole. You see it doesn't take that much effort to make 1 set of alternatives, and actually...One set of alternatives is realistically all you need. If you have one single set, you encompass a system to accept alternative languages and DB is nicely opensource. Now opensource games get mods, or opensource programs get little plugins to add extra compatibility or extra features... Once you've created one set of alternatives, theres a way to make alternatives in DB3 and thus, combining that with the fact DB is opensource if a person who speaks japanese natively, but also knows british they will have a way to make a japanese alternative, then they can invite they're friends who only speak japanese...And so on! The fact is, all you need is to compromise to one set of alternatives! Its just like how DB2's language is some-what different to what you want DB3's language to be, DB3 is an alternative to DB2, which is an alternative to DB.
-
Oh I don't mind some-what of a compromise but crucially numsigl hasn't expressed any sort of willingness to a compromise.
The feature already exists, just not in the way you want it. He has also given you additional options like #include which would remove all of your . The way that you want it implemented goes against the design.
The main problem with introducing one alternative is that we have to introduce more (since somebody else might feel strongly about a specific naming).
Maintenance would include, bugfixes, documentation, redesign etc.
Despite all of this, Numsgil, are .sx and .dx going to be retained for DB3? They are both obscure and it adds to the learning curve for newbies and, well, I can never remember the difference (but I haven't ever programmed bots for long enough). The only reason that I can see for keeping it would be in homage to the original creator or to keep some familiarity to older users. However, I don't know how fussed other users would be with keeping it.
-
Despite all of this, Numsgil, are .sx and .dx going to be retained for DB3? They are both obscure and it adds to the learning curve for newbies and, well, I can never remember the difference (but I haven't ever programmed bots for long enough). The only reason that I can see for keeping it would be in homage to the original creator or to keep some familiarity to older users. However, I don't know how fussed other users would be with keeping it.
I'm not married to DB2 sysvar names. More to the point I think the way the bots will control will be so different as to render most of the sysvars in DB2 moot. So for instance, for dx and sx, you probably don't control your torque directly like that. Instead you induce a flow across various panels to produce the torque. That is, if your shape was a square, you'd induce a rightward fluid flow along the top panel, a downwards flow across the right panel, and leftwards flow across the bottom panel, and an upward flow across the left panel, and the net result is (should be) a net torque and you'll turn. This simulates things like cilia that real cells have. Controlling that in DNA in a way that makes sense is an open problem. But it points to how very different things should end up being in DB3.
Other different things, just to run through the list real quick: shots are basically gone, at least as the primary weapons. Instead you'd try to either lyse (break open) the other cell and drink in its guts as they're released to the fluid around you or you'd engulf them inside yourself and try to break them down with digestive enzymes over time. So all the shot commands are pretty moot.
To reproduce, you'd have to build up some panels to separate yourself in two and then split. Which would take more than one cycle certainly. Again, the exact control scheme is up in the air, but certainly a simple repro sysvar is insufficient.
Basic metabolism will include at the very least nrg like we have now plus some amino acid analog (maybe more than one, maybe just one, depending on how important I think having multiple possible limiting resources is) that is used to build up "organelles" like chloroplasts, the panels themselves, "motors" used to control the shape of the bot, etc. etc., plus something like sugars/fats for long term nrg storage (converting between nrg and fats is throttled by something like a mitochondria organelle and how much bandwidth it has for conversions). The fdbody/strbody sysvars are primitive in comparison.
Even things like eyes, where I don't have exact plans but a few different possible approximate plans, it's going to be way more complex than the eye1-eye9 in DB2, so those sysvars don't really apply either.
However I would like to keep the sysvar names fairly short and compact, so in that way similar to what DB2 does. I'm going to avoid long names like build_a_chloroplast in favor of something like mkchloro. But at the very least there'll be some sensical naming scheme. Like all sysvars that create things (panels, substances, etc.) are prefixed with "mk" for "make" maybe. That sort of thing. It gets hard because some things cells do don't really have a common word for them. Like inducing a flow across a panel like I was talking about earlier using cilia. You could maybe call it "rowing", but that's a pretty coarse comparison. And even though a lot of the concepts map to cellular biology if I label everything with words like "lyse" and "phagocytosis" I'm sure I'm going to lose some significant portion of my audience.
So I'll need to spend some time and be clever with the terms and names. When things get that far I'll make suggestions and try to get feedback on the forums.
-
Yeah, that's what I was thinking. To be honest, I think the subject of alternate variable names is irrelevant, at the moment, since this has only arisen due to "obscure" variable names.
-
I do know about def, but its nicer with the sometimes limited space of commands to reserve that for extra value storage
You can def to a memory location def'd by something else. So what I'm saying is if you don't like how the in/out pairs are labelled you can invent your own labels for them.
plus as i've stated before, you need to know what the original command does to be able to use def to make an alternative!
That's true no matter how many command alternatives there are. Lets say you see random instead of rand. Well you know it's supposed to produce something random, but what and how? You don't even know if it's a binary, unary or nullary(?) command. Certainly all sysvars are like that, in terms of what they actually do. Like most things in life you have to RTFM (http://wiki.darwinbots.com/w/Sysvars).
If you remember what the sysvar you want is but don't remember what it's called, that's a good opportunity to make your own. Or just copy+paste it from somewhere else you've used it before.
you encompass a system to accept alternative languages and DB is nicely opensource. Now opensource games get mods, or opensource programs get little plugins to add extra compatibility or extra features...
(http://forum.darwinbots.com/index.php?action=dlattach;topic=6774.0;attach=1728)
http://svn.darwinbots.com/Darwinbots2/ (http://svn.darwinbots.com/Darwinbots2/)
then an extra folder would be good then you can store .txt files in there and then you can have your alternatives in there
What a great idea! Let me propose the syntax to define the set of alternatives to look like this:
def alternative original
Then you just need some way to copy+paste the contents of one of these text files in to the bot you're writing. Well, not copy+paste, since you want any changes you make in your alternatives file to be automatically reflected in any bot you write. So something that lets you specify where the text file lives on disk and the program can automatically copy+paste it in there for you when you load your bot in the program.
How does that sound?
-
then an extra folder would be good then you can store .txt files in there and then you can have your alternatives in there
What a great idea! Let me propose the syntax to define the set of alternatives to look like this:
def alternative original
Then you just need some way to copy+paste the contents of one of these text files in to the bot you're writing. Well, not copy+paste, since you want any changes you make in your alternatives file to be automatically reflected in any bot you write. So something that lets you specify where the text file lives on disk and the program can automatically copy+paste it in there for you when you load your bot in the program.
How does that sound?
Sharing that bot would become difficult, wouldn't it?
-
Yeah, that's true. We'd need something that aggregated those text files and your bot code together in to a single txt file probably.
-
That is something that could be completed by the IDE before it is shared, perhaps "export to single file" functionality.
-
I do know about def, but its nicer with the sometimes limited space of commands to reserve that for extra value storage
You can def to a memory location def'd by something else. So what I'm saying is if you don't like how the in/out pairs are labelled you can invent your own labels for them.
plus as i've stated before, you need to know what the original command does to be able to use def to make an alternative!
That's true no matter how many command alternatives there are. Lets say you see random instead of rand. Well you know it's supposed to produce something random, but what and how? You don't even know if it's a binary, unary or nullary(?) command. Certainly all sysvars are like that, in terms of what they actually do. Like most things in life you have to RTFM (http://wiki.darwinbots.com/w/Sysvars).
If you remember what the sysvar you want is but don't remember what it's called, that's a good opportunity to make your own. Or just copy+paste it from somewhere else you've used it before.
you encompass a system to accept alternative languages and DB is nicely opensource. Now opensource games get mods, or opensource programs get little plugins to add extra compatibility or extra features...
(http://forum.darwinbots.com/index.php?action=dlattach;topic=6774.0;attach=1728)
http://svn.darwinbots.com/Darwinbots2/ (http://svn.darwinbots.com/Darwinbots2/)
then an extra folder would be good then you can store .txt files in there and then you can have your alternatives in there
What a great idea! Let me propose the syntax to define the set of alternatives to look like this:
def alternative original
Then you just need some way to copy+paste the contents of one of these text files in to the bot you're writing. Well, not copy+paste, since you want any changes you make in your alternatives file to be automatically reflected in any bot you write. So something that lets you specify where the text file lives on disk and the program can automatically copy+paste it in there for you when you load your bot in the program.
How does that sound?
I am pleased. A compromise atlast, Thanks to the fact that DB is opensource (YES, I SAID IT AGAIN :3) A good few of those should crop up, possibly a section for the DB3 forums called "Alternate Command Sets".
:) Yep, im happy! Just like how we can install a new font to word easily :3