What can monkey2 better than cpp?

Community Forums/Monkey2 Talk/What can monkey2 better than cpp?

malublu

(Posted 2016) [#1]

Today I looked at monkey2.
They are struct class, etc....
In monkey1 i love the simplicity.
At the first look it seems like a cpp clone.
Only with an other syntax.
If you say: monkey2 is crossplattform!
Yes, sdl2 cpp also. (A little bit complexer, but you could write automatication bat scripts)
What make monkey2 better than cpp?
It's only a question!

A example for pointers:

#Import "<sdl2>"
Using sdl2..
Function Main:Void()
	
    SDL_Init( SDL_INIT_VIDEO )
    Local win:SDL_Window Ptr = SDL_CreateWindow( "SDL Tutorial", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 200, 200, SDL_WINDOW_SHOWN )
    Local event:SDL_Event
    Local running:Bool = True
    While running
    	If SDL_PollEvent(Varptr event)
    		If event.type = SDL_QUIT
    			running = False
    		Endif
    	Endif
    Wend
    SDL_DestroyWindow(win)
    SDL_Quit()
End

#include "SDL.h"
int main(int argc, char **argv)
{
   SDL_Init( SDL_INIT_VIDEO );

   SDL_Window* win = SDL_CreateWindow( "SDL Tutorial", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 200, 200, SDL_WINDOW_SHOWN )

   SDL_Event event;
   bool running = true;
   while (running) {
      if (SDL_PollEvent(&event)) {
         if (event.type == SDL_QUIT) {
            gameRunning = false;
         }
      }
   }
   SDL_DestroyWindow(win);
   SDL_Quit();
   return 0;
}

AndroidAndy

(Posted 2016) [#2]

Ok, I am sorry, but at first I thought this was Haiku, you really got me. So with that in mind I have transformed your post into two Haiku poems to use as replacements:

monkey2 language
seems like a cpp clone
but is it really?

monkey2 with class
what is this other syntax?
I have a question...

Cheers!

ratking

(Posted 2016) [#3]

Haha.

Well, I wonder that myself - why should I choose Monkey 2 if I can understand and even write C++ a bit? If there were going to be a lot of pre-built modules for (e.g.) game development, like it was with Blitz3D, I weren't so hesitant with even trying Monkey 2. Currently I just don't see any advantage for me to use M2.

abakobo

(Posted 2016) [#4]

For a game dev the power of monkey is mojo1/2... not monkey itself.
MX2 is more readable than cpp IMO. But it's basicaly the same language after all. Except for some low level capabilities.
You will be able do things way simpler than with sdl+cpp. Mojo2 brings you to a higher programming level than sdl2. It can be see as a framework based on sdl2.
MX2 has just more programing concepts available than monkey1, almost every concepts available nowadays, with a very high-level capabilities all in one from the start. But you're not obliged to use all those concepts.
If native api/gui and (easy!)networking modules becomes available too then MX2+modules will probably be the highest level (not slowly interpreted) programing solution on the market that includes today's programming concepts.
The fact that we'll probably have to manage the manifests/xcode.proj ourselves scary me a bit though, in a cross platform point of view. I really hope there will be something beginner/end-user friendly about that.

Just my opinion.
I believe in MX2!

therevills

(Posted 2016) [#5]

I hate coding in C++... MX2 has such nice syntax :)

Playniax

(Posted 2016) [#6]

I hate coding in C++... MX2 has such nice syntax :)

I hate it even more! I would rather go back to 68000 assembly!

Paul - Taiphoz

(Posted 2016) [#7]

I concur and I think this is why MX2 is putting me off, it just feels far to much like cpp.

in the words of someone else in another post that I totally forget who said "far to wordy"

dawlane

(Posted 2016) [#8]

I hate it even more! I would rather go back to 68000 assembly!

May as well go the whole way an use 6502 assembly. Or better yet punch cards!

degac

(Posted 2016) [#9]

Well, a possible solution to 'monkeyfy' the syntax is to 'binding' the various external modules (like SDL) in some way (like CreateGraphics W,H, CloseGraphics etc ala Blitz3d/BlitzMax).

To me the only *strange* things I can't understand is #Import "<sdl2>"... I don't think it's so hard to find a simpler way to implent it Import sdl2??? So much type for a single instruction! It's up to the translator/compiler to 'translate' it what it really means!

impixi

(Posted 2016) [#10]

Consider the “simple” task of displaying a jpg image loaded from disk, overlaid with the text “Hello World”, written in a TTF font, in a resizable window - I can guarantee it is significantly easier to do in Monkey2/Mojo than in pure C++/ SDL.

In any case, I challenge anyone to write a *game* in C++/SDL that is “simpler” to understand than if coded in Monkey2/Mojo.

Playniax

(Posted 2016) [#11]

I challenge anyone to write a *game* in C++/SDL that is “simpler” to understand than if coded in Monkey2/Mojo.

Add Pyro to the mix and the challenge is even greater!

CopperCircle

(Posted 2016) [#12]

I think Monkey 2 offers way more than the pain of coding in c++, the syntax is great and not far from Monkey1 but the new language features are there if you want them. With Mojo2 you can get a simple game up on screen in a handful of lines of code. I have always loved Mark's products and feel Monkey2 will only improve (I have lots of modules I want to port) and be my go to language replacing Monkey1.

peterigz

(Posted 2016) [#13]

Another thumbs up from me for mx2 I like it so far. Currently converting 4-5k lines of code from monkey1 to test it out and so far it's pretty straightforward, and I'm looking forward to optimising the code to take advantage of new features. Be interesting to compare performance between the 2 (and blitzmax too as I also have the code in that). I know bugger all about c++ btw :)

The extra tags in the #import is just the difference between importing a whole module, or just importing a single file, it's not a big deal really, I'm making notes as I go along and will try and summarise what I had to do to convert things over.

I think the main thing that might create discussion (I think it may have done already) is the fact that methods in classes are final by default, so if you want them to be overridden you have to specify them as virtual, and the overrided method you have to specify as override. Be handy to just tag the class as virtual which then makes all methods virtual by default instead but I'm sure there's reasoning behind it, either way it's not a big issue I think.

ImmutableOctet(SKNG)

(Posted 2016) [#14]

@peterigz: Virtual classes are available in Monkey 2; just write 'Virtual' after the class declaration, just as you would with 'Final'. I'm not sure if Mark's keeping them or not, though.

Class Base Virtual
	Method X:String()
		Return "Base"
	End
End

Class Derived Extends Base
	Method X:String()
		Return "Derived"
	End
End

Function Main()
	Local obj:= Cast<Base>(New Derived())
	
	Print(obj.X())
End

Leo Santos

(Posted 2016) [#15]

I don't know C++ at all and have some small experience with C# (in Unity), so maybe I'm more of M2's target audience.

When I look at C++ code, sometimes it feels like I'm staring at some arcane runestone, filled with weird symbols and unnecessary characters all over the place. Yeah, sure, in that example the differences aren't that major, but usually when I look at "real" C++ code out there in the wild, it feels way more complex than that. For instance, what the hell are header files for? Seems so bureaucratic! I have no issues understanding most of the M2 code I've seen so far.

Of course for beginners the fact that monkey works well out of the box, just download it, run it and start compiling code, is a big plus. Whenever I tried other languages (C++, Haxe, etc) things tend to be an absolute end user nightmare, with multiple dependency downloads, setting environment variables, then things don't work and you have to spend hours googling solutions, then you finally get it all working you still have to dig around for useful libraries, etc. I do think M2 could be better in this regard if it came with more "game engine" ready modules, such as polygonal collisions, scene graph, entities, etc, more like Blitz 3D.

Also, I have an irrational hatred of semicolons at the end of lines.
:-)

Leo.

peterigz

(Posted 2016) [#16]

@ImmutableOctet(SKNG) Ahh ok, so you can just do that, cool :)

degac

(Posted 2016) [#17]

@peterigz

The extra tags in the #import is just the difference between importing a whole module, or just importing a single file, it's not a big deal really, I'm making notes as I go along and will try and summarise what I had to do to convert things over.

Ok, why don't create 2 different commands Import and Include keeping the 'plain' syntax without strange chars?

Import "sdl2"
Include "local_file"

Danilo

(Posted 2016) [#18]

Import "sdl2"
Include "local_file"

Mark thinks too technical here, so an internal pre-processor thingy has to have '#' in front of it -
that's why it is "#Import".
I agree, just 'Import' and 'Include' would be easier/better/nice for users of the language/system.

peterigz

(Posted 2016) [#19]

Ok, why don't create 2 different commands Import and Include keeping the 'plain' syntax without strange chars?

Agreed that'd be a lot more intuitive.

EdzUp

(Posted 2016) [#20]

Of course for beginners the fact that monkey works well out of the box, just download it, run it and start compiling code, is a big plus. Whenever I tried other languages (C++, Haxe, etc) things tend to be an absolute end user nightmare, with multiple dependency downloads, setting environment variables, then things don't work and you have to spend hours googling solutions, then you finally get it all working you still have to dig around for useful libraries, etc. I do think M2 could be better in this regard if it came with more "game engine" ready modules, such as polygonal collisions, scene graph, entities, etc, more like Blitz 3D.

In my experience with C++ and MonkeyX its the other way around, for me installing Code::Blocks with MinGW and I can code and compile right out of the box even my OpenGL engine runs first time every time. MonkeyX on the other hand I have to faff around with config files etc just to get it started, on top of this nightmare the dependencies if your using Linux then it throws another spanner into the mix.

All languages have the issues its dependent on what the coder is going to put up with before chucking it in and looking elsewhere. MonkeyX2 looks nice but I want to see the final v1.0 release before passing judgement on it.

Playniax

(Posted 2016) [#21]

MonkeyX2 looks nice but I want to see the final v1.0 release before passing judgement on it

I suggest to wait a little longer to have a 'final' judgement. I am using MX2 ever day now and it really works well already but I have know doubt people will find issues in the beginning!

Jesse

(Posted 2016) [#22]

According to mark he might have something(first release) by the end of this month.
http://monkey2.monkey-x.com/forums/topic/collision-module-and-performance/#post-1112

he just did an update on github.

taumel

(Posted 2016) [#23]

I guess it will take some more time until there will be a more mature release including reasonable up to date gfx/sfx/input/game functionality/docs. You know, those aspects you can otherwise waste a lot of time on in Monkey or end up using different solutions. It doesn't make a lot of sense trying to compare stuff right now.

EdzUp

(Posted 2016) [#24]

I suggest to wait a little longer to have a 'final' judgement. I am using MX2 ever day now and it really works well already but I have know doubt people will find issues in the beginning!

Ah ok, im waiting for a full compiled release not the github stuff. I dont have time at present to delve into compiler errors etc.