[Ktechlab-devel] Thinking like a Real Programmer (tm).

[Alan Grimes]

It finally dawned on my pathetically dim mind why I'm having such a hard
time preventing people from making drastic changes to the electronics
simulation prior to the KDE4 port. =\

That reason is that while everyone sees the same needs I do, they do not
understand how I wish to approach them. This is because I have not taken
the time to explain myself.

The problem is that people crawl into the mighty temple of the CPU on
their hands and knees, and beg the CPU to compute for them. The CPU
responds THOU SHALT PROGRAM ME IN C++. And the pathetic suplicants
rejoice and say "Yes, master, we shal program you in C++. We will turn
all our problems into C++ programs for your pleasure.".

Now here's what you should be saying: "Listen up slave. I have some
things for you to simulate. Here the facts, now compute!!" If he says
anything other than "yes master, anything you say, master." you take out
your whip and beat him. That's how you treat a computer.

C++ is a very difficult language. It takes no less than seven years to
master. Furthermore, the API's for linking in runtime modules are
obscure if not undocumented. If ktechlab is to take off, we need to
provide the user the tools to add his own components without venturing
within ten miles of a C++ compiler.

To allow the user to add components, we should not be thinking in terms
of plugins, because plugins are lame. We should be thinking in terms of
declarative programs which the ktechlab engine will interpret and/or
compile itself. -- A new, easier, form of SPICE.

The user will have several options for creating componenets:

-- He can create components as subcircuits in the GUI from circuit
elements and/or anything else and add them to the component library.

-- he can create components by using a part editor to create a library
configuration for one of the built-in models such as for transistors or
triodes. -- the system will hold this as a database item.

-- or he can write a program which describes the matrix and other
equations he needs to create a new model.


To make this work, we need to continue my efforts to streamline and
minimize the code throughout the system. We then need to refactor the
components and simulations such that each part of the simulation
represents, as best as possible, an atomic concept. For example the
Current Source should actually be composed of two elements, a pin that
sources current and a pin that sinks current. By doing this the
flexability and power of the engine will improve radically.

Another long-term headache of mine is the modeling of logic Outs, I've
put a great deal of time into refactoring those classes. Effectively a
rewrite at this point. I had this problem that I wanted to create a
matrix which represented a fixed voltage say 4.8 volts or 0.2 volts, and
a source impedance. Well, I spent days and days, weeks even, going about
it the wrong way. I should have simply linked in a voltage source and an
impedance and called it a day!! =P

Another example. One very accurate way of modeling a diode is as a diode
with a second, very weak, diode pointing the other way. So you get one
set of parameters I_S, and N for the forward diode, and another for the
reverse diode: I_SR, N_R.  The previous code computed both of these in
one go. The current code has one diode junction which might be used
twice to compute the reverse part of the diode.

In summary, plugins are the wrong way to approach the problem of letting
the user program ktechlab. We want the user to program ktechlab strictly
through the GUI, both graphically and through the part editor, with the
ability, eventually, of parsing a new part description language file
with an internal compiler.


-- 
DO NOT USE OBAMACARE.
DO NOT BUY OBAMACARE.
Powers are not rights.