Live data from Hacker News

Concord, our GPL outliner

scripting.com

51–60 of 63 posts

Re: Concord, our GPL outliner

#51
post #3

I didn't know what an outliner was: From the Git page: An outliner is a text editor that organizes information in a hierarchy, allowing users to control the level of detail and to reorganize according to structure. Your notes can have full detail, yet be organized so a casual reader can get a quick overview. Outlining is a great way for teams to organize work.

It's OK. OpenOffice/LibreOffice don't either and they just yell at people that notice MS Office's outliner functionality is missing in OOo.

Re: Concord, our GPL outliner

#52
post #3

I didn't know what an outliner was: From the Git page: An outliner is a text editor that organizes information in a hierarchy, allowing users to control the level of detail and to reorganize according to structure. Your notes can have full detail, yet be organized so a casual reader can get a quick overview. Outlining is a great way for teams to organize work.

Me either. That info really should have been in the announcement. I read through the whole thing and still had no real idea what Concord is.

Re: Concord, our GPL outliner

#53
post #47

Earlier quoted context omitted.

The GPL is not about being practical, it's about freedom. That's why it's the only licence I would consider releasing software under.

How does a license being confusing to the people that use it (and somewhat to the people that WROTE it) aid in promoting freedom?

The same reason it is hard to learn Emacs, but in the long run learning the tool is worth the startup cost a thousand times.

Re: Concord, our GPL outliner

#54
post #45

Earlier quoted context omitted.

What do you mean by an "order on the edges"? I'm only superficially familiar with graph theory.

In graph theory, one usually has a set of nodes (A, B, C, ...) and a set(!) of edges between the nodes, either directed ((A,B), (A,C), (B,A)) or undirected (in which edge (A,B) implies (B,A), (A,C) implies (C,A), etc.). Sets don't have an order; most graph theory doesn't distinguish between the set of directed edges ((A,B), (A,C), (B,A)) and ((A,C), (A,B), (B,A)). On the other hand, when dealing with trees (aka outli…

Right, an ordering relation on the edge objects. facepalm That should have been obvious, but I usually think about trees in terms of vectors of children, not traditional graph theory.

I like trees too. I think that as long as computer memory is linear, our serializations are going to be linear, so even when we get holographic displays, our primary abstractions should be linearly serializable (so we don't get lost in leaky abstractions), which means trees. A graph structure built on that would have to be some form of "magic" layered on top, based on links embedded in the tree. Among other possibilities, you can make the "edges" be little independent trees that link to the "nodes".

Re: Concord, our GPL outliner

#55
I've been browsing through the code a bit. It has a few problems.

First, the brace and indentation style is extremely unusual and hard to follow. I have never seen this style used in another curly-brace-language project anywhere.

I realize that brace and indentation is a very personal preference, but I've had no trouble following a variety of styles - until this one. Here's an example:

  if(c.op.inTextMode()){
      c.op.focusCursor();
      c.editor.restoreSelection();
      }else{
          c.pasteBinFocus();
          }
The if block and matching else block have different indentation levels? What? That does seem to be the pattern followed in a number of places.

How would you follow this style if there is a chain of else-if's? I don't see any examples in the code, but it seems it would have to look like this to be consistent:

  if(a){
      b();
      }else if(c){
          d();
          }else if(e){
              f();
              }else{
                  g();
                  }
OTOH, this function follows two different indentation styles for its two if/else blocks:

  this.callbacks = function(callbacks) {
      if(callbacks) {
          this.root.data("callbacks", callbacks);
          return callbacks;
      } else {
          if(this.root.data("callbacks")) {
              return this.root.data("callbacks");
              } else {
                  return {};
                  }
          }
      };
Try this quiz: Without loading the code into a brace-matching editor, just eyeball that function and see if you can tell which open brace matches with which close brace.

The function could be much simpler too:

  this.callbacks = function( callbacks ) {
      return callbacks ?
          this.root.data( "callbacks", callbacks ) :
          this.root.data( "callbacks" ) || {};
  };
Also in a half-dozen places or so, the code uses a for..in loop to iterate over an array. This type of loop should never be used with an array for two reasons: If any other code in the page extends Array.prototype the code will break, and the order of iteration is not guaranteed. These loops need to be converted to numeric for loops or $.each() or any similar alternative.

One last point that is just a matter of taste, but I think the code would benefit quite a bit if it followed the popular jQuery convention of using a $ prefix on variables that contain jQuery objects.

I love outliners, and I'd really like to contribute to this project, but the code is so strangely formatted that I'd have a really hard time with it. I wonder if the authors would consider adopting a more conventional coding style, or if they just like it the way it is?

Re: Concord, our GPL outliner

#56

I've been browsing through the code a bit. It has a few problems. First, the brace and indentation style is extremely unusual and hard to follow. I have never seen this style used in another curly-brace-language project anywhere. I realize that brace and indentation is a very personal preference, but I've had no trouble following a variety of styles - until this one. Here's an example: if(c.op.inTextMode()){ c.op.foc…

I think the programmer was just getting comfortable with coding in an outliner when he wrote that code. I would consider that indentation a bug, when and if I work in those areas, I'll fix the indentation there. Thanks for pointing it out.

Re: Concord, our GPL outliner

#57

I've been browsing through the code a bit. It has a few problems. First, the brace and indentation style is extremely unusual and hard to follow. I have never seen this style used in another curly-brace-language project anywhere. I realize that brace and indentation is a very personal preference, but I've had no trouble following a variety of styles - until this one. Here's an example: if(c.op.inTextMode()){ c.op.foc…

I think the programmer was just getting comfortable with coding in an outliner when he wrote that code. I would consider that indentation a bug, when and if I work in those areas, I'll fix the indentation there. Thanks for pointing it out.

Ah, thanks, Dave, and I'm sorry I went a bit overboard on my remarks about the code! The project does look promising; now I'm encouraged to check it out some more. :-)

Re: Concord, our GPL outliner

#58
post #36

Earlier quoted context omitted.

The GPL is not about being practical, it's about freedom. That's why it's the only licence I would consider releasing software under.

It's not about freedom, and I'm a bit sick of that Orwellian categorization (War is Peace, Freedom is Slavery, Ignorance is Strength). Unlike other open source licenses which outline your rights, the GPL is a document that is filled with taking rights away. It's also ridiculously complicated, to the point where no one is completely clear on what is or isn't allowed (and the LGPL is even worse). It's not practical and…

>the GPL is a document that is filled with taking rights away

It's a document that gives and preserves rights of the end user, which include the right to the source code and the right to modify and distribute.

How could it possibly 'take away' rights? Any rights not in the licence didn't exist in the first place and thus can't be 'taken away'.

A licence is a set of conditions which a code author/owner sets for using his/her code, any 'rights' you have to their code is that of the conditions they set.

If a developer chooses GPL for their code then those are the rights to which you can use their code, no rights have been 'taken away from you' at all, it's not your code.

And it's certainly practical, which I'm certain is the reason that it's the most used open source licence.

One particular aspect which makes it practical from a developer standpoint is that if they release their code under GPL they have the right to source code modifications made to their code as end users of such modifications.

There is no BEST licence, the licence profileration is a direct consequence of our different needs and values.

Re: Concord, our GPL outliner

#59

Earlier quoted context omitted.

I think the programmer was just getting comfortable with coding in an outliner when he wrote that code. I would consider that indentation a bug, when and if I work in those areas, I'll fix the indentation there. Thanks for pointing it out.

Ah, thanks, Dave, and I'm sorry I went a bit overboard on my remarks about the code! The project does look promising; now I'm encouraged to check it out some more. :-)

Not at all! :-)

I am a total bugger about formatting code.

The outliner approach is pretty good but not perfect.

If-then-else is the sore thumb, for sure.

Along with try-catch.

But overall, outliners are a huge win for writing code.

Let's be hardasses about this stuff, but also understanding.

I think your approach is perfect.

Re: Concord, our GPL outliner

#60

Earlier quoted context omitted.

IANAL, but the spirit seems to be "hey, here's this software, use it how you like, but if you distribute it (including building on it or bundling it in a product) please be kind enough to extend the same freedoms to those you give it to." Using Concord on your site? Offer a link to the source. Modify it to work better with a framework? Offer that modification too. Build an entire product off of it? Well, be prepared…

And most important, no gratuitous incompatibility or user lock-in based on formats. Commercial developers esp ones that raise huge money, tend to try to lock users in. If that's their plan, they can write their own outliner, should that situation ever arise.

Use of the GPL doesn't merely prevent commercial developers from creating non-compatible formats -- it prevents them from using Concord at all. Let's say I want to build a commercial app that happens to use Concord, and I'm happy to use Concord as is (contributing back any patches or improvements I make) and even make the outlines exportable (assume outlining is just one feature in a much larger app, not the main focus). In that case, I'd have to make much or possibly all of the client-side code GPL compatible, so I can't use Concord, even though I'm not violating your rule about compatibility and am contributing back to the Concord community.

GPL seems like overkill given your goal. It will be limited to a niche of either fully open source public applications or completely private/internal applications.

Post reply on HN