1. Some random topics
- Posted by DB James <larches at co?cast?net>
Aug 03, 2007
-
Last edited Aug 04, 2007
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
