What features do you wish were in smilebasic?

Well, then you deal with it I guess. Adding and subtracting 1 isn't too slow anyway. But SB is precompiled, so array, string, etc. accessing could be converted to 0 indexing there. I should get some people from the QB64 forums.. Then you would be outnumbered. Even your keyboard doesn't like 0 indexing! See how the number keys are arranged: "1234567890"? Now, even I think 0123456789 would be better, but it's too late for that. (this point isn't really meant to be taken seriously...)

I'll get some C, C++, C#, D, Java, and more people. QB64 would be decimated. I hate to be blunt like this, but 99% of the languages that actually matter use 0-indexing.

I'll get some C, C++, C#, D, Java, and more people. QB64 would be decimated. I hate to be blunt like this, but 99% of the languages that actually matter use 0-indexing.

That isn't a reason.... all of your alphabetized languages can f*** off. I know about the "It's a tradition" argument, and even though I think 1-indexing is much better, I think that giving people an OPTION would be the best solution...

We have found a compromise! .5 indexing!!!

What if we're using an interpreted language like SB and we want speed but are limited because of the environment?

Exactly. You can say "we can just compile it" but what if that isn't the case? What if the index isn't a fixed number; what if it's a variable like A#[I%]? Even in the case of a compiled language, we would have to subtract 1 from that variable every time to obtain the index. The compiler can't just magically say "this value will always be one less than what it is." Things are the way they are for very important reasons. If we always sacrificed efficiency for convenience, our world wouldn't get anywhere.

We have found a compromise! .5 indexing!!!

Edit: my 2 cents on the matter are thus: The way I see it, SmileBOOM is trying to do two things with SmileBASIC and all preceding iterations: 1. Create an environment in which it's fun to code games and programs in a personal way, as it was with BASIC in the 1970s/1980s. 2. Create an approachable way for complete beginners to code for the first time in their lives. The answer lies in 2. You see, many of today's esteemed programmers, and especially game developers, started their way with small, home-made BASIC programs. SmileBASIC might help create the "next generation" of programmers... And in that sense, there's no need to "dumb things down" for them. Sure, we don't need to be aware of drawing operations, of v-sync or h-sync, or of drivers interfacing with various features of the 3DS. But we also don't need to be treated like we're dumb. In many ways, SmileBASIC is preparing would-be programmers for their next challenge, and their next language - and in the real world, that means using 0-based indexing. SmileBASIC has many convenient abstractions, yes, but it's not a toy - when you get down to it, every technical aspect of it is completely serious, and opts for real-world programming practices rather than layman-intuitive practices every time. The best example I can think of is this: http://smilebasicsource.com/forum?ftid=544 Arrays are assigned as pointers, not as values. To someone like Mariominer this was so unintuitive that he considered it a bug - and I don't blame him! But in fact, this system is not only similar to just about every real-world programming language, it also allows the programmer to do some things that can't be done otherwise. For example, modify an array by passing it as a parameter to a function defined in DEF. So I completely think the decision to use 0-indexing is a wise one.

We have found a compromise! .5 indexing!!!

The best example I can think of is this: http://smilebasicsource.com/forum?ftid=544 Arrays are assigned as pointers, not as values. To someone like Mariominer this was so unintuitive that he considered it a bug - and I don't blame him!

Sorry to nitpick this little part, but I saw this as a bug just because it seemed so off from what everything else acted as - without pointers. But I do agree with pretty much all of your argument, this is very much preparing for more "real" programming languages, and the 0 parsing is a technical thing - the array X points to the data at point (X) in memory, and the number inside the brackets is adding to the pointer (so like in C X+1 is the same as X[1] I believe, though don't quote me on this.) The technical thing is as it should be. Thus, I agree with NeatNit and for these reasons I urge you to vote for the negative side - the Status Quo makes sense. But "to each their own", if you really believe that 1-indexing is how it should be, then that's your opinion.

I agree I like 0 when working with memory offsets. then again nobody is stopping me from doing ARRAY[ I AND 256] and then treating it as 1 or 0 based index as long as it is 256 in length, but know that sort and rsort may not treat it correctly. I agree with "size" typed variable that are allowed to overflow. would prevent the need for "I AND 256" cause the index would overflow safely. and people modify'ing the authors program would just have to realize its 0 or 1 based indexing. When working with chip select lines (on other hardware, not sb 3ds) you can't just move stuff around cause the chip is no longer selected when working with that kinda hardware, but I agree a compiler option can solve that.

The ambassador GBA games can't sleep because they run in AGB_FIRM, the hardware GBA mode left over from the DS hardware used in the system. It's simply not supported by GBA hardware. To elaborate on sleep mode, applications are set to trigger and run an interrupt routine when the system sleeps. They do things in sleep mode, but since the system disables a lot of features and components (such as the screen) they use very little power. For most games it's just waiting for the system to wake and perhaps preserving game state, but other apps do more complex things (of which I can't give any examples.) In the case of SB, they put the interpreter into standby and basically wait until you wake up, whilst updating MAINCNT. It's entirely possible for them to implement a routine that triggers when sleep happens (similar to SPCALL and CALL SPRITE), but they would probably have to check the routine's code manually to make sure it doesn't execute anything illegal while asleep. This won't work at all the way the precompiler is currently set up.

since MAINCNT still updates, we can detect a large jump in MAINCNT and detect we just came out of sleep. but not really do anything during sleep. also string-zero or size-string based storage of strings which leads to wishing strings were accessible via array access. I don't remember if they end in zero in SB or have a size value first.

It would be nice if we didn't have to use closing parenthesis at the end of lines

It would be nice if we didn't have to use closing parenthesis at the end of lines

This has the same problems as not using closing quotations though. It's just not proper syntax and looks ugly. Good syntax is to close the parenthesis and is likely a very important part in the reading of the code.

Also every command should have a 1 symbol equivalent like PRINT and ? (This was meant to be a stupid idea like the previous one, but now that I think about it, the same concept could be used to make a code compressor)

This was meant to be a stupid idea

Please stop wasting time with stupid ideas. It is obnoxious. You're not doing anyone any favours.

This was meant to be a stupid idea

Please stop wasting time with stupid ideas. It is obnoxious. You're not doing anyone any favours.

Rekt

also string-zero or size-string based storage of strings which leads to wishing strings were accessible via array access. I don't remember if they end in zero in SB or have a size value first.

Not sure what you mean. This is a feature.

S$="TEST STRING"
PRINT S$[2] 'prints S

They're zero-indexed and their last value is the last character, at size-1, if that's what you're asking. S$[0] would be T and S$[10] would be G. Size is just obtained with LEN.

incvoid: you could use COPY. Something like COPY T$,S$,5,5

don't think that works if S$[5,5,5] and T$[5,5] copy says it ignores dimensions but I'm having trouble as soon as I specify a number of elements or offset so I'd be back to manually copying the slices of the array S$[0,i,j] to T$[i,j] I think. It works when going from 3 dimensions to one (if T$ was single dimension)I haven't tried copying backwards 1 to 3 or 2 to 3 Edit'd too soon, now it appears to be working. it'll copy. wasn't working cause I had set T$[0,0], the empty MDA doesn't get resized. it says subscript out of range even with count of 1. Which it'd be nice if it told ya which array had a bad subscript(destination subscript out of range. still doesn't solve that I have a new array, copied, and not the single or double dimension array reference. No array of array :( I even have to access T$ using 3 dimensions after doing T$=S$ if I remember right same thing with passed parameters, if I make a function that takes an array, I think it has to be the use the same dimensions.

Let's imagine you have an array S%[2,3] and an array T%[3]. The structure is abstracted like this:

S%
   0  1  2
  +-------
0 |1  2  3
1 |6  7  8

In memory, it's stored linearly like this:

S%
0 1 2 3 4 5
-----------
1 2 3 6 7 8

When you use COPY, the data is treated in its linear representation. To get the second row, for example, you would set the start index of COPY to 3, and the amount to copy out as 3. The contents would be written linearly to T%

I wish they would let us use the IR port for things like data transfer and other things like proximity sensors.

yes, but nintendo doesn't want data transfer.