OpenEuphoria

RE: Eu OpenSource Vision

• Posted by Martin Stachon <martin.stachon at worldonline.cz> Oct 01, 2001
• 400 views

David Cuny wrote:
> Martin Stachon wrote:
> 
> > 1) Get larger user base. The most difficult and 
> >  most important point.
> 
> This might get you more libraries, but why think that they will be any 
> different than the undocumented, buggy, and abandoned libraries that we 
> have 
> now?

I think it is a difference if a library is written by
a simple guy in his spare time or if there are several people
improving the product every day.

> I think that there are enough people in the current set of users to 
> write 
> libraries. The simplest way to do this is to offer a cash incentive. 
> Want a 
> DirectX library? Offer someone cash to write one. Otherwise, you're 
> asking 
> people to do something for you for free. If it's not an itch they 
> currently 
> feel (for example, I don't have any compulsion to use DirectX), they 
> don't 
> really have any reason to write it.
 
I'm now under impression of the Linux world. So many useful
programs and libraries are for free. Nobody is offering the people
a cash. They are doing it just for their good feeling they're
doing something for everyone, and maybev a bit of fame

> I suspect that things will change when Robert starts releasing the 
> Euphoria 
> source code. It will suddenly be a *lot* easier to link Euphoria to 
> C/C++ 
> libraries such as DirectX.
> 
> 
> > 2) Unite programing style and naming and formatting conventions.
> >     I would suggest the standart RDS style, expcept that tabs would
> >     be used for formatting instead of spaces. Optionally create a tool,
> >     similiar to C "indent" to automatically reformat sources.
> 
> How would you enforce this? Not accept code that doesn't follow the 
> conventions?
> 
> Writing a program to format code could be difficult, given that a single 
> 
> statement can wrap over several lines. 
> 
> Finally, some people prefer to prefix variables by their type (iCount 
> for 
> integer counter, for example). Some used mixed case (likeThis instead of 
> 
> like_this) for identifiers. Some use initial caps (This instead of THIS) 
> for 
> constants. Even where to put commas in a constant statement: was argued 
> a 
> while back:
> 
>    -- this
>    constant
>       this = 1,
>       that = 2
> 
>    -- or this
>    constant this = 1, that = 2
> 
>    -- or even this
>    constant this = 1
>    , that = 2
> 
> I think it will be difficult to unite people behind a single coding 
> style.

For example, Linux kernel has a united coding style.
I think the most important ascpect of coding style is naming
variables - it would be confusing to have a library with
fooBar(), foo_bar() and FooBar()

> > 3) Unite way to submit patches. If more people were working on single
> >    project, the current practise of sending whole changed libraries or
> >    describing "change this there and that over there" would be
> > uneffective.
> 
> I haven't heard patch submission as being a major issue.

But it would be good, especially with larger projects.

> > 4) Make Euphoria interpreter aviable for free, or at least remove the 
> > 300
> > statement limit.
> 
> Euphoria is a commercial product. Why would Robert give it away?

A few of commercial products have been given to public.
Binding would remain in the 'commercial' release, but removing
the 300 statements limit would attract more OpSo developers,
hopefully, from other languages. (Why would a Perl, Python, C
 etc. programmer try some 'shareware') Some GNU people
accept no commercial software.

> > 5) Set up a page for Eu OpenSource projects with mailing lists, 
> > info, news, progress status, what can be done, latest patches etc. etc. 
> 
> I don't see how making it Open Source would fix your issues. Removing 
> all 
> commercial incentives could even kill Euphoria. I have no doubt that the 
> code 
> is fairly complex, and would require a lot of work to understand and 
> change. 
> How would you control forking? What problem does this solve? We'd change 
> from 
> the current model of having Robert working on Euphoria full time to no 
> guarantee of anyone working on Euphoria at all.
> 
> -- David Cuny

Rob would remain as the main programmer, while the others would make
some optimizations, bug fixes, testing etc. Lot of people could work on 
the E2C Translator (I think it can be more optimized), while Rob
would have more time.

Just a poor's boy opinion, but I think OpenSource is the future.

    Martin