OpenEuphoria

Re: ESL, will it ever get anywhere?

• Posted by Cuvier Christian <christian.cuvier at insee.fr> Jan 12, 2006
• 474 views

> Subject: Re: ESL, will it ever get anywhere?
> 
> 
> posted by: D. Newhall <derek_newhall at yahoo.com>
> 
> (In reply to Chris Burch)
> 
> Chris, feel free to do this if you want, all I ask is not to 
> use ESL or the name Euphoria Standard Library.
> 
> The point behind the ESL (and it's biggest fault so far) is 
> that anyone can propose stuff and we'd agree on everything as 
> a group. I'm sure if Chris Cuvier (the other person who's 
> really into this) or I did it with our word as law we'd be 
> done by now but we wanted to allow the community to 
> contribute with everything. Sadly, this has caused much delay 
> along with Real Life getting in the way occasionally.
> 
> You have the freedom to do this if you want. However, 
> honestly, I'd prefer you didn't since we hope to get 
> everything started full throttle soon (we mean it this time!) 
> and we were hoping to have everything unified, standardized, 
> and full documented. I think lack of uniformity would be the 
> biggest issue. Our naming conventions were made to fit with 
> Euphoria's current scheme whereas with your method you could 
> get stuff like "esl_iGetKey" and then have 
> "esl_process_keystroke" in the same file which could throw 
> off many users.
> 
> 
> The Euphoria Standard Library project :
>     http://esl.sourceforge.net/
> The Euphoria Standard Library mailing list :
>     https://lists.sourceforge.net/lists/listinfo/esl-discussion
> 

In addition, never forget that testing and properly documenting any project
take more time 
than actual coding. Hence the temptation to cut on the former, which
invariably proves 
horribly costly a few months later when trying to debug or upgrade.

The less people work on the library, the longer it will take to be released,
and the lower the maximal expectations about quality (extensivity of
testing, quality of internal and external documentation, presence and
quality of end user documentation, not mentioning the actual contents of the
package). Because people involved may not be professionals and may not have
full days to spend on the project.

Any joiners?

CChris