Monkey Code vs Blitzmax Code?
Community Forums/Monkey Talk/Monkey Code vs Blitzmax Code?
| ||
It's similar to blitzmax, yet can publish to all the more popular devices?! Can someone provide an example of code for something like a Hello World app? or perhaps provide a Blitzmax comparison of code? I would really appreciate it to see just how alike it is (and i'm sure others would find it useful to see as well) |
| ||
BlitzMax Console HelloWorld:Print "Hello World" Monkey Console HelloWorld: Function Main() Print "Hello World" End Now using graphics... BlitzMax HelloWorld: SuperStrict Graphics 640, 480 Repeat Cls DrawText "Hello World", 100, 100 Flip Until AppTerminate() Monkey HelloWorld: Strict Import mojo Class MyApp Extends App Method OnCreate:Int() SetUpdateRate 60 Return 0 End Method OnUpdate:Int() Return 0 End Method OnRender:Int() Cls DrawText "Hello World", 100, 100 Return 0 End End Function Main:Int() New MyApp Return 0 End Overall BlitzMax and Monkey are very similar, they need to be set up differently. Last edited 2012 |
| ||
The language is kind of similar, but the features are not. Example: it is (currently?) not possible to change graphics resolution during run-time. Also, the things you can do may vary per target. Example: There is an OS module (load, save, create folders, etc) but only for CPP and GLFW targets. But: Monkey also has new features not implemented in Blitzmax, like interfaces, function/method overloading. So read up about the pros and cons before you jump in and maybe become dissapointed. Last edited 2012 |
| ||
Thanks for the replies! It appears monkey's setup is the way I prefer to code at any rate (Having moved from Blitzmax -> Flash / .Net Languages). I appreciate the help, and it definitely looks worth diving into. Cheers |
| ||
it is (currently?) not possible to change graphics resolution during run-time. I added this functionality to Diddy for GLFW and HTML5 targets... I also managed to do it from Android, but it requires hacking Mojo directly. |
| ||
I prefer BlitzMax....much better than Monkey x to be honest... |
| ||
I do prefer Monkey X due to it having Generics, Interfaces and type inferenceLocal myList:=New List<Bullet> 'This is a new list of Bullets ... Local firstBullet:=myList.First() '--> This is actually a bullet, no need to cast at runtime, and the variable is set to the appropiate kind at compile time! BlitzMax equivalent: Local myList:List = New List '--> This can't be a list of Bullets, but it's a list of Objects of any kind that can be used to store Bullets ... Local firstBullet:Bullet = Bullet(myList.First()) 'That's slower as requires runtime type checking and also a bit too WET for my taste! |
| ||
I prefer BlitzMax....much better than Monkey x to be honest... Why Hotshot? To me MonkeyX is a huge improvement over BlitzMax in syntax, as Ziggy pointed out it has generics, interfaces and type inferences, also aliases. |
| ||
I prefer BlitzMax because it can do desktop where Monkey X for mobile device. Not only that if you have learn horrible x code or object c if you want on tablets or phone. Lots of hassle if you ask me. Coding wise? You may be right saying Monkey X is better but it doesnt have collisions build in like BlitzMax! You would point out that monkey x got good module like diddy and Ignition X that have collisions. One things I hate is when you put image in the same folder and it is mess(error after error) in Monkey x when it shouldnt happen. |
| ||
But Monkey X can do Desktop too! In fact, it can target BlitzMax, so it can use absolute all blitzmax functionality, as is, but also code it with better language functionalities |
| ||
Again as Ziggy said, it does have a desktop target. You don't need to learn Objective C for iOS, but it can help if you want to do out of the box solutions. Yeah there isn't any built in collision functions, but its pretty easy to add. What do you mean about putting a image in the same folder? |
| ||
It is ok now and quite lots of change...for example instead of doing this Methods whatever:void() End Methods... Now it is Methods whatever:int() return 0 End |
| ||
Monkey Code vs Blitzmax Code Now language wise this is a no brainer. Now I love BlitzMax but Monkey is simply superior. |
| ||
It is ok now and quite lots of change...for example instead of doing this Methods whatever:void() End Methods... Now it is Methods whatever:int() return 0 End So basically... Methods whatever:int() return 0 End ' Method Otherwise it would be a confusing mess. Maybe I'm wrong and indentation gives you all the info you need visually, but personally I prefer a clearly defined beginning and end to a code block that gives the debugger enough info to tell you when you've bollixed things up. |
| ||
I prefer just "end"... but I'm a Java coder by trade so I'm use to just "}" ;) |
| ||
It miss the MAIN difference (for me): case sensitive word. Blitzmax Cls there is ONLY ONE Cls command/function MonkeyX Cls cls CLS there are three different commands/functions the only negative thing in MonkeyX for me (!) And no: this 'freedom' of writing is quite stupid (if I want to call a function like the 'original' one I prefer to add some sort of prefix and so on). Without the fact that the simple BMX's IDE will recognize automatically the 'commands' and help you in writing down your code. Monkey'x base IDE is more limited (only for 'core' language token). You need an advanced IDE (like jungle and the offer monkey studio) |
| ||
Again I actually prefer a case sensitive language to a non-case sensitive language. |
| ||
I'm comfortable with either case sensitive or not.....as long as my ide xan pick up my typos! Cant stand undeclared variables in code...one of the biggest drawbacks in a number of languages that dont enforce declaring variables is wading source code looking for a bug when it was just something simple like a misnamed variable.... |
| ||
Again I actually prefer a case sensitive language to a non-case sensitive language. If a language is case-sensitive, the IDE *must* help you along with maintaining that.It's all very well religiously using camelcase or whatever but typos happen, and the IDE needs to be on top of it when it does. |
| ||
I run a bit hot and cold on the case sensitive thing, but generally swing to the case sensitive side of the argument. For example, in Blitz3D (a case insensitive language) I make all my constants uppercase so that I can easily identify them visually, but have to put a C_ header on them to avoid conflicts with local variable names. As long as you're using an IDE with a good lexer that does syntax capitalization automatically you should only have the one version of a case sensitive identifier. If the IDE's lexer fails to do its job then I could see where things could go seriously pear shaped though. |
| ||
looking for a bug when it was just something simple like a misnamed variable Unless you're unlucky enough to get the really unfortunate scenario of the typo correctly spelling out a different variable name, there's absolutely no excuse for a compiler allowing this mistake to happen. It doesn't necessarily have to require you to use Local or Let or formal declaration at all - because it's easy for the compiler to keep track of which names have actually appeared on the left of = prior to the typo! It's a bug for the compiler to let a name appear on the right if it's never appeared on the left, pure and simple. (at least, in static-style languages that don't have the concept of nil or undefined or _ENV or whatever) |
| ||
> Again I actually prefer a case sensitive language to a non-case sensitive language Yep, you will start to like it more when you are used to it and soon you don't want to be without. It has many benefits. |
| ||
Yasha......have you used Blitz 3d? ;-) That's exactly what happens in blitz3d/plus.... compiler doesnt give a rats about when a variable is declared or not....anything new that appears simply gets treated as a new int variable with value zero..... |