Road map or plan?

[kryton9]

I was thinking it would be neat to setup a road map or plan so that two people independent of each other would not work on developing the same sort of module or class for oxygen.
Also with some sort of plan, people interested in developing something similar could work together.

Once a good class or module is developed, it would be submitted to Charles and he could fine tune it to meet his vision for Oxygen. This could be a back and forth between the contributors and Charles
till it is refined to be added to the language.

Perhaps first we could define clear objectives for development directions. I am sure some are only interested in console utility type programming, others perhaps windows business type programming and other like me perhaps into game programming. And another front might be porting oxygen to other Operating sytems, like Android, Chrome, OSX, Linux?

Another front is making oxygen work with other tools, like RadASM for instance.

So a short recap:
1. Define or find out where development objectives lie within the community by importance.
2. Continue work on integration with other tools.
3. Once development objectives are set for the first round, break it up into required classes / modules to meet the goals. With this list, then those wanting to contribute could pick the areas of interest and develop with others interested in the same thing.

The benefit is not ending up with many classes doing the same thing making it hard to learn and use oxygen as you see with so many other languages as it grows.

What do you guys think?

[Charles Pegge]

Well I have A few policies but not many definitive plans.

I would like to keep the Oxygen nucleus very small, containing only those features which cannot be efficiently implemented in an external library. This includes all the core language abilities, OOP and dynamic compiling.

A few well developed demo  applications will be of great value in helping to coalesce useful functions into a small number of compact libraries, small enough to include in the standard package.

Encourage the use of the widely adopted cross-platform libraries like Sqlite and Opengl.

Work towards developing a tightly coupled IDE - an OxIde which includes full syntax awareness, background compiling and code database. I would like to use pure Opengl for all the visual aspects including the code editor if this is feasible in a finite period of time

Finally keep the entire Oxygen project completely open and unrestricted by licensing so that any part of the source code may be extracted, adapted or redeployed.

Charles

[kryton9]

Charles,

I would like to keep the Oxygen nucleus very small, containing only those features which cannot be efficiently implemented in an external library.

That sounds just like the goals of C and why it has become so popular and widely used, which is great.

Do you plan on using your c library converter to make popular libraries available for oxygen? Is there a list you have in mind... I know you mentioned sqlite and opengl?

[Charles Pegge]

Hi Kent,

Oxygen can read most C headers directly. Though a lot more testing needs to be done in this area, it should not be necessary to translate all those .h files into basic if you can tolerate the heavy-duty type definitions and watch out for case sensitivity. There is #case capital which makes O2 sensitive to fully capitalised names, this is sufficient in most cases.

Troublesome definitions can also be overridden

For Opengl demos, I include the C headers in the package and find that so far, case sensitivity is not necessary - the naming policy ensures that all symbols are unique.


Charles

[kryton9]

Oh, ok great!

[kryton9]

Charles, I was thinking about oxygen and I know that the small core with additional libraries is very flexible but at the same time it will lead to fragmentation.
Mixing and matching libraries in c++ for me has been a nightmare to tell you the truth.

I think when you think of BASIC, at least the way I do... all of the commands were uniform and provided by the language.

Perhaps you can do both. Make official commands that are part of oxygen with a bigger oxygen.dll core and no libraries.
And another small oxygen.dll core with libraries.

As people make classes and libraries for oxygen, then perhaps whichever one best fits oxgen can then be absorbed into this bigger core dll.

For example, I find it comforting when looking at new languages to see something like this with many commands built in to the language.
http://www.purebasic.com/documentation/index.html

When you click on a library for instance it brings up commands that look and feel like the main core language.

Does this make sense?

[Charles Pegge]

Hi Kent,

Yes I agree all those C++ libraries are a complete turn-off and impenetrable for an outsider like me.

My intention is to have a small number of outer core libraries covering major areas of application like editing, graphics, audio and networking.

Also a number of highly developed examples which may be taken and customised for user applications. Even with good libraries, multimedia applications are way too complicated to build from scratch. It is much easier to take something which already works and gradually morph it to your own requirements.

Charles

[kryton9]

I am happy to hear that Charles.

Even freebasic, with all those libraries it is so hard to start for a new comer. And as the problem I have with sqlite, I can't seem to find the matching dll to get it to work. So having things all in one package that works will be great!