As you will very probably have already seen, The Open Logic Project (a team of serious and good people) has now made available an early public version of an open-source collaborative logic text, somewhat ploddingly called the Open Logic Text.
There are two things to comment on here (eventually!), namely the Text itself — or at any rate, the current snapshot of an evolving text — and the open-source nature of the enterprise.
At a first quick glance, the Text does look rather uneven: there are 77 pages on first-order logic and beyond (some at quite an elementary level), 100 pages on computability, incompleteness, etc. (this looks like a solid graduate course), and then just 21 pages on sets (at a very much lower level of sophistication). Still, this is obviously exactly the sort of thing that should be covered in the Teach Yourself Logic Study Guide. So when I’ve had a chance to take a serious look, I’ll report back with my two pennies’ worth, maybe in a mid-year update to the Guide.
You can download the current version as a PDF. But as the Project site says of the Text,
… you can download the LaTeX code. It is open: you’re free to change it whichever way you like, and share your changes. It is collaborative: a team of people is working on it, using the GitHub platform, and we welcome contributions and feedback.
I will be really interested to see how this pans out in practice. Using GitHub is a notch or three above my current nerdiness grade. But I simply don’t know if this is me just not keeping up with everyone — or whether it is pretty typical for logicians to know a smidgeon of very basic LaTeX, with that being about their geek limit. Maybe, at least as a bit of exercise to keep the brain from entirely rusting up, I should take a look at this GitHub malarky about which I’ve heard tell before (any useful pointers to an idiot’s guide?). Then I could also report back about how the collaborative aspect looks to a complete beginner. Again, watch this space.
I would actually recommend learning a revision control system (such as Git) for your own work.
Apart from perhaps a few Mozarts of textual composition from whose fingertips whole texts flow effortlessly and error-freely, everyone who’s written anything of any size has been in the position of making substantial changes, then realising that the old version was better, or at least some of it was, but you’ve deleted it all and it’s too late now.
Many people manage this risk (after the first time it happens, perhaps) by keeping different versions of their document around, perhaps with numbered suffixes, so they can go back.
But this is just being your own revision control system, and it’s easier and better (once you know what you’re doing) to let a computer program do it for you.
While on any reasonable measure I’m a pretty complete nerd, for the most part I don’t use revision control systems in a particularly sophisticated fashion: 95% of the time I just commit every time I’ve done something significant, and 4% of the time I go back in time to see what’s happened in the past, either because I need something from the past, or because I’m curious.
That’s enough to get serious value, and it only requires knowing one command for the committing, and maybe a small handful for going backwards.
One of them newfangled GUIs (including web interfaces) makes it even easier.
The other 1% of the time is something more sophisticated like branching, but you really don’t need to know that to get some serious value out of this for personal use.
(I think this sort of thing is creeping into ‘consumer’ software, like Apple’s Time Machine or whatever it is. Maybe Word does something like this these days? Someone feel free to school me about this. But if you’re using LaTeX, Word features probably do you no good, and some OS-level thing is, I imagine, unlikely to be as useful, as it won’t know what revisions are significant and won’t keep notes on them.)
I’ve seen that sort of argument quite often over the years, and although I can see the value of a revision control system for collaborative work when more than one person will be making changes, especially when dozens or hundreds of files are involved, I’ve always found such systems more trouble than they’re worth when I’m doing something by myself. The GUIs and web interfaces make the problem worse, from my point of view, because there’s more to learn and they can be quite complicated in themselves.
I think this is largely down to individual temperament, with the result that some people like revision control systems, and some (like me) find them a tedious and unpleasant complication. One reason I think this is that I saw revision control systems being recommended for one’s own work even back when the options were as poor as SCCS and RCS. (Git seems a huge improvement over systems like those.)
I suppose an alternative to Git for LaTeX users just working on their own is to comment out everything they think they want to delete, then they can uncomment it if they change their minds. I do this a bit, but I can see that it could get quite messy if you did it a lot, or made large-scale changes.
I’d just keep a copy of the old version if I were making large-scale changes.
I wouldn’t use commenting-out unless I thought there was a good chance I’d want to bring that text back or unless it was useful in or as a comment.
I keep a file of notes that describe significant changes, and I include in the notes any deleted text that I might want to reuse.
I guess, like Rowsety Moid I’m yet to be convinced about getting into something like GitHub for my own, uncollaborative, work. Everything is on DropBox, which keeps the last thirty days’s worth of versions. Then TimeMachine can take me back a couple of years. That’s enough accessibility to past versions for disaster avoidance! (OK, that doesn’t generate any log of what exactly I’ve changed when: but I’ve never really felt the need for that.) So what are we missing?
Dear Dr Smith,
I can recommend some of the official GitHub tutorials on Git, which can be found here, and here. I am sure you will like Git and GitHub — just imagine people sending you corrections and additions to your various guides and notes as patches which you can easily apply in one click.
They have just put up a blogpost (the day after you posted this, Peter), Git for philosophers, part 1:
http://openlogicproject.org/2015/05/11/git-for-philosophers-pt-1/
The name suggests, but it does not prove, that more parts will appear (we are still waiting for Gödel’s Über formal unentscheidbare Sätze II).
I also wonder how Git for philosophers differs from Git for anyone else. It puts me in mind of book titles like “The Internet for Seniors”.
Whoops, I have just noticed that “they” is Richard Zach, who promised us a guide (in this comments thread) and then supplied part I the very same day! My apologies, Richard.
The step-by-step guide is on top of the pile of things to do!
PS: You don’t need git, you can download a ZIP file too.
I’m reminded of the HoTT book (http://homotopytypetheory.org/book/), which seems to recommend https://try.github.io/levels/1/challenges/1 as a resource for learning Git and GitHub.