I have been playing with XOD on and off for a while now. One of my main problems with it is the difficulty of using the “not-implemented-in-xod” node. I found that, once I got down to the nitty gritty detail of developing my programs I always ended up coding something in C++. However I am not a C++ programmer. I’m not really a programmer at all, but I have learnt a fair bit of C along the way using Arduino (and some superior tools such as PlatformIO). I have found the implementation of anything in the not-implemented-in-xod node an exercise in frustration because of my lack of understanding of C++.
What I would like to see in the not-implemented-in-xod is, instead of a straight text editor, something a bit more user friendly. Maybe several sections or windows where program text can be entered, but without the complex and confusing C++ syntax. Maybe a section for persistent data, where the various data items can be defined and optionally initialised (possibly using C syntax), which would replace the existing “State” processing. Then a section for “local data”, again with data items defined using C syntax, but where each data item must be initialised to a value, and will always have the initial value when the node is entered. This section would not include input/output variables, just local temporary variables used for calculations, temporary storage, etc. Then maybe a section that is executed only once (again C syntax) on the first execution of the node. Then a section that is executed (you guessed it, C syntax) every time the node is executed, like the “loop” section in an Arduino program.
I would then like to be able to reference, in the initialisation section and the “loop” section, the inputs and outputs for the node by simply referencing the input (or output) name. e.g. if I had a node called myNode, with an output called myTrigger, then in the code I could specify “myTrigger = 1”. Similarly I could reference inputs by just referring to the name, e.g. "if (myInput == true) {do something}. Whether the node is an input or output node doesn’t matter, the reference technique would always be the same. Needless to say all the variables defined in the persistent section and local section would also be available.
I think that a setup like this would make it a lot easier for those of us who do not speak fluent C++ to get our code working, with all the complex C++ syntax hidden away where we can’t foul it up. It would also make it easier for noobs and non-programmers to transition to XOD from straight code editors as they would already be familiar with the coding paradigm (i.e. “C” coding) for creating their own nodes.
The concept may require some tweaking, as XOD is not, to my understanding anyway, a strictly procedural language, like C. But I think if it was possible to simplify the process of building your own bespoke nodes it would make life a bit simpler for all of us.
Regards, Ian
Hello, Ian!
Thank you for the deep analysis. The idea of sections is pretty bold, I like it in general. Doing it right will require significant effort though. I foresee very-very many edge cases, naming conflicts, error handling questions, etc.
So, why the problem even exists? Why can’t everyone who knows nothing in C++ stay away from C++? Yes, it’s because the coverage of “pure” XOD is too thin now and you have to fall back to C++ way too early. I think we should focus on things which make XOD itself more expressive and wide leaving C++ for optimization and interop stuff.
Thanks for the reply. I should confess my idea is not original. I’ve been playing with another tool called Embrio (embrio.io) which has similar objectives to xod. It has a very neat and effective way of including bespoke code in a node (or “agent” in their terminology) that is easy to come to grips with for someone who has only done a bit of C programming in Arduino. Embrio has some nice features but is not as stable or comprehensive as xod, in fact it seems the intention is for the developer to write most of the code, but Embrio breaks it up into small units (“agents”) and manages their interaction. Neat and powerful. However the Linux version at least is a bit flaky and sometimes things just don’t work. The Windows version seems a bit more stable, and, from conversations with the developer, I understand that he develops on Windows then ports to Linux (and Mac). I guess it will improve in time, but right now it is not really usable.
My original thought when writing this post was that a simple preprocessor would be enough to convert code in the various sections (as I imagined) and combine everything into a C++ module that would be the same as a bespoke one written in the existing system. I don’t know all the use cases or edge conditions as my view is, of course, limited to what I want to do, and I have no idea what everybody else will be doing with xod.
I like your idea of building more xod nodes, but it seems to me you can’t possibly predict what everybody will ant to do, so you will never eliminate C++ code completely. So you will either end up with an enormous number of nodes, or they will have to be generic enough and tailorable enough to meet many different requirements. In my case I wanted to setup some registers in an Arduino Nano to make one of the timers generate a PPM stream for a radio control transmitter, a problem you helped me sort out many months ago. I don’t think there will be too many people needing a xod node to do that…
I would think there will also be so many microcontroller specific functions that you can’t possibly cater for all of them. On top of that, while it may be possible to achieve what you you want to do using pure xod nodes, in some cases it will be orders of magnitude easier to just knock out a bit of code to do it than try to do it in pure xod. From that point of view the Embrio model makes a bit more sense. It forces the developer to focus on the individual bits of functionality that the program requires, while the management of data and control flows is managed by the hierarchic diagram that requires no coding at all.
Anyway I’m continuing to play with xod, or I will be soon. Currently (and for the last three months) I’ve been moving house and moving interstate, and so have had no time to scratch my bum never mind doing anything fun. But we are on the home straight now, so I will be getting back to my toys soon!
Cheers, Ian
I see what you are talking about. The way Embrio does it, that is a drop-down which sets the code “section,” is easier for newcomers to start with, but in the long run, it introduces too much magic for a user and for the IDE code itself (my humble opinion, of course). The more magic, the harder maintenance is. Furthermore, such a design gives no answers to all C++ questions: “How do I set up some registers to make one of the timers generate a PPM stream?” You’ll still find and copy-paste some snippets from the internet.
We have a statement written on the wall in our office. The translation would be: “Complete everything doing nothing.” It means we’re trying to find ways to re-use existing mechanisms to solve as many problems as possible. A new subsystem, UI flow, or concept should only be introduced if there’s no possibility to apply a combination of existing things. That’s why we are able to keep XOD relatively simple to get.
Given that, I’m thinking how can we improve the situation with C++ and stay simple at the same time. One idea originally told by @brusher may work fine: what if we put a collection of C++ snippets to the Quick Help sidebar which will show up when the C++ editor is open. Clicking any of them would insert it to the editor. We might have a wide variety of snippets:
- Getting and setting pin values
- Dealing with time and timers
- Keeping state
- Initializing once on boot
- etc
Will it make XOD more accessible in the way you are talking about in this thread?
“Complete everything doing nothing”. You must be a taoist monk or zen master.
The snippets idea sounds good. It sounds like it would go some way to doing what I’m talking about, by removing the need to understand complex C++ syntax, and just type in the names you’ve defined in the appropriate spots (assuming you can identify them!) I’ll be interested to see how it works.
I think I understand what you mean by “too much magic”, by hiding too much functionality “behind the scenes” the code reliability and simplicity may be compromised, and you end up with a similar problem of not being able to accomplish the goal due to restrictions in what functionality can be specified. I would agree with that assertion to a degree. But I think that for less experienced programmers who don’t have a deep knowledge of C++, or even with only a basic knowledge of simple C code, the more magic you can provide, and the more C++ syntax you can hide, the more likely they are to get their code working. For more complex problems and expert programmers access to the raw C++ behind the node would still be required.
Anyway, just my thoughts.
Ian
Well I guess you didn’t like my idea much, so I had to write my own version. It’s a simple Python script but it does most of what I need. xodbuilder.txt (541 Bytes) is the input file. Pretty simple. xodTranslatorVSCodeV2.py.txt (2.6 KB) is the python script. Pretty basic and probably poorly written. But, as I said, it does most of what I want it to do. I had to rename it as you don’t allow uploading files with a .py extension.
Cheers,
Ian