General (Roadmap) Status
Community Forums/Monkey2 Talk/General (Roadmap) Status
| ||
| The Roadmap status wasn't updated for almost 4 month (February 2nd 2016) - any News on language progress (Class extensions, Debugger stuff, '?.'-Operator)? Will all of this be available with v1.0 (AFAIK planned at end of May 2016)? |
| ||
| The language wont be changing before V1.0, but a simple debugger will be in. The graphical side of the debugger is mostly going now - you can stop/step through code etc much like bmx/monkey1, nothing particularly flash but a good starting point. There are still a lot of docs that need doing, so it wont be out in 2 days time. I'm not planning on writing 100% complete 'this is how a linked list works' style docs, but I do want to write something for everything and highlight any gotchas etc. I have no idea how long this will take, but I'll keep github updating as I go. |
| ||
| I have no idea how long this will take, but I'll keep github updating as I go. What about farming it out to the community to help? |
| ||
| > What about farming it out to the community to help? I guess we (the community) should just start doing pull requestes @ github, and Mark could just integrate it, if he likes it (especially for the docs). That's open-source-management... but it sounds like not everything on Roadmap will be in v1.0. Maybe it would better to do a Roadmap in the v1.0, v1.1, v1.2 etc. Style ( https://www.panda3d.org/manual/index.php?title=Dev:Roadmap&oldid=60170 or http://www.ogre3d.org/tikiwiki/Roadmap ), so we know what to expect for v1.0, v1.1, v1.2. etc...? Currently I don't know what to expect for v1.0, v1.1, v1.2, ... it's all guessing from things I read at the forums. We talked about so many things... I don't know anymore what works/will work, and what not - what will work in the future, and what has been discussed away. |
| ||
| > Currently I don't know what to expect for v1.0 Did you read this? http://monkey2.monkey-x.com/2016/04/26/are-we-there-yet This is pretty much still valid, although the gui code wont make it in as a 'module' - it'd just take too much time to cleanup and doc properly, and I gather people aren't that interested in it anyway. It'll still be present in the 'src' directory though. > I don't know anymore what works/will work, and what not - Everything up at github should work OK. The language is pretty much 'frozen' until V1.0, so not much has changed there. Any API visible in the html makedocs docs is pretty much finalized and will be in V1.0, barring last minute panic attacks on my part. My plans for the future language/tool wise are still the same, ie: extension methods, reflection, module manager etc, so nothing's changed there. But I think it was mistake planning too far ahead when it comes to modules, eg: mojo2x, mojo3d etc. This is basically just me guessing what I think people will want in future and I think it's a far better idea to wait until V1.0 is actually out and people have had a play with it a bit before deciding what our priorities should be here. For example, networking is bound to come up pretty quickly, and there may be other things like this that need attention before I go all 3d in everyone's face. Ogre and other similar products have been around for ages now, so they have a pretty good idea what the community wants/needs and can plan accordingly. Monkey2 is still young and IMO needs to find it's feet a bit before we start thinking too far ahead. |
| ||
| Ogre is flawed in a number of ways. Networking is less important than 3d and 2d. |
| ||
| Personally I would prefer monetizing modules like admob etc. to have some priority after V1.0. I didn't see this on the roadmap maybe because it's obvious but it can't hurt to aks: will there be official support for monetizing modules? |
| ||
| Networking is less important than 3d and 2d. Speak for yourself. :P Number one on my list! |
| ||
| This thread again has made me think how self-financing MX2 can be... Some of the modules such as networking, 3d and monetizing could go into a MX store which could support MX2 future development. I guess it all depends on where Mark will make his money from... |
| ||
| Some of the modules such as networking, 3d and monetizing could go into a MX store which could support MX2 future development. I think you are right! Keep MX2 and some core parts free and charge for some add-ons to keep the cash flowing. If 'you' can make money with Monkey than Mark should too! |
| ||
| Yes its a can work, with the monkey shop. But i think it should be for every one. So if you have a small/big code for mx2, you can upload it and make money with it. Also build in a donation feature for the free modules. All modules in one location. Playniax? What about your modules? Are there, if you buy the modules, in clear text? So it could be also simpler to make them avaible via the store. In the feature the store can have an api. So the monkey ide's can auto download (with api login and if you have bought) the modules. All the more easier to use monkey is even more users . |
| ||
| If some thousands users would spend $1/month each, everything would be fine, but reality is that 67 users donate $365. I doubt anyone can make a living from that (in western-standard countries). In some countries it would be fine to make $300+ per month. 67 users/donaters only, is the problem. It is too few - and this count has been relatively constantly for some month. MX2 requires some thousand users (like 5.000+), and everyone knows the "BASIC" market is very limited. Doing a more opened language-system could help. A frontend for BASIC/FLASH-like and another frontend for C/C#-like - with both sharing the same native output, and native libraries. A competitor to (Object-)Pascal (a.k.a. as 'Delphi') wouldn't hurt. I'm talking about 3 frontends (BASIC/Flash-like, C#-like, ObjPascal-like), that translate to the same AST (Abstract Syntax Three), and to the same final target (cross-platform, native C++). With inter-change-able libs/imports. Maybe a bit too much, and probably very enthusiastic - but it's the "final" system in my mind. Native. Cross-platform (Desktops+Android+iOS+RasperryPi+etc). Optimizing. The "best of all worlds", so to say. Including a good RAD IDE (GUI Designer), fast compiler/translator/build-system, optimized executables/outputs/libs, etc. But maybe that's just a dream within my brain. Anyway, I think it may be the road to success (and maybe big money, at least fame) ... |
| ||
| A competitor to (Object-)Pascal (a.k.a. as 'Delphi') wouldn't hurt. There already is with the Lazarus IDE and it supports to some extent the three main Operating Systems and some work for ports to Android/iOS and Web. If it had better support for OS X cocoa UI then it would be my main tool. But it's in the same boat with lack of funding, volunteer programmers and there are a hell of a lot more users than what use see on here and the other BRL site. Plus with it being cross platform there are certain issues that can not be easily overcome without some knowledge or a work around.To be honest the last thing that I would want to see is a GUI module exactly like the one in BlitzMax where everything is of type gadget.To me the Delphi/C++Builder/Lazarus would be the way to go with a GUI construction and should be kept separate from Mojo. |
| ||
| Would another frontend language for MX2 make sense? For example clean C#-like syntax, and modules can be shared between languages (like C++ Builder + Delphi). C# to (cross-platform) Native sounds very interesting... and C# is VERY popular. |
| ||
| What will you do with multiple front-end languages, many platforms and advanced programming considering the limited resources (facing OS updates, new APIs/techniques/..., platform specific needs, ...)? Opening fancy gui windows with 'Hello World!' messages? There could be focus, reasonable decisions and having fun. I prefer thinking of monkey2 more like a sports car, less a truck. More like BlitzMax 3, less like Monkey-X 2. |
| ||
| @Danilo: You're basically describing a higher level version of Clang. It's not exactly an original idea, but definitely one I've thought about myself. C# and VB.NET have Roslyn, so it's not like you can't have significantly different high-level languages share a codebase. It's definitely doable, and honestly might be something to put time into at a later date. For now, Mark should simply develop the compiler as he usually does, separating the build phase, parsing, and semantics. Technically even Monkey 1's compiler works like this, and could have a different parser attached to it. Although, Monkey 1's compiler has its own problems that make this idea a pain. To everyone suggesting a store, I like the donation idea, but from there it should just be developers/vendors making their own decisions about this. The way I see it, Monkey 2 shouldn't be commercial itself, but if Mark wants to sell a module he develops separately, then that's perfectly fine. Now, a module manager on the other hand... |
| ||
| "More like BlitzMax 3" I bet that puts a smile on Marks face. :) The Monkey2 path is just getting started. I think building on it is the best way forward not heaping on as much as possible. As far as a revenue path why not just keep a core desktop open source and charge for mobile (if feasible as it may not be) and optional modules. That way there is plenty of interest and support plus revenue. I also like the idea of a Monkey store for third party modules, assets and alike where Monkey makes a cut. That would also promote third party development for Monkey and bring revenue. Mark also might not be in it for the cash. He might be in it for other reasons like legacy, vision and passion. In that case project supporting revenue is what counts and Patreon, donations and possibly optional modules are what I would think matters. Whatever happens we have a great start here and as we go forward I think the language will begin to speak for itself. In my conversion efforts it's clear that Monkey2 is Marks best work to date and has the potential to excite others. I think the best thing to do right now is to get coding and get the word out. :) |
| ||
| I like the idea of keeping the language free and open source, but being able to buy and download additional modules easily, in one place. |
| ||
| > It's not exactly an original idea, but definitely one I've thought about myself. This idea came to me automatically few years ago when reading some books about compiler construction/design/optimization/crafting/patterns. You already learn about Frontend (Tokenizer/Lexer + Parser > AST (Abstract Syntax Tree)), Middle End (Semanter, Data Flow Analysis, Optimizers > may result in an AAT (Abstract Assembly Tree)), and Backend (Code Generator, Pattern Matcher, Optimizers for specific platforms, Loophole Optimizers, Linkers & Loaders, etc.) The idea is not new, because all those books already teach the modular style - but only very few people/companies/groups really do it like this (so frontend and backend can really be easily exchanged). LLVM compiler infrastructure (Clang), for example > even Apple and other big companies use (and support) it, because it is so good. The GNU GCC compiler suite also has many frontends for the compiler infrastructure (AFAIK C,C++,C#,Pascal,Fortran,Java,...). I like that stuff and collected every book about compilers & prog. languages I could get (english/german), just because I find this topics very interesting and challenging. The more you work on the topics the more ideas come. :) For example an advanced optimizer using graphs and neural networks to find and learn the optimal/best output sequence for speed, smallest output, or smallest energy use. The neural network connected through internet (in the cloud?). Most of the big compiler providers already support multiple frontend languages (VB.NET/C++.NET/C#/F#/XAML, Intel C++/Fortran, (Borland ;) C++ Builder/Delphi). Something for every taste, so to say - because it really widens the customer base if you provide more input/frontend languages. I remember a topic within this forum, where somebody said his friends/colleagues are not interested in Monkey because of the "BASIC-like" syntax - they prefer C-like bracketed languages (probably often teached at Universities (Java, C, C++, C#, Go, D?)). So, generally, I think it would be a pretty good idea. Just another Frontend (Tokenizer/Lexer and Parser) for a C#-like language, and the rest (Middle-End and Backend) are shared, so libs etc. are compatible and can be used by all frontend languages. It means you could code native, cross-platform games and applications for desktop + mobiles + web easily with the MX2 language, and additionally with a language similiar to the C-language-family (clean C#, instead complicated C++). I guess many C/C++/C# users could be interested in such a thing, if it comes with enough included libs for everything (Sensors, Screen, GUI, Networking, Packers, Memory, 3D engine, Images/Drawing, Stripe, etc.) Of course, this would be a long-term goal on the Roadmap. |
| ||
| I wonder if Mark had more fun designing languages that made making games as simple as possible as opposed to writing compilers that test his compiler design skills.... Imagine if Mark went oldskool and designed a language without all this Reflection, Generics being at the forefront, hidden and with every possible avenue covered that would allow even the new generation of folk wanting to just make games to do so and have it be a fun prospect for each day to fire up a BRL game making language. Oldskool blitz. That's how the show began, really. |
| ||
| No way Amon. Writing Java style boiler-plate builds character. :-p |
| ||
| No way Amon. Writing Java style boiler-plate builds character. :-p Yep, and also keeps you broke..... :) |
| ||
| I guess Mark puts some effort into making his language. I doubt that investing limited resources into more languages attracts more users in the long run (not even arguing about what could be done instead). These things end up with a few or even one dominating language(s). They'll get better support (both from the dev and the users)... , a snowball system, great mass attracts more mass until it hits a tree, collapses (new technology shows up) and things kind of start over again. AI will change the way to program. As long as the ball is rolling, try to make smart decisions. |
| ||
| Got the message, taumel & Amon. If I reallly believe in something, I have to do it on my own (it seems to be the only way) - MX2 is not the project to make my coder's dreams come true. Thank you for being honest! |
| ||
| I like the idea of keeping the language free and open source, but being able to buy and download additional modules easily, in one place. I really hope mojo(whatever version) along with net and other basic modules will be free open source software. That's why I was donating. I hope the comunity will work on a free native api-gui if Blitz doesn't. (If I remember well it was said it won't be a priority) It's fun how people here have a lot of ideas for marksibly's buisness. I love the fact he's gone free open source with active github. For me that's the future of dev softwares. |
| ||
| @Danilo, there's nothing wrong with your idea. Multiple languages sharing a core build system and libraries is hardly left-field craziness considering .NET and JVM technologies both offer this as well as the modular compilers. It's hardly a new point that the BASIC-like syntax is a real barrier to adoption either. It was brought up repeatedly in the early days of Monkey when people started to menton the product to other coders. Bringing it up always results in the same "missing the point" reactions arguing against that market preference as if it's a debate to be won about aesthetics or technical equivalence. I've been meaning to look at the mx2 code at some point with the primary interest in seeing if the language parser can be easily replaced with a mini-C# front-end. Even a fairly simple mapping of structure and declaration syntax would ease a lot of the friction when hopping between projects for me. |
| ||
| Hei hei hei, what's up with da monkey2?! |
| ||
| See Monkey2 Forum ;) |
| ||
| Hmm... |
   |