a case for architectural change in oxygen?

[kryton9]

I am going to make a case for a change in the architecture of Oxygen. Right now Charles has picked the C design, small core and everything else libraries. This sounds good at first, but then you end up with what we have in the c/c++ world. Everyone writing their own library to fit their coding style, each with their own dependencies. You can look at source code on google code search and see code styles that are light years apart in look and readability. You can see a zillion examples of people rewriting the same code over and over again rather than looking and settling on a proven library. Even in proven community based libraries, like Boost, you have people that absolutely will not use them for whatever reason, so they write their own.

I say that Oxygen should be a giant core that is ever growing. The core is only added to by Charles and others he might add to his core team. Any new code would be submitted as a library to the core team and then they would make it fit the Oxygen way. This also means developing a rigid set of rules for the look and feel for Oxygen. Right now it is too flexible if you ask me. Then when the program is compiled, Oxygen would remove any unused code from the giant core to make the executable small.

For tinkering and getting things going, I think Charles took the right approach. But when you look at how powerful Oxygen already is. I can also see how the current way will lead to chaos in the future as we add more complex systems. I see Peter's libraries and some of Charles that do the same thing as well as some of my own. And we are just in Oxygen's infancy.

Here I submit a very nice well thought out schematic for a game engine. Now imagine all of these components written by various authors in various styles with redundant code and crazy dependencies, as it will be, if we continue on the current path. The only way I see a clean elegant solution is to have a master plan. Not only for a game engine, but for other areas of development. I just present a game engine as that is my current passion.

My initial suggestions for style would be based on C, since Oxygen can read C header files.
1. Case is Sensitive
2. Parenthesis are required for functions, subs, methods
3. Use == instead of := for conditional equality checks

If oxygen is to keep Basic as part of its name. I think then the extension .o2bas should just be .bas and the include files .inc  Right now we have a mixture of many extensions in the examples I download. Again flexibility was nice, but now I think it is detrimental.

Also, I think Oxygen would be in two main prongs. Procedural and Object Oriented Programming. A user could mix and match according to their needs. But basically, for almost all commands there would be 2 of them. One in the Procedural Prong and the other in the OOP Prong. The help would be a clean split of these two prongs.

It is alright if you want to take me out to a wall and shoot me if you disagree, what do you guys think?

[jcfuller]

Sorry Kent I am opposed.
I have not been coding with O2 lately but I have been following it's progression and I like what I see,even if I don't understand a lot of it.
I think with a comprehensive help file and MANY,MANY examples (with extensive comments) one will be able to pursue their own preferred manner of coding.

James

[Peter]

Hi Kent,

What I think:

Case sensitive ,  no 
Brackets,           no 
:=,  will  never used by me.  May go to the Moon.. 
 

[Aurel]

Don't worry Kent nobody kill you...
I understand that you want something like have PureBasic,EBasic etc...etc...
but this aproach is unique ,right?

[Peter]

Hi Kent,

After this defeat, you could feel the desire to build a plane and just fly away.
for this airplane  could you  already get a propeller here. 

[kryton9]

Thanks for the input guys. I will head South to the Border to go hide deep in the jungles with my crazy ideas, using Peters Propeller

[efgee]

@kryton9

Case sensitivity -> no
Parenthesis -> yes
C-style equal sign (==) -> yes

In the end Charles has to decide what he wants in his language.

But before these kinds of things are evaluated/discussed the error reporting "mechanics" inside Oxygen need to be fixed.

[Peter]

What is so exciting of  " ()" and " ==" ? 
I think that Kent and efgee won't Basic,  rather an Oxy C, C++. 

[efgee]

What is so exciting of  " ()" and " ==" ?  

Peter,
when looking at old code of mine that I wrote 10 years ago and I see:

Code: [Select]

fruit = Banana()

Even after 10 years I know Banana is a procedure.

If I would have written:

Code: [Select]

fruit = Banana

after 10 years I don't know what Banana is; is it a variable or procedure?
Have to look at the code and find the declaration of it.

Also as you know from experience Oxygen's error report differs if you use parenthesis or not...
This said, the syntax check inside the compiler gets more complicated and error prone.

---

A big flaw of BASIC is that the assignment of a value "=" and the check of equality "=" is the same.
Examples:

Code: [Select]

fruit = Banana ...


Code: [Select]

if fruit = Banana then ...

Sure the code surrounding the "=" tells me if it's an assignment of a value or the check of equality.

But with other languages that have the "==" to check for equality you can do:

Code: [Select]

function Banana( dword a, dword b)
   ... do some things with a and b
   ... and then do:
   result a == b
end function

The function above returns "true" or "false" depending if a equals b.
In Basic you need more code to do the same...

Don't fall into the trap and think that the BASIC syntax (as it was invented decades ago) is the best thing after sliced bread...  

Be open minded, but please not too open... otherwise your brain could fall out

[Peter]

otherwise your brain could fall out

this happens often.   

[Charles Pegge]

I find standing on one's head is a good way of pushing the brain back into its proper position 

You can use "==" if you prefer it but I think it would be undesirable to enforce this.

The C use of "=" in conditional statement is a continual source of confusion for inexperienced programmers. So I felt the best compromise was to use ":=" to denote an unambiguous assignment.

There is a reason for not enforcing brackets and perhaps blurring the distinction between variables and procedures. It is part of the OOP philosophy of separating implementation specifics from the user.

This is a trivial example of using pseuodovariables:

Code: OxygenBasic

1.   class fruit
2.   '==========
3.  
4.   string itype
5.  
6.   method type(string s)
7.   itype=lcase s
8.   end method
9.  
10.   method type() as string
11.   return itype
12.   end method
13.  
14.   end class
15.  
16.  
17.   '======
18.  
19.   fruit fr
20.  
21.   'overloading pseudovariables
22.  
23.   fr.type="Banana"
24.   print fr.type 'prints: "banana"
25.  
26.  

Charles

more thoughts to follow..

[Aurel]

All basic like languages have '=' not '==' and if currently work OK i
see that work ,why insist on unbasic syntax?

[JRS]

There is a reason for not enforcing brackets and perhaps blurring the distinction between variables and procedures.

ScriptBasic doesn't require parentheses for functions or subs if they don't return anything.

SUB Dummy(arg1,arg2)
  'do something but don't return anything
END SUB

Dummy "String comand", 0

I have to use parentheses in this case.

FUNCTION Dummy(arg1,arg2)
  'do something
  Dummy = 1
END FUNCTION

okay = Dummy("String comand", 0)

[kryton9]

Oxygen has come along way, but many times I see reinvention of the wheel over and over again in the code examples. I found this image to show the complexity of what it takes to make a proper game engine and this could also reflect the amount of work for any huge project. I hope this great schematic can give direction and organization as Oxygen development moves forward.

I wish I had the low level skills that Charles and Peter have, but I don't. I have tried to work in an organized manner, but keep hitting walls that I find frustrating. So for now, I will move onto another language or framework and see if I can get anywhere. If I ever get an engine together as I wish, I will definitely look forward to porting it to Oxygen in the future and carrying on work in it. Oxygen is very sweet to work in and it makes it hard to go to any other language, but my muddled mind needs to focus on one language at a time anymore.

With a working engine and code to port, I think I can contribute more in the future than I currently can.

I hope the Rosetta Code site brings more low level developers to this site so they can help take oxygen to the next level. It is a language that needs recognition and support!

[JRS]

I think it would be great if Charles explained his vision for OxygenBasic. Where he is now, next major milestone and the end goal.