Approx time frame?

Community Forums/Monkey2 Talk/Approx time frame?

Neuro(Posted 2015) [#1]
Interesting to see all of this. So is there a timeframe for monkey2?


marksibly(Posted 2015) [#2]
> So is there a timeframe for monkey2?

Nothing hard and fast as yet, although it should be possible to build useful stuff within a month or so. From there, I'll just keep adding stuff and whether it's useful or not to you will depend on your requirements.

But really, the overall plan is to get to a point where monkey2 is doing relatively well and I can keep on developing it 'for ever', as software these days is never finished!


EdzUp(Posted 2015) [#3]
As long as it is as capable as BlitzMax then it will be a winner, if its like a drugged up hippy version of max with most of the decent features removed then it will vanish quicker than a politicians promises after election day.


Danilo(Posted 2015) [#4]
EdzUp wrote:
As long as it is as capable as BlitzMax then it will be a winner

+1 >> BlitzMax with moderized Syntax and Features like Google Go, Vala / C#, D, Haxe, ...

I really hope Mark takes the time and looks into some of this languages while
designing MX2 and making decisions about the MX2 language feature set.


Neuro(Posted 2015) [#5]
Nothing hard and fast as yet, although it should be possible to build useful stuff within a month or so

Nice...looking forward to testing it out :).


Nobuyuki(Posted 2015) [#6]
+1 >> BlitzMax with moderized Syntax and Features like Google Go, Vala / C#, D, Haxe, ...


Go and C# definitely seem like some good ones to take cues from, though C# is somewhere between Java and Haxe in terms of which generation it belongs to. I'll admit I'm biased towards C# because of .NET. When Monkey came out, I was very happy to get the "feel" of enjoyment coding in something that felt modern, simple and clean as compared to the VB.NET I'd been used to. Go is new, but not blisteringly new like Rust or Nim seem to be in terms of having stabilized the language. The relative conservatism can be a good/bad thing, depending on how you see it.. Since I'm not super-familiar with either, articles like this have proven helpful in understanding the mindsets of the people developing the languages as they reach for their goals.

After having been brow-beaten for years as an old VB guy for its weak Variant typing, it's nice to see that people don't automatically crap on type systems that aren't exactly like C anymore. I'm presuming that monkey2's type system isn't going to undergo any radical changes, but if we start seeing pointers and more GC control appear, some of the stuff the Rust guys have been doing may be worth taking a look at.


Samah(Posted 2015) [#7]
The first task is to finalise the list of "release one" features, and create a lexical grammar. This really needs to happen before any coding begins.
Mark, you need to set up a Trac or Jira project and pick your initial team. It's a huge task, and Monkey 2 will fail if you try to go this alone. We want to help! :)


Danilo(Posted 2015) [#8]
Samah wrote:
The first task is to finalise the list of "release one" features, and create a lexical grammar. This really needs to happen before any coding begins.
Mark, you need to set up a Trac or Jira project and pick your initial team. It's a huge task, and Monkey 2 will fail if you try to go this alone. We want to help! :)

I was thinking about something like MediaWiki for the public documentation and collecting informations,
but alternatives could be better. Something that allows to collaborate when writing the docs,
and allows generation of different outputs (HTML, CHM, PDF) would be good.


Samah(Posted 2015) [#9]
@Danilo: I was thinking about something like MediaWiki for the public documentation and collecting informations...

Sounds good for high level doco. I'd prefer something along the lines of Javadoc or Doxygen though for inline documentation. It'd be awesome for the community to write user guides and tutorials, but I think the developers/contributors should be the ones writing documentation for individual classes.
Also, I think any documentation should have to go through some form of quality control too, mostly to catch typos, grammatical errors, and potential misinformation.


therevills(Posted 2015) [#10]
Inline docs ftw!


Nobuyuki(Posted 2015) [#11]
Inline docs ftw!


with param support for those of us who don't know what arguments like 'stride0' could mean in method x


degac(Posted 2015) [#12]
Question:
I know MX2 is a 'work in progress' and there's no an ETA.
But
1. it's possible to post on www.paetron.com (just to make the thing public outside this forum...)
2. it will possible to start to finance it (or what'else is the 'paying' thing...) before the 'alfa' release? Or you (Mark) prefer to wait


I just registered to paetron just to know how it works, and of course - it's plenty of projects....