Comments for The Third Bit

Comment on Problems with Pandoc by Trevor King

Trevor King — Mon, 17 Jun 2013 01:25:43 +0000

If Markdown isn’t sufficiently expressive, I’d suggest reStructuredText. It’s more structured than Markdown, with cross-references, etc. all built in. It’s also easy to extend, so you can add a new directives for your “for instructors” section, etc., when the built-in capabilities fall short.

As a caveat, I haven’t written a ReST extension personally (yet), so maybe it’s not as easy as it seems. I’m also not sure how the table or “ markup works, so I dunno how hard it would be to extend them with new CSS classes or highlighting. Still, ReST solves two of your four problems (1 and 4), so it may be worth poking around a bit more.

Comment on Heroes by James Aylett

James Aylett — Mon, 10 Jun 2013 07:12:40 +0000

As good as that quote is, it’s almost certainly not Burke.

Comment on Merging is the Real Revolution by Sheila

Sheila — Thu, 09 May 2013 15:21:47 +0000

“When remixing is hard, open collaboration doesn’t take root”

This comment grips me, and I’d like to know if there are articles that can quantify it. It seems so obvious to me that I have trouble defending it.

This conversation happens when I tell people to make the process of starting development on their software a lot smoother in order to influence more people to participate in their projects.

This is not exactly related to your blog post, but I think the principle applies here.

Comment on If Anything, They Overestimate My Javascript by Julia

Julia — Thu, 09 May 2013 01:11:54 +0000

Funny. “It seems—from their activity streams—that Julia and swcarpentry are probably friends or at least virtual friends. With this in mind, it’s worth noting that swcarpentry has a less consistent weekly schedule.”

Comment on If Anything, They Overestimate My Javascript by Matt Doar

Matt Doar — Wed, 08 May 2013 22:38:43 +0000

Nicely written spin though: “Matt’s most active time is around 10am, I would conclude that Matt works best in the morning. It is important to note that an attempt has been made to show the daily schedule in the correct time zone but this procedure is imperfect at best.”

Comment on Merging is the Real Revolution by Matt Doar

Matt Doar — Fri, 03 May 2013 20:12:44 +0000

I wrote a blog “Life is Diff and Patch, Diff and Patch” (http://toolsmiths.blogspot.com/2011/10/life-is-diff-and-patch-diff-and-patch.html) with the note

“diff and patch seems to be a common theme of what I do for a living. But life is also diff and patch at some level – see what’s different between two people and merge those differences to another generation of people.”

Diff – what changed? (The organism evolved)
Patch – repeat the changes elsewhere (reproduction)
Merge – some one else made changes (sexual reproduction)

~Matt

Comment on Merging is the Real Revolution by Johannes

Johannes — Fri, 03 May 2013 14:48:01 +0000

In the whole article you don’t talk about “conflicts”. This is a bit strange because you make it sound as if there was a technical solution (merging) which could improve collaboration much.

In practice, the biggest and most important part of merging is solving conflicts. What even many software developers don’t understand is that merging and solving conflicts is a social problem. You have to get together (or at least anticipate the other one in mind) and find out what the other wanted to do to find a resolution. I would argue that collaboration to a big part is also about finding compromises and solving conflicts of some sort. A collaboration tool should always be designed with that in mind.

Comment on Merging is the Real Revolution by Trevor King

Trevor King — Thu, 02 May 2013 16:58:52 +0000

But I care about the picture as a whole, where the exact circle radius is rarely critical. The goal is enough library support so you can enter your design decisions directly (put a cannon on a low hill), and have the libraries handle the low-level details of fitting your design into the available space. SVG (and image formats in general), are usually designed to be easy to parse and render. You should be developing (and diffing and merging) in a language (or GUI interface to a format) that is designed to be easy to develop in (e.g. support for variables, functions, libraries, …). Then you can (communally) build the abstractions you need, or leverage the abstractions that someone else is providing.

On the other hand, I haven’t used either of the diffing tools you mention. Maybe they really are the bee’s knees.

Comment on Merging is the Real Revolution by Greg Wilson

Greg Wilson — Thu, 02 May 2013 14:38:16 +0000

As a counter-example, vector image formats (such as SVG) can be diffed semantically: not “these pixels have changed” or “these lines of the SVG file have changed”, but “this circle’s radius has increased from 1.5 to 1.7″. Maya and Houdini (two high-end animation tools) can similarly diff (but as far as I know not merge) two dataflows, and Photoshop has some good raster image diffing plugins.

Comment on Merging is the Real Revolution by Trevor King

Trevor King — Thu, 02 May 2013 14:31:03 +0000

I think my main gripe with WYSIWYG editing is that they usually lack good methods for coding abstractions. Whiteboarding with a mouse is quick and dirty, but if the computer only knows “draw a black dot here”, “make a dashed line there”, …, semantic merging will continue to be awkward. In order to *really* leverage the power of merging, you need to be able to write your slides using high level concepts (make a cannon firing a ball off a cliff) instead of low level primitives (draw a circle). This also means that when developer X improves his cannon-drawing library, everyone with cannons in their slides gets prettier pictures automatically. Writing semantic abstractions has to be about as easy as hacking up a one-off solution, otherwise few people will bother.

Whether abstraction libraries are coded in text or GUIs is just a technical detail, although if the technical problems are mostly solved for text and mostly unsolved for graphics, I think it makes sense to be biased in favor of text .