I'm aware of this plugin. That's exactly what I'm talking about. People obviously put lots of thought, effort and care into it. If it was invested in modifying notebooks, I argue, the results wouldn't be less impressive.

The only difference between notebooks and traditional editors is the latter being strings-oriented; the former being trees-oriented.

So, what exactly can a traditional IDE (or a command line, for that matter) do that notebook can't? :-)

> I can't imagine how we could have managed

> without using plain text files and version control

I haven't yet collaborated, that's important, of course. Still, I have plain text files that can be version controlled, and this doesn't seem to have anything to do with interface. I never edit them directly. Programs' text and metadata (comments, preamble, datestamp, sections markup) are all compiled into package files from notebooks. Git will diff as it does usually, so your colleague doesn't have to use tree-oriented editors. There's even a default feature like that in FrontEnd but the functionality is very basic and it's not meant to be extendable.

I don't collaborate, so I don't have a package to notebook converter but there's nothing conceptually difficult about it. You import someone's changes to a local notebook (or to a newly created copy of it): your drafts, experiments, test results and overall interactive canvas all stay, only definitions become modified. Drafts and experiments from collaborators' notebooks could be merged, as well. Notebooks don't have to be a part of version control at all.

Again, it's not conceptually difficult to write a version control aimed not at strings but at cells, or maybe cells with datestamps. If I want to merge notebooks I'll have to implement that. — An ad hoc merger I've written right now is merely 4loc, though.

The question at its lowest level is very simple: what is a better medium to organise data (and code — which is the same, in our case), strings or trees?