10-03-2007 02:48 AM - edited 10-03-2007 02:48 AM
Message Edited by kaêm on 10-03-2007 10:49 AM
10-03-2007 07:55 AM
10-03-2007 08:25 AM
Adding to Jeff's comments;
Many of the contributors here and on LAVA are or were C-coders, so you have a lot of experience to call on.
Unfortunately I have not written that book (yet) and to the best of my knowledge, nor has anyone else.
What I can tell you (in the Reader's Digest version) is;
Stop Thinking in Steps!
It is a common mistake for C-coders to simply rotate their code 90 counter-clockwise and use sequence structures to define the order or the operations. Not only is this bad style, it also puts atrificial restrictions on LV. Think about what needs done and let LV determine the order.
Wire are Named Variables!
Another mistake C-coders make is again constructing LV code like it was C. In C you can read from a named variable and write the result back to that variable. The name of the varible was very helpful for me to keep track of what I was coding and were data was. LV will determine by itself what variables you need and will create and destroy them as indicated by the code.
The variables are the wires!
If you really need labels to keep things straight, then put free lables over the wires to make you life easier.
Approach your application from the top down!
The operators of C were designed to be implemented on any machine hardware( almost). THe available machin language instructions were reduced to the basic operations required to accomplish any task. LV has done the same thing but from the other direction, i.e. insteed of looking at the machine code, it was designed from the view point of the "Human code".
Keep your code modular!
When coding I find it best to concentrate only on the current task at hand. When I coded in C, I had to think about getting back to other tasks that I had started to make sure they are progressing properly then jumping back to the task at hand. This is a natural response to the single thread nature of a text based launguage (yes I known more thatn LV cand do multithreading). Since LV handles all the scheduling I don't have to thenk about other things but can dwell on the challenge before me. The extent of the thought is limited to making sure I don't use up all of the CPU and I leave some for other processes to use.
Globals Are Evil!
The multithreading aspect of LV allows for race conditions if protected sections of code are not protected. Many ex-C programmers will use Global varibles they way they are used in C. At best they can serves global define statements. There are better methods of sharing information across threads. Learn what Action Engines are and use them, queues or other mechanisms to share info.
Ask Questions!
LV has acquired a group of nut-cases (like myself) that love LV so much that they want others to learn to love it as well. Let us advise you when you run into a challenge.
Answer Questions!
Once you get a handle on LV take the next step and try answering any question you think you know the answer to. If you get it correct, you will have re-inforced your knowledge and you may even get some stars or nice comments from the experts. If you get it wrong, someone will generally step in to correct you and set the record straight.
Ben
10-05-2007 01:42 AM