Monkey and Max
Community Forums/Monkey Talk/Monkey and Max
| ||
| So, how do Monkey and BlitzMax fit together? It seems to me that Monkey does pretty much everything Max does on the Mac and PC fronts using a GLFW target, with the added bonus of supporting more targets. Thoughts? |
| ||
| ...Monkey doesn't support pointers? On the one hand, the result seems clear: Monkey supersedes Max in most important respects (I'm guessing the performance is better too when compiled with the right targets). On the other hand, unlike Max vs. Classic Blitz, there's no particular reason to see BlitzMax as obsolescent, so does it matter? (If the communities for the older languages are anything to go by, Max itself is not going to disappear any time soon.) I don't know to what extent it's been discussed already, but what are the odds of things like a homegrown 3D engine appearing? Rather small I would have thought, because it sounds like it would be far more complex to force to fit with the many platforms. So for a large subset of more demanding games and applications - which BlitzMax has shown it handles very well - there won't be any real advantage in moving to Monkey (e.g. Leadwerks will still be Windows-only or whatever it is). I would naturally expect the Monkey community to tend towards only developing more cross-platform libraries, too. Last edited 2011 |
| ||
| Using Monkey for Windows, wouldnt you be limiting your customers to just OpenGL? I think when Monkey is stable and feature rich, I will use it to develop games for iOS, Flash and Android, but still use BlitzMax for Windows and Mac OSX. Last edited 2011 |
| ||
| Using Monkey for Windows, wouldnt you be limiting your customers to just OpenGL? Some people see black and white. I can see a whole rainbow of opportunities! Monkey is awesome. It is (at least) matching my expectations so far. It has so much raw potential. |
| ||
| Good answer, Yasha. To clarify my position, I am not in any way implying or complaining that Max is 'superseded'. It is, however, hard for me to justify starting a project in Max when Monkey opens so many more targets up, and the two languages are just that little bit different enough that porting from one to the other would be a pain. If only Money could spit out Max! |
| ||
| I think when Monkey is stable and feature rich, I will use it to develop games for iOS, Flash and Android, but still use BlitzMax for Windows and Mac OSX. I had wondered about the same thing. Perhaps if I'm making more "Indie" titles and not casual portal ones, then going OpenGL only is acceptable... |
| ||
| My point of view about BlitzMax and Monkey. BlitzMax is targeted on Mac, Linux and Windows - it has many modules ready for do (pratically) anything (from database to image recognition), it has GUI - wx and MaxGUI, maybe QT - you can do games and applications. Monkey is targeted -mainly- for mobile world: Android, iOS, WindowsPhone, Flash and HTML5, and XNA (I still dont' see any great use without a 3d engine on a console...) For me win32, mac and linux support is only a *plus* - Mark has learned how to do it with BlitzMax and the 'cost' to port it is/was very low (even if he choose to use new library/tool-chain). For me they servers 2 different markets. |
| ||
| I think to a large degree it depends on your game design. Beside of this it for sure doesn't hurt waiting for a few more updates. Doing OpenGL on Windows for sure hurts a lot more if you're using it on a complexity level like Unity would, instead of the simple drawing commands you're having in monkey. I would be interested to know if certain language enhancements (Classes, +=, End, Case Sensitivity) will also make it into BlitzMax. BlitzMax surprisingly feels rather quickly awkyard in this respect. Last edited 2011 |
| ||
| I would be interested to know if certain language enhancements (Classes, +=, End, Case Sensitivity) will also make it into BlitzMax. You can't make those sorts of big changes to a language several years into development; too much existing code would break (read: all of it). |
| ||
| It would be nice to see if overloading could make it. I dont think it would break any code, cos the longnameing workround (ie MakeIntIntLongFloat) would still work. The chance of it breaking something in Bmax itself would shy me away Last edited 2011 |
| ||
| I'm also wondering what Monkey could do for me that BlitzMax couldn't do or that BlitzMax would have done for me if it had gotten the royal treatment. Was it necessary to create yet another new language instead of just "upgrading" BlitzMax to be a 64-Bit compiler on the desktop with additional mobile phone back-ends? Somehow, I doubt that. BRL now has FOUR languages on sale, and I wonder how such a small company is going to support them. My guess is that three of those products are now in COBOL - read: maintenance - mode and only Monkey is getting serious attention for the time being. And that is until BRL decides to create a new product, and then the cycle starts all over again. I think there are two problems at work here. One is BRL's business model of "buy once, get all upgrades for free forever". Once the saturation point is reached, you need to come up with a new product to keep the cash flowing, and with limited resources, this can only mean that from then on the already existing products only get the lowest possible minimum of attention from the company that created them. I guess the second problem is interest - or lack of interest, to be more precise. Maintaining the same product over years becomes BORING, and you just need a new challenge after a while. Thus goodbye BlitzMax, Blitz3D and BlitzBasic and enter Monkey. And I guess in three to five years, we will see the next new language coming from BRL and Monkey will then enter the COBOL phase. I cannot say that I blame BRL for that, I can absolutely understand it from their perspective. But from my personal perspective, I currently have some difficulties evaluating this new product and its possible place in my own little world. I am also not so sure about my willingness to buy into yet another new and most likely rather short-lived endeavor. I wonder if going for one of the competing, subscription-based products might not get me something more reliable on the long run. Some people see black and white. I can see a whole rainbow of opportunities! Yes, sure. But BlitzMax had exactly the same opportunities, it's just that the decision was made to invest into a new product instead of adding all those features to the one with the great potential that was already out there. For example, Mark very specifically said that BlitzMax wouldn't ever get 64-Bit support, and a couple of days ago you, Brucey, posted that Monkey obviously could be used to create 64-Bit code. Well, since it "only" translates to other languages, this is hardly surprising, but still noteworthy in this context. We've also repeatedly heard the rumors that an ARM-back-end for the BlitzMax compiler was on the drafting board or in the works. Now Monkey can do it; it cannot talk to a database nor does it know how to do multi-threading , but at least it can create mobile phone games. But which BRL product do you use when you want to create GUI apps for the desktop and a mobile phone? Unless Brucey decides to take Monkey to the next level by releasing his Qt port and porting a bunch of his other valuable modules, Monkey won't be an option - not even for non-games mobile phone apps. Anyway. I think we've had similar discussions before, and the answer can only be an individual one. Personally, I'm not (yet) sold on Monkey and its promises. Its only interesting aspect for me at this point is its ability to create mobile phone apps, and here I must admit that I find the Corona SDK much more convincing. I haven't bought either product yet, and I will sit it out for a few more days. (I've also very recently bought a new house, and that project currently has a much higher priority anyway.) I have an emotional weak spot for BRL products (and I like Zombie Trailer Park), so even if I think that Corona SDK looks more mature and complete, I probably will eventually still go for Monkey anyway. Well, let's wait and see what will happen. |
| ||
| Some good points, Winni, but I'm not sure that there will be any 'all new' languages from BRL in the future. We know that a complete re-write was required after the B+/B3D era for a couple of sound architectural reasons: 1. B3D was too tightly bound to DX7. Max remedies this by splitting that kind of code out into modules. 2. Max brought multi-platform support and a bunch of modern language enhancements. I'm assuming it has been written with upgrade-ability in mind. I think with Max and Monkey, Mark has covered all the bases, and for that reason, I don't envisage any more new languages, however you have a great point about the payment model. I can imagine the revenue dropping off quickly after a new product reaches saturation. |
| ||
| Mark very specifically said that BlitzMax wouldn't ever get 64-Bit support Most probably because it requires a re-write of the assembler generator or something... (I've no idea how unscalable assm code is) Since I can now generate C++ from Blitz/Monkey, I can build it on any platform, conceivably. My Qt translator generates Qt-friendlier C++ (for example I use QString rather than Monkey's own String, amongst other things). I'm also interested in generating ObjC directly. This will sit better for me on OS X than C++, and make life easier mixing it with all those pretty OS X things :-) As for modules using other libraries... I haven't worked out how to have a module build itself a static library yet. It's not impossible - hell, all the source code is there to do with what I can dream up with it - just requires some problem solving. Given that it's only been out for a week or so, and given that BlitzMax once was not so capable either... things can only improve :-) |
| ||
| I don't think Monkey does anything near as much as BMax at the moment. Can't even change resolutions in Monkey code. Ah yeah, I agree with Brucey. It can only get better. And even one new command is a bugger, considering it has to work on all platforms identically. Probably makes a new command take nth longer than supporting only 3 platforms like BMax. Last edited 2011 |
| ||
| just "upgrading" BlitzMax to be a 64-Bit compiler on the desktop with additional mobile phone back-ends? There are two points that I believe are worthy of consideration here. 1) Developing Monkey was the exact opposite task from that. New front-end, no back-end. Backends are hard to develop and not very interesting to most people (I don't know what Mark enjoys doing, but from the other products front-end seems like a good bet). Front-ends are where the real fun is, and are a lot easier to write; not only that, but he's developed six products by working on one rather than having to redevelop the same thing six times with little ability to share implementation details. This is a big deal. 2) Which end do users care about? It's true that the BlitzMax compiler was an order-of-magnitude leap forward from Classic Blitz (term I am going to use from now on for +/3D), but people who use it mainly do so because of the friendly syntax and large variety of modules. Front-end stuff. Combine this with the fact that no matter how good Mark is, he's never going to write a compiler that can compete with GCC on the -O3 setting, and it becomes obvious that the effort in writing backends is largely not being appreciated by the intended audience. Instead... how about giving the people what they actually ask for (constant arguing over properties and operator overloading), and let GCC and other extremely mature compilers (that already have backends for every hardware platform more complex than a lightswitch) do the heavy lifting in the background. It's not cynical, it's a good design decision that takes advantage of existing tools. Last edited 2011 |
| ||
| I share Winni's concerns about BlitzMax vs Monkey. On several occasions, I proposed BlitzMax switch to a subscription model to reward future upgrades and maintenance. Didn't hear any shouts of approval from Blitz users. Now Monkey isn't subscription either. I imagine Apple will break some things with OSX Lion. Some of you may know already. Good to see is Brucey enthusiastic about Monkey! |
| ||
| Currently: bmax has more features, more libs and stuff behind it. Future: monkey gets more libs, features and stuff and that's somewhat an end of Bmax. Case "Threaded http request": 1) There was no option to make http request using Monkey. 2) People asked about it 3) Tim from Indiepath wrote module for HTML5 target: http://www.monkeycoder.co.nz/Community/posts.php?topic=137 4) Somebody (marc or coder monkeys) will expand it further and provide http requests for new targets ...and that makes Monkey to catch bmax. One banana at a time. It takes time for monkey to mature, so right now bmax has its use. Maybe at future it won't have, and to be honest: who cares? Since monkey syntax is pretty identical to bmax and price is reasonable, and at some point it's quite certain that monkey can handle bmax + more... so I see no reason why not to switch to monkey when it's mature enough. |
| ||
| There are already lots of user made additions for Monkey: 1) Embedding assets in swf files 2) Stoptimer class 3) Exiting Android (and other targets) apps 4) Threaded HTTP requests 5) Adding new targets to Monkey and GNU C++ compiler for Windows and Mac 6) Encode as Base64 function (to embed binary files into html code) 7) HideMouse function 8) lots more (have to read the Monkey forums to find them all) I think I will make a bigger list of all user made additions, then Mark can also read that list and decide what he wants to implement officially in Monkey. Last edited 2011 |
| ||
| @Yasha I think you can and if it makes sense and comes with a benefit, then you also should do this. Exchanging some of this stuff could be done by search&replace already. |
| ||
| Exchanging some of this stuff could be done by search&replace already Not really the point. You could safely add some of the features - += syntax can probably exist safely in parallel with :+, and class parameters have no equivalent and therefore wouldn't clash with anything. But BlitzMax is case-insensitive, has an End statement, and probably many other things. If you changed the syntax to match Monkey in those areas dozens of existing programs would no longer work as expected. This isn't just not acceptable, it would pretty much be actively malicious on the part of Mark. The fact that the changes can be accounted for easily, is no reason to force people to either go through potentially tens of thousands of lines of code with Find-and-Replace, or no longer update their compilers and create some kind of forked community. |
| ||
| I think this is acceptable. I would prefer if coding in BlitzMax and monkey would go more hand in hand where it's possible in the future. I don't mind changing a few lines of old code therefore. |
| ||
| I agree, you can't just go changing Max at this stage. I really don't see why Mark made some of the minor distinctions that kill compatibility with Max. 'Class' instead of 'Type'... to appease the C++ fanboys and add an extra char to type? '+=' doesn't read as well as ':+' in my book.... again a C-ism. In nesting season, it's a lot easier to glance at the code with endifs, endfunctions and nexts rather than a sea of ends. I really don't understand case sensitivity, as in, why? Now I spend time chasing case bugs that wouldn't have been bugs before. Anyone who uses the same variable name for more than one thing differentiated only by case should earn a guest appearance on the Muppet Show, IMO. Last edited 2011 Last edited 2011 |
| ||
| It's not C-ism, but universalism. Class is used by Java, Flash/ActionScript, C# (has nothing to do with C/C++), Monkey. += is also used by most of those, but none use :+. You don't have to use End either, but you can add your End What also, it shouldn't really matter what it says, because nested blocks are always in the same column. Case sensitivity is good, because it forces people to write cleaner looking code. I have to read code like soMeVaRIAble = SomEVariaBLE + 1. It also makes searching harder, because you can't do a case sensitive search if the programmer has written his code in random upper/lower case, and without case sensitive search it would find all kind of additional stuff which you were not looking for. Last edited 2011 |
| ||
| Oh... I've just found a big hole : there's no way to know when your class instance is about to be freed (in BlitzMax you'd put stuff in the Delete() method). Fair enough that JavaScript and AS3 don't support this, but as far as I know, C++, Java and C# do. It's kind of useful at times... Ho hum... As for the use of the word Class. I prefer it. Since I've always wanted to say "superclass" instead of "supertype" for a super type... now I can say "superclass"! And as Lumooja says, you can put words after "End" if you want. I prefer to write things like "End Method". |
| ||
| It's not C-ism, but universalism. We could argue semantics, however it's 'universal' because everyone copied C++. Myself I would prefer to be in the same universe as Blitzmax. You don't have to use End either, but you can add your End What also, it shouldn't really matter what it says, because nested blocks are always in the same column. Ooh I wasn't aware of that. I like that option. For me, it takes longer to pick the aligned indents in a big nest without the helpers. Case sensitivity is good, because it forces people to write cleaner looking code. I have to read code like soMeVaRIAble = SomEVariaBLE + 1 Well I think you're in a unique situation reading code of someone with perfect indentation that at the same time writes something like that. At least in max, it is instantly obvious what that means. Your imagined idiot coder could cause even greater havoc in Monkey with something like'aBc=(aBC+aBc)*ABc' Case sensitivity compounds the problem. |
| ||
| it's 'universal' because everyone copied C++ Maybe. Once you get theoretical though, it's important to draw a distinction between types and classes as they can mean very different things (e.g. Haskell uses both words for related concepts). Your mileage may vary on "class", but "type" is not that good a choice either, although on the other hand consistency is a good thing. To chime in on case-sensitivity: I've always felt that a good IDE ought to solve this matter for you. What I'd really like is an IDE that has the option to turn off case-sensitivity as a code option, and autocorrect the caseless identifier to match the declaration (this is also because I'd like to be able to forget about case when writing in other languages, such as C). Last edited 2011 |
| ||
| To chime in on case-sensitivity: I've always felt that a good IDE ought to solve this matter for you. What I'd really like is an IDE that has the option to turn off case-sensitivity as a code option, and autocorrect the caseless identifier to match the declaration (this is also because I'd like to be able to forget about case when writing in other languages, such as C). Definitely the winning solution. When I'm fixing case issues in Monkey, it feels like a real step backwards. |
| ||
| I've always felt that a good IDE ought to solve this matter for you I use a text editor... and the command-line... I guess that puts me in a minority of one? I haven't had any case issues yet - since I am fairly consistent with the keyboard. Perhaps because I am also used to case-sensitve Java. It becomes second-nature to type it right first time :-) |
| ||
| Come on secretly you enjoy living on the edge here. ;O) Regarding case sensitivity, meanwhile i'm very happy that it's in monkey, would be cool if BlitzMax would use it too. Last edited 2011 |
| ||
| Regarding case sensitivity, meanwhile i'm very happy that it's in monkey, would be cool if BlitzMax would use it too. I don't know. Pascal was one of the strictest languages (and for good reasons) that I've ever used, but even Niklas Wirth didn't believe that his language should also be case sensitive. I don't see that necessity either, especially not when the language itself is case-insensitive and applies case sensitivity only on identifiers. All other case sensitive-languages that I know enforce that case sensitivity everywhere for consistency. I think mixing case sensitivity and insensitivity rules in a language is a bad idea -- either be strict all the way or not strict at all. Strange compromises are just confusing. |
| ||
| Well, you can take advantage of it and for instance differ your naming for variables and functions this way. If you do this properly than it can be a benefit. Regarding monkey, the IDE automatically puts monkey's commands into the right upper/lower case shape. So, as soon as you save&compile via the IDE it's updated automatically for you. It can be an issue as soon as you have to deal with code from others who have their own style. I guess i would dislike it more if i wouldn't have been forced to go case sensitive in Unity since years. Last edited 2011 |
| ||
| 'Class' instead of 'Type'... to appease the C++ fanboys and add an extra char to type? I would not say it had anything to do with C++ fanboys It is a universal notation in all OOP languages. When you use 5 ort 6 different languages, it becomes much easier with standard terms and notations. In the rest of the programming world types and classes are not -quite- the same thing.In many OOP languages "Type" and "Class" are BOTH keywords and have quite different purposes. Basically a "class" defines a object's "type". (or class-ifies it you could say :D) Anyway what is wrong with running a few search and replaces? Type to Class, +: to += etc... Last edited 2011 |
| ||
| renaming type to class isnt bad, its the strict mode thats the problem, its super strict, so it takes ages to convert any strict program. Last edited 2011 |
| ||
| IMO languages should be superstrict from the start. I hate all this dual case, non-declaritive nonsense. It makes code as you say endless to convert and is a real pain in the bum. I don't like implicity either (eg.. var myvariable or $myvariable) but it is better than no declaration - as long as a declaration is forced and enforced by either the IDE or compiler. Last edited 2011 |
| ||
| IMO languages should be superstrict from the start Either that or dynamic. One of the things I never understood about BlitzMax is why non-Strict is actually semantically the same as Strict - logically leaving type information off ought to make a variable non-typed (at least in my twisted mind), not strongly-typed to something you didn't declare. (I understand that it's mainly grandfathered in from B3D where integers were the dynamic data type for all practical purposes... doesn't mean I like it.) Last edited 2011 |
| ||
| Ya b3d was horrible for that, i remember the afternoons wasted debugging spelling mistakes. Last edited 2011 |
| ||
| > Ya b3d was horrible for that, i remember the afternoons wasted debugging spelling mistakes. I eventually put all my variables in types, it made catching the typos easy. |
| ||
| It is a good idea, and sometimes i use a Global "Globals" type too, but IO to a type in b3d is quite slow compared to using normal variables/arrays etc... especially in intensive loops etc.. the threshold being about 5+ references before it is quicker to simply unload it into temp vars... do the intense bit and then write it back (if needed) Last edited 2011 |
| ||
| I never ran into a speed problem (I was never doing anything really intesive anyway). Should be easy enough to fix though, when ready to do a release globally replace the type name with blanks. |
| ||
| Lol, not a bad idea that...(so long as your fieldnames don't match any locals) :D although i still think strict would have been better in the first place ;) Last edited 2011 |
| ||
| > Lol, not a bad idea that...(so long as your fieldnames don't match any locals) :D Oops, instead of changing the type name to blanks, I would change it to g_ (for global variable). Locals would be l_ and parmaters p_ (some people hate it, but it works wonders when trying to name variables - no need to come up with unique locals when wanting to use a similar global) > although i still think strict would have been better in the first place ;) Agreed! Last edited 2011 |
| ||
| i still think strict would have been better in the first place ;) For the benefit of any B3D users reading this far... IDEal (third-party IDE for B3D) has a Strict mode option. It's extremely useful. (Also, my original point about non-Strict was actually complaining about untyped variables defaulting to Int, rather than to a dynamic "var" type. Seems to have been lost.) Last edited 2011 |
| ||
| Make a game in BlitzMax for Mac and Windows and use Monkey for porting on Iphone ,iPad and Android looks like good solution :) Last edited 2011 |
| ||
| Well, there are a few things I miss in monkey comming from BMax: Direct pixel acces (basically pixmaps) OpenGL commands (HTML 5 can cover this with WebGL which is really really fresh out the oven, but flash doesn't really have an alternative as far as I know - maybe Shockwave?. EDIT: XNA is out of the question as well on this one) Proper file saving/loading (having the game scan a whole folder for maps/addons/etc. is great for development - no recompile needed when adding content) However, for our current project, monkey is perfect. Last edited 2011 |
| ||
| Just got a few comments to add, if I may. First of all I have to agree with some of the others above, Max is a far more complete and developed product designed to target PC and Mac, Monkey(lol) is designed to target mobile devices. So Write your PC game in Max, write your mobile , xbox game in Monkey(lol) One last thing, I don't recall who said it, I read this on my phone, but some one above suggested a more subscription or paying for update model, dear god NO!!. just NO!!. there are two reason I own almost all of Marks products, 1 is that I get the updates, and the other is that I simply love the syntax of the language, if he moved to that sort of pay for update content I would not buy another product, actually this is why I did not get the GUI stuff, I never saw it as a stand alone product but more an update so refused to buy it. I am actually glad that Monkey(lol) is a stand alone product, if he made it an upgrade to max and sold it id never buy that either, but thankfully he didnt, and as a result, eventually when I scrape the money together I will be buying it. So Mark, Keep it coming, keep the updates free, and I have no problem with you bringing out a new more upto date faster cooler language every 5 or 6 years, just one thing, can you please for the love of god stop naming your products and let some one else do it. Not that monkey is a bad name really, just not good for what your using it, I told a few friends the other day about it, without saying its name and just saying what it could do the pair of c++ snobs were all on the edge of their seat's with words like Woah sweet, and im getting it, until I said what it was called, then it was all , oh thats for kids. I sware people can be real fickle at times, im positive had you called it something better, and splashed out a better looking website you would be doing way more business than you are now. Last edited 2011 |
| ||
| The world has some funny programming names that we have got use to: * Java * Python * ColdFusion * Cobra * Ruby * Logo * Pascal * Smalltalk * Groovy So why not add Monkey to the list :P |
| ||
| @Yavin If you're worried about the name of the language, why not refer to it as M for short? It would be interesting to see how C++ snobs react to that that ;-). |
| ||
| Ugh. Language snobbery is the first and most obvious sign of not having a clue. I wouldn't expect anyone expressing such opinions to be a good enough programmer to be important. Especially C++ snobbery of all things. </hypocrite> |
| ||
| I agree. Some people think c++ is the only real language to which I normally reply what is asm then. But never mind. Therevill makes a good point. |
| ||
| ather than to a dynamic "var" type TBH i think implicit types are the devil :D I hate them. I can see why in some situations they can be useful but i prefer strong typing, I just know what why and when with those. Languages like JS and PHP have always put me off doing any complex stuff because of it. C# and Java both have optional implicit types which is a nice touch if you want them but i never use them. |
| ||
| Erm... this doesn't actually affect your point as such but I think you're confusing two completely unrelated concepts. The two axes of static vs. dynamic and explicit vs implicit declarations aren't connected: Dynamic typing is where variables have no type discernible at compile-time. JavaScript is an example of this: you can put an int, a string or an object with any fields into any variable at any time. The only restriction being that some operations might not be legal; the compiler won't stop you putting floats and objects in the same variable and you might get bugs like trying to access a field of a float. Static typing is where the compiler tries to enforce type-safety at compile time, which usually translates to "strong" or "weak"-ly static. Blitz languages and Java are moderately strongly-typed, because there's no possibility in normal code to make actual type errors: you can't end up with the bug described above. C and C++ are not strongly typed (even though they are superstrict) since they allow infinite type casting in infinite combinations, and thus the compiler's type checking can easily be defeated. Finally there's inferred or implicit type. In C# this is where you declare a variable with "var" - but this isn't dynamic. The variable will be strongly typed to the type of whatever you put in it at initialization, and cannot hold values of other types. The only advantage this confers is so you don't have to write the signature out again if it's something long like a generic type nested five deep. SO this is just a syntactic sugar and has no connection at all to the dynamic typing of JavaScript, Python or Lisp. Some languages like Haskell take this to extremes: by having very strong typing they actually make it unnecessary to declare types for the vast majority of variables simply because the behaviour for the values is so well-defined that the compiler can work out the types of variables and expressions on its own (look up Hindley-Milner type inference). Again, this has nothing to do with dynamic typing, even though no type is visibly declared. I think we're on the same page about Blitz though. If you want an int, declare an int. Last edited 2011 |
| ||
| In my opinion if you like and use Mark's other languages, you will adjust to how monkey works pretty quickly, it shares much of the BlitzMax syntax, but as in other differing langauges the result of some of the commands is not quite what it was in BlitzMax, this made testing the early beta an interesting experience when there wasnt really much in the way of documentation ;) I think Monkey is a good name for the language as therevills said above a lot of languages have simple, memorable names, often infolving animals or body parts and anyone who judges a language on it's name and not by its abilities must be an idiot, I dont ever remember coding stuff in PHP and thinking christ, what the hell is a PHP. Monkey is also in its infancy but very expandable I am sure we will soon see other targets, libraries etc which would simply not be possible in BlitzMax, also you can create PC and MAC games on it perfectly well using either GLFW or XNA targets, they may lack some of the nicities that we are used to with BlitzMax but in time I am sure they will be added, but it is true that Monkey is aimed more at creating code which will run on many different systems without you having to do crazy amounts of extra work to make that happen and that is where Monkeys real power lies. |
| ||
| @yasha thx for the info, a always assumed php and js were implicit/static (i have always used them as if they were, good habits i guess.. but then they are not really my languages if you know what i mean), Anyway my point was i like to know -exactly- what something is from declaration through use to dropping it. So implicits (and definetly dynamics) are most certainly not my bag! :D Last edited 2011 |
   |