pre-empting feedback on first build
Community Forums/Monkey2 Talk/pre-empting feedback on first build
| ||
| Hey Mark, Quick question about all of these language changes / tweaks / etc. If when you release the first build, there are certain elements that the majority of testers feel arn't quite right, what is the scope for these changing? For example if you release version 1 with case-insensitive keywords but then testers don't really get on well, is the language still open enough that you feel like you want to swap this kind of thing around? Are you looking for public approval on the aspects of the language before moving on, are are they set in stone upon release? Also do you consider that the language will massively fluctuate over development and are any new features added over time, more or less there to stay? |
| ||
| Do you really think somebody will struggle because of the choice/freedom to write "endif" / "EndIf" / "endIf" / "eNdIf"? |
| ||
| Yea it would be nice if mark create a list what is: - ready and will not be changed in the future - ready but will be removed within some months - not ready, and wil be changed soon so we can create some simple stuff, what is a little future proof. |
| ||
| > If when you release the first build, there are certain elements that the majority of testers feel arn't quite right, what is the scope for these changing? For new features, there is definitely scope for changes - a lot of the new stuff is just my first attempt and may change over time. I definitely want feedback on this side of things. But for existing monkey1 compatible stuff, there wont be any radical changes, only behind the scenes improvements (some which IMO are very important). I just don't see the point, given that I quite like monkey1 and this is supposed to be monkey2! So you will be able to safely write 'future proof' monkey1 style code using monkey2 V0.01, and will be able to take advantage of language improvements here. But new features will be more volatile... Keyword case is still a bit up-in-the-air. I'm OK with the current approach but it does have a practical downside: 3rd party IDEs aren't generally able to auto capitalize keywords, which wont stop stuff compiling but it could mean 2 'styles' of monkey source evolve. So I haven't decided 100% one way or the other here. |
| ||
| Didn't know case (in)sensitivity was on the table. I'm assuming that's for variables? Having always worked in VB, case sensitivity was one of those things that I thought would drive me nuts, but Monkey actually helped my discipline in capitalization a lot. There are some advantages to having case sensitivity, mainly scope and shadowing type things, and the aforementioned "gentle nudge" it gives towards having a consistent caps style. I noticed that even VS2013 still has trouble fixing the autocaps stuff with VB on some variables in some circumstances, so code can start to look messy if you're not careful and aware of it. Glad to hear that most of the underlying syntax from Monkey1 won't change. |
| ||
| @Nobuyuki: Didn't know case (in)sensitivity was on the table. I'm assuming that's for variables? Just for keywords. Variables will be case-sensitive as in Monkey 1. |
| ||
| Do you really think somebody will struggle because of the choice/freedom to write "endif" / "EndIf" / "endIf" / "eNdIf"? Probably not, but it's just an easy example to give to illustrate my question. For new features, there is definitely scope for changes - a lot of the new stuff is just my first attempt and may change over time. I definitely want feedback on this side of things. But for existing monkey1 compatible stuff, there wont be any radical changes, only behind the scenes improvements (some which IMO are very important). I just don't see the point, given that I quite like monkey1 and this is supposed to be monkey2! So you will be able to safely write 'future proof' monkey1 style code using monkey2 V0.01, and will be able to take advantage of language improvements here. But new features will be more volatile... Ok good to know in both aspects. I won't bank on porting any code for a while then. Will be cool to have a play with the new stuff, even if it does make me sad that I'll have to stick to monkey1 for the time being! |
| ||
| So you will be able to safely write 'future proof' monkey1 style code using monkey2 V0.01, So, does this mean I can safely write Monkey 1 code now and use it in Monkey 2? What does that mean?. :) There is one good reason I can think of for using both Monkey 1 and Monkey 2 to develop a project and that would be Mojo. Mojo1 supports older style / limited performance GPU's much better then mojo2 as far as performance on fill rates of say sprites (way evident on mobile devices). So it would be nice to have the Monkey 2 coding syntax and style compatible with Monkey 1 at some level. This would allow me to develop for lower end GPU's on Monkey 1 / Mojo1 and still support higher end GPU's with Monkey 2 / mojo2. I suppose that I could possibly import a gaming framework that would fit the project needs as described above, but all of them (current mainstream frameworks) would have the same retro GPU limitations as mojo2. I can definitely see an advantage for using both MX1 / Mojo1 and MX2 / Mojo2 together for development. |
   |