On Thu, 27 Dec 2012 02:44:36 -0600, John Fields
wrote:

On Wed, 26 Dec 2012 18:55:26 -0800, John Larkin
wrote:

On Wed, 26 Dec 2012 16:12:06 -0600, John Fields
wrote:

On Wed, 26 Dec 2012 10:43:48 -0800, John Larkin
wrote:

On Wed, 26 Dec 2012 10:27:12 -0600, John Fields
wrote:

On Tue, 25 Dec 2012 19:54:15 -0800, John Larkin
wrote:

On Tue, 25 Dec 2012 14:32:38 -0600, John Fields
wrote:

---
Just an ad hominem attack, and I'd say it was PKB, what with your not
knowing what source code was, and all.

What I didn't know was where the source code was.

---
If that were true, then you would have asked for the location of the
source code instead of questioning its existence.

Besides, I posted both the source code and the executable, so anyone
who knew what source code was should certainly have been able to
identify it as such.

Didn't I turn you on to PowerBasic?

---
Yes, thanks.

I'll be indebted to you forever.

Then you might appreciate that I know what "source code" means.

---
You do now, anyway
---


I tried that with Jim, but he bailed.

---
Why is that germane?
---

I've written over a thousand programs, including hundreds of embedded
apps, two compilers, and three RTOSs. Of course I know what source
code is.

---
Strange then, that you didn't recognize mine as that.
---

I asked where it was, not what it was. You posted a binary and said it
was in uppercase.

---
What twaddle!

I posted the source code in lower case, and posted the executable as a
binary file which, upon examination with an editor, will of course
contain upper case characters.
---

Who cares whether you can program Basic in lowercase? It's just
cosmetics.

---
The same can be said for your penchant of trying to make BASIC source
code look like old FORTRAN, so PKB.
---

But that's just the way you are, you make mistakes and then try to
cover them up later by moving the goalposts or trying to place the
onus for your errors on someone else.
---

As far as the PKB thing goes, I'm an EE and you're not. You are an
amateur.

---
Not being an EE or any other kind of E has nothing to do with being a
professional but, of course, in your effort to belittle your
detractors you choose the ad hominem attack because if you were to
argue logically you'd lose face and, Lord knows, we can't have that.

Get professional and design some non-hairball, hazard-free, non-RC,
properly synchronous logic.

---
"Properly synchronous logic", according to you, means subjugating
everything to the edge of a clock, even when it's not warranted.

Kinda sad, but expected.

What's wrong with making stuff that works?

Red herring, but addressing it anyway:

AFAIK, nothing, but the way you go on about yourself being the
unconventional rebel EE rulebreaker, one would think your hard and
fast stance about not breaking rules about which you pontificate as
being inviolable smacks of hypocrisy.

In other words,: "Do as I say, not as I say I do."

Synchronous programming isn't a religion or a rule. It's just a fact
that even trivial async designs are wont to have bugs, and serious
async designs are so bug-prone that they are rarely done. You have
posted several async designs that had low-probability (ie, long-period
intermittent) bugs. You either do that to prove that async design is
safe (which you have proved the opposite) or because you don't
understand how to do reliable synchronous logic design. Safe
synchronous logic design can be taught in about 15 minutes on a
whiteboard. I got straightened out on this when I was still a
teenager.

When logic was expensive and problems were simple, like up to around
1970, some people still tended to do async design. DEC's PDP-8,
PDP-8/I, and PDP-11/20 were async computers, and they were ugly and
buggy, full of one-shots, RCs, and delay lines. Later versions were
fully synchronous, simpler, and much more reliable (except for the
legacy async Unibus part.)

A synchronous state machine can be documented and analyzed. Every
state and every state transition can be known and controlled, and
there are conventions for doing so. Async systems really don't have
distinct states, and transitions happen all over space and time,
creating endless hazards.

No serious enterprise would hire someone if they knew that they
preferred ad-hoc hairballs to serious state-machine design.