Outliners vs. Inliners (and a little intro to programming with Outliners (but not Inliners, sorry, Steve!))

Posted by Fredy
Sep 4, 2012 at 10:24 PM

Alec, if I misunderstood your question, reformulate. As I understood it, I can answer as follows:

In any outliner(2/3), I structure all my stuff as I would do in a W/O diagram, or you can even do the same within a program like MindManager, or even within a W/O diagram (but not with B-liner, but perhaps with MindApp, same developer). Problem with B-liner is, you only have 80 or 100 chars for “footnotes” for each item, whilst you need a real “note” field, for doing the “real code”, i.e. the routines - no need to bring the W/O system to excessive details, you can perfectly do routines, with 4, or with 80 lines, as compact “notes”: W/O diagrams are good for the overall structure, but if you find yourself with thousands of W/O items (even distributed on many sub-diagrams), I think you did “too much”, especially so since W/O isn’t real code but pseudocode, so trying to follow with W/O into the “body” level of a program seems a lot of unnecessary work to me. Structure: tree / W/O; routines: “notes”.

Then, you will have the structure within the tree, be it a vertical outliner’s tree, a horizontal W/O tree to the right, or the horizontal “mindmap” tree (also to the right) within MindManager or your Mind… what’s it called again. The important detail is, it should allow for plain-text export as is possible in most outliners, with all headings / subheadings / nodes of any indentation level immediately followed by the corresponding “note”, i.e. not “notes export” separately (and that’s why I don’t know if the W/O diagrams in MindApp will do; I spoke to B-liner’s daughter (I think), and she said B-liner will NOT be enhanced in any way in the near future, so if MindApp doesn’t allow for this way of export, any automatted W/O diagram will not be available).

Then, this complete plain text export will, by scripting / macro, straight go into a text file, like a text file you would have created with an editor, but WITHOUT any editor use! Yes, I tout editor use, for other things, but not for programming!

Thus, you’ll have a plain text file (whilst in your outliner, in MindManager, or something, you will have formatted text, just as it pleases you there in order to better structure your program (components), and, again by scripting / macro, you’ll compile it.

From your “production tool” (outliner, mind map sw, whatever), you will “export”, as said, but need not export the whole thing, each time. If you have a big application in one such file, you’ll first select your “main topic” / “source topic”, do your trigger command, and several seconds later, your target program will be compiled anew - no switching to any editor or such needed, just export into file, then compiling.

And if have any fractioned program to develop, either you do it with several outlines / mindmaps / W/O diagrams (if MindApp works as hoped for), or you’ll have one central such mindmaps, etc., and do the “export and compile” command from the item in question that is the source item of that separate file or the sub-mindmap or whatever - have the same trigger command trigger the same procedure from any such - original or intermediate - “source item” = source item for the big subtree of that item in question that the “export” command will build up.

When your projects develops, you’ll place the initial consecutive A, B, C:

0
-A
-B
-C

under an intermediate “1” and begin an intermediate “2” for a second program component:

0
-1
—-A
—-B
—-C
-2
—-A
etc.

Then, you select “source” item 2 and trigger the “export and compile” script / macro.

This is perfectly possible in a network since sw like UR or MM are network-ready, i.e. anybody could trigger such partial recompile commands from within those parts of the “overall tree” being available to him.

If you don’t like all items (= items’ titles, the nodes in a diagram or the items in an outline tree) beginning with a comment char, you can easily extend your script or set the options in the export function of your design tool in a way that any such heading will be preceded by exactly the comment char of the given programming language; such an automatism will make your diagram / tree even neater in its appearance, whilst it takes the option from you to have a mix of pseudocode and real code in these items, but perhaps it’s a good thing to avoid such a mixture in the first place, so in a sub-routine’s title, you would write “while a > x”, which would automatially be preceded in export by “//” or whatever is needed to comment that line out, and as first line of the “note”, you’d replicate this “while a > x”, not the least for better understanding the 60 lines or so that’ll follow within that “note”.

It goes without saying that there are numerous projects in which you would need several programming languages, all with their specific comment chars, so in the end, putting the (adequate) comment char right into the item’s title would perhaps be preferable, but then, you’d probably only trigger “export and recompile” for one such component with one programming language, so it would be sufficient to put the adequate code to the respective source item, then having a routine replicating that individual code onto any subsequent (“child”) items.

I know that in this scenario you don’t have automatted formatting, etc. for your specific programming language(s), but you can do lots with scripting and text expanding, be it for “difficult to remember” commands, be it for 1-key typing of commands very often needed; remember in scripting languages you can use global variables, so it’s possible to have just some keys but dozens of such pre-figured commands at your fingertips.

I must make a reservation: My system will not function with programming languages where indentation levels of the code is a constitutive element of the program syntax itself, since my system simply doesn’t care about indentation levels of the code, and chances are if you have a look at the straight output, via opening the text file in an editor, it appears horrible to you. But then, you will “never really see” this horrific intermediate output, since any debugging is then done back in your production system (you’ll just have a look into what the debugger presents you just in order to identify the place to look into, within that production system).

So much for MY system. Of course, you can optimize it, with more scripting (or just simply by checking more options in the export function), so that the intermediate file, that will then be re-opened by the debugger, will have correct indentation, blank lines, etc.

So, if your question was, how to assure that the debugger will “open” your production system at the “right” line, I’m sorry, that would need LOTS of further scripting. But for me, its perfect for everything I’m doing, and I even put my ancient programming into such a structured system (in order to contemplate, and perhaps to re-use lots of the structure of that code some day).

I particularly savor, except for the extradordinary structurization (which in a collapse editor is not possible to this point, or let’s say, not as evident there), the fact that I can freely format my code, which I heavily do, in the tree and in the body.

I concede that better debugging facilities (= without the necessary step of looking up the incriminated lines, then search for them within the production tool) would be very welcome, but then, just compare my system with original W/O:

In W/O, you necessarily do DOUBLE WORK, any change within the graphical represenation must then manually be replicated by hand, within the body (= editor files), and vice versa, which is very time-consuming, very dumb work, and very error-prone. My system isn’t perfect, but all is done within ONE production tool, not in two that must endlessly be synched by hand.

(As for automatic synching, of structure AND content - synching just structure would be devoid of sense -, between, let’s say, UR and VisualMind, well, I kindly explained the interest of such interoperability to both… and never get an answer from either.)