SynthModules

Official Olde Phaarte Doc here,
Why... why why oh WHY! do you guys** always pop the most interesting
threads when I'm pinned under the worst schedule crunches........
>oh yeah<
MURPHY's law!
(thank goodness LUNCH is still sacred!)
;'>
ahem-
(cue: Elgar's 'Land of Hope and Glory' for parody effect of
ridiculously officious and facetious lecture from dr.mabuse ...)

> Now, I understand that all you "early adopters" have gotten used to
these
> names. However, we all hope that the future will bring more people
into the
> PSIM fold, so an effort to make the standard names more
understandable may
> be good in the long run.

> There are some IT pros here, 
> 
Hi my name is Mike and i'm an IT pro...
(group of hopeless, downtrodden-looking, middle-aged virgin geeks all
mumble:"hiiiiiiii mike")
because , at least one corporation is still willing to humor me with 
a paycheck to write code despite my competition from inmate slaves in
Hunan Provincial prisons.

...and i strongly endorse ALL standards as long as i can write
whatever i want in my code...
 
> 
> I. ALL CAPS
> Why are we using all caps? The language is not case sensitive. Just
curious.
> 
> 
in my case, pure habit! simple keypad finger-muscle-memory!
 In my day-gig i write and analyze several hundred lines of a form of
BASIC every day. This form requires all-caps to distinguish
executable code and i've worked in this environment for 20+ years,
thus: 'dyed-in-the-wool' doesn't even begin to how deeply ingrained
my BASIC keyboard habits are.

PS: (everything prof. Richter cited in his response was true and
complete - I was the first coder to port the teletype playboy images
from GCOS to the Microdata Reality OS1A-800 to the delight of
businessmen of modest means everywhere)


> II. Designator for common variables
> to adopt a prefix (or suffix) to identify them. Perhaps a lowercase
"g" (as
> in "global", although all vars are global) so we would have gADC1
and
> gDAC1V. Maybe "psim" is a better prefix. (Maybe I should just shut
up! ;-)
> 
> An alternative would be to leave the existing names alone, and use
a prefix
> on one's own variables: myNote, myLoop.
>

Copy/Paste is endemic to the way i build my PSIM code, so whatever
conventions were hardwired into the code i'm stealing determine the
standards i use. This tactic is a simple survival instinct i
developed in the 'wild'. There are, of course, cases where the
benefits of retrofitting/renaming a set of VARS outweighs the time
and effort required to do so, but by and large, the conventions i use
in a PSIM program are simply determined by the predilections of the
victim of my code-shoplifting. 

i officially recuse myself from this case because PSIM code is
recreation for me and i just scratch whatever itches at the moment.
For my part, if i were to start fretting over whether a piece of PSIM
(read: FUN/LEISURE) code  failed to pass muster vis-a-vis 'shop
standards' the work would start to resemble WORK and my attention
would be immediately shunted to LUNCH! and nothing would ever be
finished
;'>
 
> III. Names
> Some variables have nice, descriptive names, like STOPLED. On the
other
> hand, the Stop button is IN5. Why is that?

IN5, IN4 came from the BasicAtom datasheet -refers to hardware
interrupts on the BAsicAtomPro24

> 
> And then there are ADC1, DAC1, and DAC1V. What's this about? I know
that the
> inputs are ADCs and outputs are DACs, but the PSIM is labeled IN-1
thru
> IN-4, and OUT-1 thru OUT-4. 

(chuckle)
in ---some very early cases-- the PSIM had no panel labeled IN-1 etc.
 just ADC & DAC chips 


Therefore, I suggest that ADC1 would be better
> named "In1." DAC1V could be "Out1." Isn't that more intuitive?
>

it sounds more intuitive to me but-
(to paraphrase another Psimian)
one fellow's intuition is another's nightmare, that's the
ETERNAL wrangle with standards, whose nightmare gets declared
'intuitive'
 
> 
> 
> That's about it. Please try not to flame me too severely if you
disagree.

i realize i'm being glib, but i'm very protective of any
opportunities that i get for zany madcap misadventures in code
because of the hidebound nature of my day-gig work.
But---To get un-zany for a paragraph:
I have served on standards committees for two companies (that are
still in business- woo-hoo!) and the position that has evolved
between my ears is that only two approaches work:

1) Pax Romana 
TOP-down, Judeo-Christian, Monotheistic, ONE-way and ONE way ONLY
...and if you fail to conform it's off to tech-support with ye!
-i think this method has NO chance of survival in the PSIM community

2)Linux/Open Source Anarchy
  allow the cows to wander wherever they will for a few YEARS. After
a while, the most acceptable 'paths' will emerge 'organically' from
the grass... THEN (and only then) you pave those cowpaths. It's
rarely 'elegant' but you get the maximum amount of buy-in from the
maximum number of your 'cows'
-If the Psimians are hellbent on a standard, i recommend this method.
It will take a year or two after the PSIM is as widely distributed as
 Brice can make it --so this path requires great patience. In the
meanwhile prolific, prodigious and various schemes slug it out for
the hearts and minds of the coders. It's a messy process but my
experience is that yields a remarkably 'sustainable peace'

i overlook a lot of the Linux standards in my open source code too
(in bugs bunny voice, ain't i a stinker???)



> There are some IT pros here, so I'd like to hear what they *and*
the novice
> programmers have to say.

novice programmers????
here in america???? don't do it kids!!!!
just say NO!
move to the Kashmir and maintain ORACLE (harems are almost legal
there!)
or Belgium or Slovakia and write OutLook trojans in VB....
Look at what it's done to me!!!!
Run kids RUN!!! Run for your liiiiiiiiiives!!!!!!!!!



> 
> Wow, thanks for reading all the way through! :-)
> --

and likewise!!!!
enjoyed the rumpus!

-Doc

**
sorry for the chauvinism but so far it appears that the PSIM is as
much an all male pursuits as Snow-Calligraphy. I'd be delighted to
find out differently