On Sunday, February 14, 2016 at 8:50:43 AM UTC-5, Kent Tenney wrote: > > I had originally seen colored buttons to click and change between the > black, red and green view layouts, but I like the tab idea, create a > 'debug-01' tab which consolidates nodes of interest, a 'doc' tab which > intersperses narrative ...
I too thought of colored buttons in a separate pane but the tabs idea is really interesting. In fact, it seems like they are both good ideas and if possible could be supported. The current discussion of new approaches to viewing node > arrangement sounds like introducing 'edges' to replace the current > 'physical' tree structure in the xml file. That strikes me as evolution > towards a more powerful data storage model. > This was exactly where my thought experiment took me. > As is so often the case with Leo, there isn't really an existing analog, > so it's hard to answer the question *'what would you do with that?' * > Edwards questions are important but this question is probably the most important to answer. Let me try to answer this question in my own experience. Arguably programming at any non-trivial level is about how to best reduce the duplication of code and effort. Leo does many things, but at it's core it is a tool that aides a programmer in manipulating and organizing code. Perhaps the most important feature which supports these two functions is the tree structure. What I like about it is that it adds a layer of organizational abstraction to any programming language. Your language doesn't support breaking up code like that? No matter, here is a tree to organize things to your heart's desire. It's great because the code is organized in a way that makes it easier to navigate and and it's freeing it makes code easier to manipulate. The monolithic tree in itself fails to address the next most important concept of programming, context. I recently started studying x86 assembly language and reviewed the concepts of the stack and stack frame (as described by the C ABI), both of which are arguably the most important entities in the programming world. Their basic abstraction allows the computer to keep track of the context of its operation, protecting it from getting lost in a sea of symbols and memory. Context is key. It's safe to say we're not computers, if anyone posting here isn't I'd like to know. We would prefer to not think in terms of stack frames and single instructions. In fact one of the primary achievements of the C programming language was to hide the fiddly details of the the stack and the stack frame from us. In C we haven't completely let go of the of the stack concept but the frame itself we no longer have to worry about. This allows us to better focus on the context of the state of our program. At this higher level of abstraction we're more efficient programmers. More efficient programmers are empowered to now produce more lines of code. More lines of code mean bigger programs. Bigger programs means getting lost in a sea of code. So what do we do? We produce even higher levels of abstraction, a familiar example being Python. Coding in Python compared to C reduces the amount of code we have to write to get basic things done and making it easier to reuse code. We have a smaller code base now for the same functionality which means we're not as lost and the higher level of abstraction means we're more efficient yet again. So we keep programming and our programs swell yet again to monstrous heights, but now we're stuck. We're not sure how to create a higher level of abstraction for programming languages themselves. Maybe we can get some marginal gains but for the most part our code bases aren't going to shrink down any further. Enter the IDE. IDEs came along to help us organize our code and get a higher level view of our programs. We were given lists of functions, function definitions, class descriptions and maybe even some fancy class diagrams. We became more organized and it allowed us to handle larger code bases. But most IDEs provide all these listings and high level views without taking into account context. All the lists make it easier to navigate code but it doesn't help us gain any insight into the state of the program by viewing the code itself. We of course do this ourselves by checking which functions call which and through debugging but it's hard work, especially if you've never seen the code before. I'll repeat, as the computer knows so well, context is key. If the computer has the stack and the stack frame to provide it context for not getting lost in memory the programmer should have analogous tools for not getting lost in the flow/state/context of a programs code. Not just that but in an ideal world we should also have tools to gain insight into the mind of the programmer that produced a portion of code. The programmer had in their own head (or on paper) a type of stack and stack frame that kept them from getting lost in producing the code that executed a particular algorithm. That context can often get lost in transferring an algorithm to code. So what about the "view" things? *What would you do with them? *They should help provide context into the state of a program given a collection of code and ideally provide the context of the algorithm itself in a given piece of code. The ultimate view will always be code being debugged. I call this the "dynamic view". I say *the* because I really think there is only one huge dynamic view, the active program. Debuggers allow us to look into the active program. But there are limitations to debugging. One is that debugging isn't always possible for a variety of reasons. Two is that debugging is still a whole lot of work and almost always an exercise in exploration rather than a guided tour. What other types of views are there? Well, a "static view". Static views are what we're talking about. The goal of a static view is the same as the dynamic view, provide context to the active program given a piece of code. But it would have to do this differently, because it doesn't have the benefit of winding and weaving through the stack. It would have to *present* the code in a such a way that the context of the active program became clear. There are different ways to achieve this. A static view could simply collect all the relevant pieces of code in one place, reducing the burden of searching and navigation. This "simple" method is quite powerful and it is something that Leo currently offers in the form of clones in its purest form and also through bookmarking and with the quick-search plugin. Each of these solutions has limitations which have already been discussed elsewhere. And so at its basic level a "static view" should perfect the presentation of code relevant to an algorithm or feature as it exists in the active program. Work must still be done by the programmer to put the pieces together (so to say), but if these views can be provided along with a code base it would significantly reduce the barrier of assimilating unfamiliar code bases and generally understanding code. A more ambitious goal of static views would be what I call a "frozen dynamic view". This would be more along the lines of the guided tour I previously mentioned. Rather than exploring the active program the author of the original code would provide a view to you which presented the context of code as it would executed in an active program. Probably not an exact snapshot, but some structure to guide you gently through disparate pieces of a large code base. You're asking... isn't that called a flow chart? The programmer should have made one of those anyway. My experience is that once a programmer reaches a certain level flow charts exist only in the mind and almost never make it into a saved diagram. What if this context could be easily extracted and reconstructed from the code itself. This is where I think the idea of threads become relevant. Threads as we've been discussing them could achieve this goal I think. By manually threading the flow of different pieces of code and including it with the large code base we'd be able to more easily provide insight into how a program works without having to ever run the program. There is a third goal that I see static views fulfilling. Providing a play space for developing algorithms and their respective code. I often find when I'm developing a new piece of code that I often get lost in my own thoughts. What I really need is a way to keep the most relevant pieces of code to what I'm currently working organized in a way which provides increasingly precise context about the active state of the algorithm. I've had some thoughts on this already that I've wanted to bake into quick-search plugin. This is my least thought about concept related to views so I won't go on about it. Really enjoying the dialogue. Sorry I didn't proofread, really interested in any reactions people might have. This really is exciting stuff for anyone wanting to dissolve the barriers between programmer and code. -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
