OpenEuphoria

Some random topics

• Posted by DB James <larches at co?cast?net> Aug 03, 2007
• 464 views

Several random topics due to idle note-taking:
--=====================================================================
Basic rule of the game:

Break no pre-existing code unless demonstrably necessary, and it is
rarely necessary
	-Can add keywords to Eu with no problem
	-Can add routines to libraries or interpreter with no problem
	-Can optimize any routine if the behavior is same otherwise
	-Can modify routines with a returned sequence by adding onto it
	-There is almost always a way.
--=====================================================================
It would be helpful if coders' "best practices" could be listed as
this would push many a programmer up a notch.  I think this should
be seen as a non-controversial area, just "this is what I do".  Also,
I would recommend it be in a separate web page, rather than in the
forum.  In fact, several matters should be more permanent than the
ever-changing forum.
--=====================================================================
I am wondering: how much of a penalty is there for combining libraries?
	-Have a std.e file with all the official Eu includes in it
	-Has anyone tested this in detail?
	-Does a penalty carry over to compiled code?
	-(At what point do old issues die that relate to previous 
				computer speed/memory capability?)
--=====================================================================
Would it be worth having "official" coding aids that have been
optimized by the "open source model"?
	-preprocessor (this would be tough to do well, may be impossible)
	-Sanity, testing, timing aids, time-profiling in all OSes
	-best diff on the planet
	-Eu html editor for help files
	-Eu compiler (fat chance, but would be kewl)
	-What are the best ones we have already? (Need list.)
--=====================================================================
Most disagreements among coders are due to different emphases on:
	-speed
	-clarity
	-simplicity
	-generality
	-utility
	-intuitiveness (works as one would expect)
Unfortunately for problem-solving, there is no demonstrable 
"best-practice" for these.  (When in doubt, use the KISS principle :)
--=====================================================================
Types of routines that need to be optimized to the nth degree:
	-"Atomic" routines out of which more complex ones are built
	-Routines which are commonly used in loops
	-Others?
--=====================================================================
"Open source model":
	-problems ==> sub-versions ==> merging-to-test-program ==> 
			testing ==> reporting problems [repeat]
	-Distinguish between test program and stable program
	-Need to have more objective testing and reporting
	-Decision-making not much touched-on in Wiki descriptions
	-Decision-maker cannot be seen to be a partisan
	-Key principle: release early & often so "many eyes" can see bugs
		Corollary: Maintain ultra-stable version separately
	-Alpha version: bleeding edge
	-Beta version: test, merge and test again
	-Delta version: looks good to go, final testing
	-Omega version: published, stable -- the "official" version
--=====================================================================
Eu is open source: there is no longer a reason to limit what is 
included in the installation -- good libraries and utilities can
be part of the official package as long as the original coder agrees
to release the work under the RDS license.
--=====================================================================

--Quark