Code center > Darwinbots3
Command Shortcutting
Numsgil:
You can see all the current Sunweaver commands here: 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:
--- Code: ---5 .毒を作る
--- End code ---
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 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. 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?
Panda:
--- Quote from: Numsgil on April 08, 2015, 01:45:41 PM ---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).
--- End quote ---
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.
spike43884:
--- Quote from: Panda on April 08, 2015, 06:44:35 AM ---
--- Quote ---I know it takes extra typing, but only one set of alternatives won't be that hard.
--- End quote ---
--- Quote ---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.
--- End quote ---
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
--- Quote ---I know it takes extra typing, but only one set of alternatives won't be that hard.
--- End quote ---
--- Quote ---.attack
--- End quote ---
Well, rather than the original shoot, I want shot instead but Numsgil wants strike. Which ones do we include?
--- Quote ---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
--- End quote ---
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.
--- End quote ---
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.
Panda:
--- Quote from: spike43884 on April 09, 2015, 10:08:19 AM ---Oh I don't mind some-what of a compromise but crucially numsigl hasn't expressed any sort of willingness to a compromise.
--- End quote ---
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.
Numsgil:
--- Quote from: Panda on April 09, 2015, 01:14:16 PM ---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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version