Ben Bacarisse
5/16/2015 10:06:00 AM
jonas.thornvall@gmail.com writes:
<snip>
> Well it is a hobby project afterall and i think the development using
> a RAD like approach. The global aim for the project is to show
> different ways of doing highlevel arithmetic in bignumbs, and show how
> the format/interpretation rules of digitplaces and symbols *at
> highlevel* do affect the arithmetic performed at binary level, and how
> the computational complexity changes with the tools used.
I think you are misusing tterms here. Analysing computational
complexity needs no code at all. I think you want code to demonstrate
the practical costs of what you imagine doing.
> The specific need of algorithms and functions of this project is not
> welldefined, so i can not make a flowchart, or an object tree model.
That does not inevitably lead to bad code. In fact RAD needs very good
code because the idea is to change it frequently as the development
progresses (refactor is the jargon term). At each stage you do have
well-defined goals: read in a number, print a number, convert from base
A to base B, and so on. But as the goals get more complex, the design
and code keep getting re-written to accommodate them. You don't just
keep adding more and more globals.
And there is nothing "rapid" to choosing bad names. Calling a function
"isLessThan" is not slower than calling it "compareTwo".
You will get stuck at some point. You will end up with code so tangled
that you can no longer change it without catastrophic effects on its
behaviour. I think you are already close to that point.
You should spend at least half of the project time learning to program,
or you will simply not be able to finish it.
> The functions and algorithms are developed as the need for them occur
> that does not mean i do not want general working code, quite the
> opposite there is a need for it since many functions work upon the
> same operand arrays.
This is why you must avoid globals. They will mess up the key
separation you need to have bignums with bignum bases. If do nothing
else, do this. Remove every global variable that you can so that
all your functions compute results only from their arguments.
> And that is why they are global, it is not like the program is a big
> main with endless nested loops. It is quite welldefined functional
> behaviour, but i agree my comments are absent, and the variable and
> function naming sometimes misleading.
Every programmer will tell you the opposite. This is not a conspiracy
of dunces. It is, very often, the result of bitter experience. I
started by career helping professional scientists who were, in those
days, forced to be amateur programmers. In every case, the programs
were a tangle of subroutines intertwined by information flowing though
global variables. In some cases I could do nothing but say "start
again".
> That is a RAD problem the full plan is not thought thru.
RAD does not imply bad programming. It's not an excuse. In fact it
makes good structure essential.
--
Ben.