On Sat, 14 Dec 2019 at 01:06, Booth Martin <booth@xxxxxxxxxxxx> wrote:
1. State-up, City-up
2. State-up, City-down
3. State-down, City-up
4. State-down, City-down
5. City-up, State-up
6. City-up,State-down
7. City-down, State-up
8. City-down, State-down
State-up, City-up != City-up,State-up
If I choose to use the motorcycle to travel from A to B before I work
out the reason for the travel, I may be unhappy when I discover that I
need to help a friend move furniture. qsort's implementation is
multiple procedures. If that produces unhappiness, perhaps the
journey's end isn't yet defined? If the purpose is to practice with
qsort, then the number of procedures shouldn't make one unhappy.
We programmers tend to have an allergic reaction to someone telling us
that 'you need more structs, procs, programs, tables, etc'. But more
modern techniques often rely on just that notion - instead of a
massive 500 column all-in-one table, break it into relational pieces.
Instead of that mammoth 10000 line program, break it into
sub-procedures that can be tested individually.
If you are embarking on a journey of education, consider this option:
Write that 'sort' function with several sub-procedures. All in the
same service program/program. One that uses qsort, one with SQL, one
with the sort API and for kicks, how about one that dynamically
creates FMTDTA specs! Your program can flip between them seamlessly,
since you'll be writing these all with the same PR/PI. Once you have
several... models to choose from, you'll have several models to choose
from! Each one tested and working using the same data. Sub-procedures
are pretty sweet for A-B comparisons like this. Once you can see the
level of effort it takes to write, understand and maintain each
'model', you'll have a better understanding of which one you'd like to
choose for what situation. Now, and in the future.
I envy your journey (in the good way)!
--buck
midrange.com
