201–210 of 222 posts
Earlier quoted context omitted.
Went to try it out but it requires signing into your twitter account and they get access to: - Update your profile. - Post Tweets for you. That's not cool.
OWL is a nifty fork of Dave Winer's work that stores all data locally and doesn't require a Twitter account. https://github.com/interstar/OWL
Good stuff.
>> We need a solid, simple program that can simply edit trees. I might be misunderstanding this but a "tree" is a graph, so formally a tuple G = {V,E} where V a set of vertices {a,b,c,....} and E a set of tuples: {{a,b}, {b,c},...} so that each a,b,c,... are vertices in V. So for instance, the graph: a | / \ b c | | d e Would be written as {{V,E}: V = {a,b,c,d,e}, E = {{a,b},{a,c},{b,d},{c,e}}} possibly accompanied b…
Your representation is certainly valid , but I think those properties (light-weight, intuitive, etc.) apply to your example rather than your representation. For example, imagine representing the HTML of this Hacker News page in your format; it would be completely unwieldy, and Hacker News is notoriously simple as far as HTML goes. It's clear that this representation is massively space inefficient, since it repeats th…
Well yes, but that's because HTML is a mess, not because graph notation is unwieldy.
In any case I don't think it's a good idea to try to program in graph notation, or anything like it. Actually, I think it's a terrible idea. Unless you want to create some kind of help tool for graph theory, I guess.
>> Proof assistants are incredibly picky about what they allow (that's kind of the point ;)
As are all programming languages. Manipulating graphs, er, graphically, will not give you some sort of magical get-out-of-jail-free card against syntax errors or undefinable behaviour etc.
Like, I'm not even sure what the point is here, with the OP. Is it along the lines of "hey, look at graphs, graphs are cool, let's make coding cool with cool graphs"? Or is there some sort of benefit, like expressive power or syntactic clarity, that you don't have with high-level languages already? Why do you need a GUI to an AST? To be honest, the OP looks like a bit of a muddle to me.
>> We need a solid, simple program that can simply edit trees. I might be misunderstanding this but a "tree" is a graph, so formally a tuple G = {V,E} where V a set of vertices {a,b,c,....} and E a set of tuples: {{a,b}, {b,c},...} so that each a,b,c,... are vertices in V. So for instance, the graph: a | / \ b c | | d e Would be written as {{V,E}: V = {a,b,c,d,e}, E = {{a,b},{a,c},{b,d},{c,e}}} possibly accompanied b…
Would that support an edge between b and e? That's what determines whether something like an outliner would be a good UI for it. If you need that support, then the UI becomes more difficult - you either have to "draw" the graph visually, or have a continually adapting approximation.
A UI, now that's a different issue but I don't see why you need a special UI there. It just sounds like a bit of a gimmick to me, to be honest. Or probably it's just that the OP wants to use graphs (trees) for something that doesn't really need graphs? As in, yeah, you can represent computation using graphs -you can represent all sorts of formal stuff with graphs- but that's an implementation detail.
Like, why have a GUI to an AST and not a GUI to your computer's 1s and 0s, in RAM? Or a GUI to your processor's registers? It's just a very unnatural way to program, really.
When you have text, you can interpret the string as a number and you can count the possible files: "0x01", "0x02", ... "0x0101", "0x0102", ... "0x010101", ... -- all of the possible files are enumerated by a single increasing sequence. This corresponds to the ordinal "omega-0".
When you have a table, you can interpret each row as a number and now you have an arbitrary number of infinite increasing sequences, but you can imagine a transfinite "sequence of sequences" that counts the tables with 1 row, then the tables with 2 rows, and so forth. This is a single infinite increasing sequence of infinite increasing sequences, which corresponds to the ordinal "omega-0 squared".
But when you have a tree, there's an infinite increasing sequence corresponding to... every single finite tree! In fact, there are multiple increasing sequences corresponding to every finite tree, and infinite sequences associated to those sequences, and... anyway, tree-counting functions are very hard to define at all, but with a little bit of work in combinatorics you'll find something called a "Veblen function" which is defined so that the parameter of the function is the number of levels of recursion of infinitary functions applied to themselves, and then the fixpoint of the Veblen function itself is the Feferman-Schutte ordinal, which cannot even be defined in first-order logic! One example of the horror that results from counting trees is Kruskal's theorem:
http://en.wikipedia.org/wiki/Kruskal's_tree_theorem
In other words, trees, which can encode arbitrary structure, are much more difficult to do math on than tables and flat files, which can only encode simple structures.
Workflowy is pretty nice, it exports to plain text and xml. https://workflowy.com/
I wish for something more sophisticated than workflowy, but I can't stop using it!
One huge question to ask is why you need an editor specifically for a tree. Do you want a gui, or a format? If you need a gui, you are automatically in domain-specific territory. If you only need a format, maybe you don't need a tree editor at all. Excel is a great tool for making trees; just add a column that names your parent. I used Excel to create a prototype of an event driven animation sequencing engine for a D…
> If you need a gui, you are automatically in domain-specific territory. The author specifically describes a platform in which domain specific concerns are facilitated by plugins, so I don't see why we are "automatically in domain-specific territory". One could easily envision classes of plugins for drawing nodes and edges (perhaps a canvas DSL), plugins for enforcing the domain's specific rules, etc.
This is not a new idea, people have tried it before. If there was a decent solution it would already exist. People have tried to make general purpose graph editors & tree GUIs & layout engines, and there have been a bunch of people that thought they were being smart by architecting it to accept plugins. There's a reason you've never heard of any of them; nothing was general purpose enough to stick around, and applications that didn't try to be "general purpose" have vastly superior UI/UX.
I spent several years building a tree editor (the animation sequencing project I mentioned earlier). I've also used well known tree editors in node-based gui apps for decades. (Check out programs for film & game production like Nuke, Maya & Houdini -- they are tree editors.) Simply put, there are not enough commonalities between applications in different domains to make it worth building a shared "general purpose" editor. The workflows, problems, and schemas are too distinct. The tree isn't even close to the hard part anyway.
Earlier quoted context omitted.
Don't forget org mode or mind mapping software. Both are quite able with hierarchical data.
Can you (or anyone) name some good mind mapping software (other than org mode)?
Trees are graphs with out cycles but you always end up adding cycles. Code is no exception. There have been endless attempts to create coding systems based on graphs. These systems promise extraordinary modularity and reusability and an ease of programming which will allow anyone to construct complex software with a few clicks and drags. So far everyone of these systems that I have seen in the last 25 years has falle…
How do you feel about tools like Reaktor, which I assure you works very well indeed?
Above I was referring to attempts to apply this idea to general programming. I'm not saying such systems are impossible just that it's a bad idea to assume it will make the programmer's life easier.
Earlier quoted context omitted.
> {{V,E}: V = {a,b,c,d,e}, E = {{a,b},{a,c},{b,d},{c,e}}} possibly accompanied by a statement as to whether edges are directed or not. From a math notation point of view, this statement is not needed. If your edges are directed, denote your edges not as sets (which are always unordered in math), but as ordered pairs instead: {{V,E}: V = {a,b,c,d,e}, E = {(a,b),(a,c),(b,d),(c,e)}}
Thanks. Or you can always use what I think is slightly informal notation, where a directed edge is notated as a -> b (I've seen that in textbooks, but I'm not sure where it's coming from).
(1) The notation a->b was defined as a simple shorthand, i.e. a->b := (a,b).
(2) The notation a->b was defined to be the graph consisting of just a, b and the edge, i.e. a->b := ({a,b}, {(a,b)}) ... this may be followed by some algebraic rules about how to combine small graphs to build larger graphs.
(3) The notation a->b may be a somewhat misused notation for functions, meaning the only possible function from set {a} to set {b}, i.e. the function that maps a to b. If you define a function to be a relation (i.e. a set of pairs) where the first elements are unique, then this is acually equal to {(a,b)}, i.e. the set containing exactly this one pair.
Interpretation (3) might look somewhat contrieved, but it actually isn't that much of a stretch, given the connections between graph theory and function structures through category theory.
Earlier quoted context omitted.
There's a core abstraction lurking behind tools like ZigZag, the Leo editor, hashtags, and C pointers/linked structures. The hyperlink as the base abstraction allowed us to store and navigate individual nodes in a hypertext, but it doesn't work well for collections - thus it provides limited support for programmatic access. Conversely, pointers & references in programming languages allow for easy handling/transformat…
> Conversely, pointers & references in programming languages allow for easy handling/transformation of large structures (either loops or recursive traversal), but there have never been a really good visual representation beyond a few nodes, and are difficult to navigate. Have you seen DDD (the Data Display Debugger) ? It's a graphical shell around gdb, and can help visualizing data structures.
It's been many years since I used it, so it may have evolved to include features for displaying large datasets; however what is needed is something akin to Bret Victor's "Learnable programming" principles, which is more powerful than simply tracing a single deterministic execution path (which is what classic "debugging" is).