A while ago I added search through Swiftype to my tumblr. It’s really quite effective, especially considering your alternative is the funtionally useless default tumblr search. It has never worked for me on other people’s sites, and on my own, it returned no results when I searched for “the”.
Yeah, you should probably get Swiftype.File “site search” as something Tumblr doesn’t do for you. So sign up for a free account on Swiftype, grab the code representing the search bar, and look through the HTML for your theme for “search” and try to replace that with the Swiftype stuff.
Anyway, they recently sent out an e-mail with a bunch of new stuff they added. One of those things was support for a sitemap, which lists all the pages of your site and some metadata about them. So I looked into it a little and discovered that yourtumblrname.tumblr.com/sitemap.xml is automatically generated for you. sitemap-pages.xml lists the things you’ve added via Tumblr’s Pages, and sitemap1.xml lists all the posts you’ve ever made and the last time they were modified.
Next discovery I made was yourtumblrname.tumblr.com/robots.txt, which tells polite search engines where to find your sitemap and what parts of your domain to exclude. Wikipedia’s got a little page about it. If you go to that file, you’ll see that it asks web crawlers not to look at your private posts - they don’t have to do that, though. By sheer brute force they could easily discover all your private posts, as could anyone else willing to try the various random numbers inserted in the url of a private post.
The one issue I have with this stuff is that I don’t know how you could modify them. Still, it’s really nice to have this stuff done for you already. You’d never need to know this stuff exists, no matter how much you use Tumblr, and that’s a good choice on their part.
…and forgot to tell the internet about it
So yeah, I turned 20 more than two weeks ago. Wasn’t a huge spectacle, though an old friend from PEI happened to be visiting his aunt so we brought him along to dinner. We went to a new burger place near Dad’s, which was decent. I didn’t really want to throw a party or anything, but I still didn’t have time to sit down and write. I realize nobody was on the edge of their seats waiting for me to bore them with personal junk, but in case you were, that’s my excuse.
I feel like I should write about what happened during my 19th year, if only for posterity. Trouble is, there hasn’t been a whole lot of spectacle in my life lately. If anything, I’ve achieved a stratospheric level of mellow-ness. Still, a quick scroll down my archive has brought up a few interesting things to talk about. On an unrelated note, this is my four hundredth post. Holy crap.
Easy cop-out solution to recapping the last year: referencing previous recaps! The last five posts of my 2011 recap happened after my birthday, so that counts. I assume 2011 in review gives a good idea of what the 2011 part of being 19 was like. I distinctly remember being very morose on New Year’s Eve, though, so that played a part in the tone of the review post. Not the recap post, mind you. Sorry about that, it’s confusing in retrospect.
Anyway, onto more substantial discussion. I wrote during winter break about some goals for 2012, but had a hard time coming up with anything significant. I said I’d like to be consistently happy, but lamented my choice of solitary hobbies. I also said (hang on, have to re-read the sentence five times…) that “I might be miserable because I don’t have any close friends in Ottawa”, or something along those lines. “Might also be good if I were to talk to people, or spend time with them”. Hilariously enough, I resolved all those things… without… really… meaning to. Now, this might be obvious to you, but hanging out with people who share your hobbies turns out to be a two birds, one stone sort of deal. Watching anime, playing games, and reading may be primarily silent activities I do on my own - but it’s just as nice to be alone together, i.e. doing so with someone else engaged in their own game/book. Having hobbies in common also netted me a friend who is close physically as well as emotionally, and it’s nice to have that again.
I’m also getting pretty good at gathering a group of people and hosting a relatively low-key nerdfest event at home. This allows me to safely avoid individual invitations while still gradually getting to know people. Next step should probably be expanding on the set of people I can comfortably invite to hang out individually. Which isn’t to say that I prefer quantity over quality, but generally you deal with a quantity of quality larger than one. One person is significantly better than an empty set, but it just seems like I’d benefit if I wasn’t so damn scared to say “hey we should hang out and bond over *insert shared hobby*”.
Related to that is my post about decreasing my misery quotient, which still seems like it’s going to be a valid strategy. But aside from that, I am much more consistently pleased with life than I used to be. As it turns out, computers and video games provide a lot less emotional support (active and passive) than real, live humans. Hooray for nice people!
I posted near the end of the school year about some goals I had for 2012 and where I was at in life. That was pretty good, and I think it’s still pretty relevant to where I am now. Regarding my second goal, I’ve been reading (thus, learning) voraciously - I cleared out almost all of my list on Read It Later (now Pocket, but the new name doesn’t give you any idea of what the service is about). And then I filled it up again. At any rate, I’m starting to put stars on things I really like and delete things that were lame, so there should be a higher signal/noise ratio in my archive. As for books, you can see what I’ve read over on GoodReads, which I like more and more as time goes on. It’s funny when I recognize names of reviewers on programming books from StackOverflow and parts of the Emacs community. All in all, I think I’ve learned a lot of good stuff over the summer.
Something I never wrote about was that my roommate is no longer staying with us. Or speaking to me, for that matter. It’s unfortunate, but life goes on. I wish her the best, truly. Don’t be concerned by how little I’m talking about this seemingly significant event; it’s not really fit for public consumption. I’m older (lol 20 isn’t old) and wiser and have a better idea of what I should/shouldn’t post publicly. This is one of the things I shouldn’t write about.
There’s one small benefit of the above, though - I’ve got my own bedroom back at mom’s. Which is kind of nice, because living in the basement sucked in subtle ways. Meanwhile, I’m getting an awesome place in the basement at my dad’s. It’s still under construction, but I expect it will be nice to have when it’s done.
Anyway, things are winding down for my work at HotSoft. My project didn’t yield a lot of fruit this summer, but we’re on hold for a week or two to await some information about some of the software we depend on. If the information doesn’t show up, we may plot a fairly different course from here. We’re having a picnic tomorrow and I’m bringing delicious cake. So that will be nice!
Classes start a week from today, so between now and then I’ve got a couple hundred bucks to drop on textbooks and some time to spend on my own stuff. Not sure yet what I’ll focus on, but I’ve been getting Emacs set up for Python programming lately. Spent hours looking into it and I’m still not done, because there’s literally three solutions to every problem. Sigh.
Oh, right, I ordered a new laptop! I’ll post more details when it arrives, which should be soon. It’ll be a good opportunity for me to sit down and get digitally organized. This post is mostly about life, though, so I’ll save the tech for another post.
A few years ago, I came across a game on Steam called Winter Voices. It was an episodic RPG for PC by a small French developer, but they only released Episodes 0-4 (with 5 and 6 unreleased) before going bankrupt late last year. Because the company dissolved, the game has been removed from Steam and most honest digital distribution platforms. I don’t know what the game’s sales were like, but it didn’t get very much press and most people couldn’t recommend the game wholeheartedly. The rough state of the game at launch and bittersweet press response probably hurt the game a lot. But for the people who played it, Winter Voices provided a unique experience that truly deserved more exposure than it received.
The game stars a young woman whose father has just died. She has returned to the small northern village where she grew up in order to attend his funeral, with the implication that she had gone off to make the most of her life elsewhere. Winter Voices begins when she arrives - correction: when you arrive - at the village a few hours before the funeral. [correction: I e-mailed this post to the game’s author, and the heroine did *not* leave the village - that was a miscommunication with the people who made the game’s intro video] You choose a variety of stats relating to your character’s personality, like humour and memory, and set off to talk to people and wander around the village.
Whenever you run into nostalgic or otherwise emotional situations, you enter grid-based battle arenas where you struggle against shadows representing grief, painful memories, and other psychological trauma. However, there’s no “combat” as such - you can’t defeat grief by brute force. All you can do is try to withstand it. Most battles have goals like “get to the other side of the map” or “survive for 5 turns”. It’s a great metaphor, and Winter Voices may be the only game to imbue these common battle mechanics with actual meaning.
It gets even more interesting when you see the game’s skill tree. Here’s an image of your initial skill choices, courtesy of Rock, Paper, Shotgun:
The skill in the very center is Repulsion, which lets you push enemies a very short distance away. Generally, they can move much farther than you can push them, so it’s a fairly ineffectual defense - but initially it’s all your character is capable of mustering. As you gain experience from dealing with your emotions and talking to others, you can gain new skills that are connected to the ones you’ve already learned (in the above image, the highlighted circles are skills that player is able to pick). To quote the description from RPS:
You start at the centre, and each direction represents a different way of dealing with grief. See the yellow-looking skills towards the bottom right? They relate to regressing into your own imagination. The orange skills above those are all to do with being sociable, and the power of friends. An example of a skill that lies between both of those areas is Imaginary Friend, which summons an ally that will hold enemies back.
The skill tree is another beautiful metaphor, and I think it makes for an awesomely individual experience for each player. Instinctively, you might think that everyone will experience the same “story” when playing Winter Voices - the one the game’s writers came up with, focused a woman dealing with the death of her father. However, the important story in Winter Voices - what I think of as its “narrative” - is the one enabled by the gameplay mechanics. Everything that you do in a game contributes to its narrative, and most designers and writers ignore this at their peril. Almost every game in the strategy/RPG genre relies on generic player statistics like strength, agility, etc. and skills that focus on faster or more exciting ways to kill things. This makes it very difficult for them to have a narrative that doesn’t involve faster and more exciting ways of killing stuff, because that’s the main form of conflict resolution. Then the writers are forced to craft a story with a lot of combat opportunities, stifling a huge swath of meaningful stories and narratives.
Rather than following the combat-focused trend, Winter Voices makes a metaphorical narrative out of your choice of which skills and stats to invest in. Every player builds their own, personal narrative about who the main character is and how she learns to cope with (and hopefully overcome) her emotional anguish. It’s possible to play Winter Voices without thinking about the story behind your gameplay choices - your narrative - but I expect that few players would. It’s just more fun to construct a story to make sense of the choices the game has provided for you, and that’s what makes Winter Voices so amazing. The sheer size of the game’s skill tree (you can only see a fraction of it above) also contributes to this phenomenon, because there are a lot of valid ways to play the game. Since they’re all equally efficient, the player will probably wind up making some personal choice in how they decide to play. Metaphorically speaking, each potential set of choices represents a different coping strategy.
This sort of narrative complexity, which is generated by a mechanical system, fits poorly in other mediums. There are twelve mechanically (what they do for you) and narratively (what they say about your character) distinct skills you can choose when you gain your first skill point, and the number of possible paths only expands from there. That level of choice enables a wide variety of narratives, and it would be difficult to provide all of them in a single traditional novel or film. Moreover, the systems in Winter Voices provide an environment in which to make interesting choices. The skill tree in particular provides a handful of meaningful choices, each time you level up, about how your character deals with her emotional problems.
On the other hand, it also provides constraints that make each choice more meaningful. If you could have every skill in the game at once, your choice of skills doesn’t really matter in the long run to the narrative. If you could have ten arbitrary skills from the entire set, the choice would have less narrative meaning - there would be less logical progression in the way that your character solves her problems. The end result is that your character builds on basic, foundational skills to learn more advanced and more effective abilities, which have a logical grounding in what she chose to learn in the past. The choices and constraints in Winter Voices enable a wide variety of possible narratives, and that’s what makes it so fascinating. To me, that’s the essence of video games.
Having played Winter Voices when it was on Steam, I think it provides a valuable experience. If you spend an hour or two playing Winter Voices, you’ll experience a powerful argument for video games being art. The sort of argument you just can’t convey by letting people look at (but not touch!) games in a museum. It’s not a game for everyone, but you can get the game’s prologue for a few dollars, and I guarantee it’s worth at least that much money and a few hours of your time.
There’s roughly three reasons why I wrote this post: one, the game is set to be re-released soon with a plethora of improvements from when Rock, Paper, Shotgun played the game. Two, I was disappointed by the Smithsonian exhibit linked above and I wanted to provide a compelling argument for why games are art. And finally, Extra Credits just released a compelling two-part series about game mechanics as metaphors.
Regarding the first point: Some members of the original development team reformed under a new name, bought the IP back from the French government, and are currently running a beta test of a huuuuuuuuuuugely improved version of the game through Steam. If you’d like to try it out after reading this post, you can send them an e-mail at betatest@innerseas.com with the subject “Winter Voices EP5 - Beta Test”, with at least your Steam user name in it (maybe with some info about your computer’s hardware and such, too).
It sounds like they’re looking for people to test the game from start to finish right now because of a big engine update a few days ago, so they’d probably be happy to have your help. Otherwise, they’re hoping to have the game back on Steam in a couple of weeks. So even if you don’t get into the beta test, please do give the game a shot - with the improvements they’ve listed in the Steam forums, I expect I’ll be able to recommend the game without any reservations now.
[Thanks to Vael Victus, M-. and Sarah for reviewing and helping me edit. Also, if your viewing experience sucked, you’re probably using the Tumblr dashboard - blame their elimination of a lot of basic HTML stuff.]
While I was researching a post I’m working on (you’ll see it soon, I’m really proud of it), I took a bit of time to look into interactive fiction. This led me to a Stack Overflow question with a lot of good answers about IF tools/systems, and I realized once again how cool Inform 7 is. I’ve also been listening to episodes of a Destructoid podcast called “Sup, Holmes?” (itunes, feed with mp3s), and in a number of episodes (episodes 15-18) he has interviewed people from the Toronto indie game community. They all spoke of things they had worked on at various game jams in Toronto, and I thought that sounded pretty cool. A game jam is just a bunch of people gathering (often physically, but sometimes digitally) and working on a game for a set period of time. At the end, you have a thing that probably sucks but gosh darn it you made it and you’re going to be proud of it!
Light bulb: why not combine the two?
So here’s what I’m proposing:
This is meant to be difficult, because to the best of my knowledge I don’t know anyone who writes interactive fiction. The random theme aspect is designed to make it that much more challenging. What you produce doesn’t have to be awesome; it will probably be more fun to create than to play. At any rate, it’s just meant to be a fun event for us to hang out and do something interesting. I literally have no experience with this, and haven’t written creatively in a while, so I expect this to be really difficult. But you’re up for it, because you’re awesome!
I’m going to be continually adding resources that seem useful here, if you want to do a bit of research. Just try not to show us all up by reading everything like some kind of genius, alright?
For a practical introduction to Inform 7, check out this screencast by Aaron Reed. I’d forgotten about this video, actually; this was the first thing I ever saw about Inform 7 and it’s really quite impressive. He paints the system in a more prose-based light than some of the other more programming focused resources below. So at a bare minimum, give that a watch and then grab things below that seem useful.
One programming-language-y thing that I expect to be quite useful is rulebooks. I expect he’s right that using rulebooks as much as possible is a good idea, so do give that post a look and consider making use of them. Thinking about it a little, rulebooks are kind of like quirky interfaces - you have some behaviour that you want a bunch of things to share, so you put it in a single place and have them “consult” with the rulebook on what to do. Depending on the approach you take, this will either be incredibly useful or utterly irrelevant.
For in-depth tutorials on Inform 7, there’s a section on their site. The Recipe Book seems particularly useful.
For those of us with the background, Inform 7 for Programmers is long but informative. I actually find it to terse to a fault in some ways; it’s not very good as reference material to flip through.
If you’d like to see some source code as an example, check out the bottom half of this page which implements Cloak of Darkness, which seems to be an IF “hello, world” sort of story.
One of the StackOverflow answers recommended the section on design from the old Inform Designers Manual, Fourth Edition (DM4). So I’ve extracted that into its own PDF, which I’ve uploaded here.
Inform has an extensive library of extensions (shut up I am normally better at writing than that), which you can check out here - once you’ve got an idea of what you’re going to do, you might want to look around in there.
If you’d like to write a fight-y sort of game, you can check out an extension for Inform called ATTACK.
He also has a series of posts about designing a text-based dungeon crawler in Inform 7, if that’s your jam: pt 1, pt 2, pt 3, pt 4
If you run into anything interesting that I haven’t directly linked to, please do send it around to the rest of us. We’ll probably all be doing wildly different things, but you might inspire someone to change direction with whatever wonderful extension/blog post/whatever you’ve found.
I’ve been watching Chris Granger’s Light Table project for a few months now (apparently, since April) and the more I think about it, the more I like it. According to their Kickstarter, the rough estimate for release is May 2013. When it comes out, it’s supposed to support Clojure (a Lisp dialect that initially ran on the JVM but has a variety of ports), JavaScript, and Python - all dynamic languages with powerful tools for instantly providing feedback. The link in the title of this post will get you to the version 0.1 demo, which currently only supports Clojure.
Even though I like Emacs and have no trouble using a command line tool like Leiningen (aka lein), I see a lot of things to like about Light Table. I like the fact that lein is now built-in, and you can get started with a project right away. The Instarepl is fun to play around with, and it’s something that would be difficult for a purely text based editing environment. With the addition of the Table in the latest version is, things have gotten a lot more interesting. What they’ve done is emphasize the structure of functional programming through the structure of the IDE - you work with a bunch of discrete, self-contained units and gradually combine them into a unified organism (to take some inspiration from the preface to Structure and Interpretation of Computer Programs).
Working in a buffer of code, if you find that you need to re-arrange some units, it’s a lot of work. Light Table presents these units as being completely distinct from each other, making it easy to navigate between them and move them around. I assume the final product will make it easy to travel between the different views of your code - I’d love to shuttle a bit of code between the Table for editing and the Instarepl for testing, for example, but at the moment that doesn’t seem to be possible. The constant documentation lookup presented in the Kickstarter pitch+video is nice, as well, and I think it would prove to be more useful than having a hotkey to go looking for a bit of documentation.
The moral of the story, though, is that these are the kind of things you put together when you look at the logical structure of code. Extending Light Table in JavaScript, as demoed by Chris, actually winds up leading to more impressive extensions than most of what you see for Emacs. Emacs has tons of awesome extensions like Org mode; but your power starts and ends with text processing. You can make nice tables in Org mode - I’ll happily concede that you could write a similar benchmarking mode that outputs an Org file. That’s pretty simple in plain text.
What about displaying the contents of a database on the fly? It seems to me that Emacs isn’t so great at displaying constantly changing data like that (ie as you change the code in the associated buffer), but I could be wrong. But until someone completely revamps the rendering engine in Emacs (which could be a long time coming) you just can’t embed a webpage in Emacs. Full stop. No, viewing it in plain text with w3m doesn’t count. No, converting the webpage to a pdf and displaying that doesn’t count (yes, Emacs can do that). I mean honest-to-goodness embedding the webpage, such that you can interact with it and see it true to life, including its JavaScript and other stuff that probably stumps text-based browsers like w3m.
This isn’t just an abstract problem - displaying text with heavy formatting is basically impossible in Emacs. I’ve been looking at using Emacs to write LaTeX for papers, and the workflow is pretty crappy. You write your LaTeX document, you compile it and output a pdf, then you display the pdf in Emacs or in a standard pdf viewing program (on Windows, SumatraPDF is a good choice because it won’t lock the pdf file while you’re viewing it). Compare that to Gliimpse - personally, I’d like a version with instant transitions, but that’s just me. With or without transitions, it’s the same idea. You write your markup, you take a second to see what it looks like, you switch back to the markup to make some changes. Tada!
Contrast that with the current workflow - you write the markup, compile the new version, open the pdf, check out your changes, make some adjustments, recompile, re-open/refresh the pdf… A dual-pane environment for writing Markdown is actually available online, but I’m having a hard time finding anything similar for LaTeX. If Emacs had a rendering engine capable of displaying LaTeX documents accurately, it would provide leverage for a plethora of useful tools, stuff above and beyond the demos Chris put together.
Until then, we have Light Table.
If you don’t use Emacs, you can safely skip this post. If you’re curious, checking out my files is probably a bad place to start; I’ll make a post sometime about all the “starter kits” I’ve discovered and pilfered ideas from.
I don’t know if I have anything super awesome in my configuration (yet) that actual Emacs users would want to check out, but hey, here’s what I’ve got. You’ll notice there’s an insane amount of comments in there. By my last count, the file “old .emacs” contained 1207 lines. Without comments, it only had 239 lines of code. The main benefit is that it’s really, really easy to read through (for me, anyway). I can go a couple months without looking at the files and still understand why a certain snippet is there. I’ve linked to the source for a lot of things (80 character line limit be damned), too. I’ve got sort of a hierarchy going on with the number of semi-colons in a given comment line - five for the introduction of a section, three for the introduction of a paragraph explaining something, and one for each line thereafter.
Oh, and 80 semi-colons surrounding every conceptual section. They’re kind of hard to miss.
Something that may be new to you: I learned about electric-buffer-list yesterday, which I don’t think anyone ever uses, but it’s enough of a marginal improvement over the default buffer-list command that I mapped it to C-x C-b. And, hey, it supports the same buffer highlighting as the original buffer-menu (you only have to modify a single line). But of course, this being Emacs, you also have the option of BufferMenuPlus, if you like.
It’s not meticulously organized just yet… There’s mostly no rhyme or reason to the ordering of a given file. I’m planning a big revamp johnw’s use-package soon, and just generally getting things organized in a clear way. I haven’t actually used org-mode yet, but I’m starting to itch for hyperlinks within/between my files - I may very well take advantage of org-babel and base a new version off of it. I could even have a table of contents for a given file, which would be nice for other people who you don’t know what to search for.
Hyperlinks in a text file. Yay, Emacs!
I recently added Disqus comments to my Tumblr, so that anyone can make quick comments on my posts without having to formally reblog the post. Or otherwise use Tumblr at all. This further illustrated the main problem with my tumblr: it totally sucks if you aren’t reading my posts through your dashboard. Well, the RSS feed might be good. But anyway, people visiting for the first time didn’t have a great experience. It didn’t look good, it was a pain to change things, and so on. I was always apologizing whenever I linked someone to it.
It was using a pretty lame default theme that was available when I first started this whole thing more than two years ago. When I was trying to add Disqus comments, had to futz around in the HTML in order to add the comments section, and even then, it looked weird. But the guide I had bookmarked on getting Disqus on tumblr, aside from highlighting some useful stuff like Akismet, also mentioned that “modern” themes have built-in support for Disqus.
In other words, it was time to move on.
I eventually settled on the theme Effector, which looks relatively nice and has support for a huge amount of stuff. It has a checkbox for infinite scrolling, which I had previously enabled with some JavaScript I found online. It has Disqus support, obviously. It has a nice little section where it links to various social networks. It has a floating bar thing for my title and search box and stuff. All in all, it’s a huge improvement. The one thing I don’t really like is the flat colouring used in music posts, but I think what I have now is kind of ok.
Stuff I changed:
I’ve got a few things I’d still like to take care of, though:
Anyway, there’s a bunch of stuff you can fiddle with if you haven’t visited the actual web page in a while. Or add to your own tumblr, if you like. Or any website, I assume, if that’s how you roll. Swiftype’s indexing and searching is really quite nice, and it’s free if you’re not sucking up their bandwidth. And automatic syntax highlighting is pretty rad if you’re going to post code snippets. So yeah, if you like the sounds of that, go check them out and I’ll be happy and stuff.
edit, five minutes later: I uploaded the required JavaScript file and the Monokai theme for highlight.js, but unfortunately it looks quite ugly. Turns out none of the themes with dark backgrounds look good on my current theme. So I’ve gone with the Arta theme because it kind of fits with the rest of my current colour scheme. You can see it all in action at this unlisted page, if you’re curious. It was pretty easy to install, actually, though I have no idea if it might have averse effects on page loading…
Over the last few months, I’ve been learning a lot about a text editor called Emacs. I haven’t started using it full-time, yet, but I’ve already spent dozens of hours researching it. The reason that so much information even exists is that Emacs can be easily extended to do things far outside the domain of a simple “text editor”. This is done using a programming language called Emacs Lisp (one of many dialects of Lisp). The essay I’ve linked above, The Lisp Curse, proposes the following hypothesis: “Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp.” Since Emacs is written in a dialect of Lisp, naturally it seems like it would fall prey to this problem.
I can’t really evaluate the essay as to how it treats Lisp historically. But what strikes me about it, as someone who (currently) isn’t fluent in Lisp, is how much it reflects what I’ve seen in Emacs. The EmacsWiki is nothing if not a historical archive of many years of Emacs development. If you go to the page for some high-level problem, like session management, you’ll usually have at least three competing solutions. The trouble is that many of these solutions haven’t been touched for years, and may even be broken in modern Emacs. A different solution (which may not be perfect) may have been added to the standard distribution in a recent version, making extra code unnecessary (electric-pairs comes to mind for auto-inserting pairs of characters like [] and ()). This has been the case for the history of Emacs pre-2011 or so - let’s call this the “Dark Age of Emacs”. It seems to me that projects from the Dark Age of Emacs suffer from The Lisp Curse. From the essay:
“Programs written by individual hackers tend to follow the scratch-an-itch model. These programs will solve the problem that the hacker, himself, is having without necessarily handling related parts of the problem which would make the program more useful to others. Furthermore, the program is sure to work on that lone hacker’s own setup, but may not be portable to other Scheme implementations or to the same Scheme implementation on other platforms. Documentation may be lacking. Being essentially a project done in the hacker’s copious free time, the program is liable to suffer should real-life responsibilities intrude on the hacker. As Olin Shivers noted, this means that these one-man-band projects tend to solve eighty-percent of the problem.”
I ran into this problem pretty early into my Emacs career. Session management was one of the first things I wanted to figure out when I started with Emacs. My goal was to keep a small text file open on the side at all times, containing a list of shortcuts and tricks I should remember. Imagine my frustration when none of the solutions I tried actually worked! Or at least, none were simple to set up for a complete beginner. Right now I use revive.el, which functions for the most part, but I’m not entirely happy with it. I could probably get it working if I understood it better, but at the moment its particular 80% solution works for me.
Code from the Dark Age of Emacs is kept in blog posts, hosted on EmacsWiki, stuck in some obscure directory on university domains, lost to the ether that is personal websites with expired hosting… Tracking down updated versions is nigh impossible, because they’re often created by new authors taking care of an abandoned project. Small projects get “forked” or maintained by someone new without the benefits of the trail of crumbs left by forking on GitHub. I once ran into a project that was three times removed from its original author, with every successive version being hosted on a different personal website. The only reason I found the “newest” version of the project was a few stray comments on a long EmacsWiki page, full of hacks and monkey-patching that stopped being relevant years ago. See the EmacsWiki page on smooth scrolling for an example of this - odds are that none of those fixes will work for you. I’m surprised even two comments on that page have version numbers to serve as a lame time stamp…
It’s been a long time coming, but the Enlightenment of Emacs has begun in earnest, thanks to the power of the internet and proper tools. GitHub makes it incredibly easy for developers to collaborate on large projects, or for users to report bugs and have them fixed quickly. The Emacs Lisp Package Archive, and especially the inclusion of package.el in Emacs 24, have made installing and distributing extensions as easy as it should be. The MELPA repository combines the power of the two by supporting packages stored on GitHub, without requiring the author to upload their package to a special repository or give ownership their code to someone else. Unlike, say, downloading revive.el, trying a new package doesn’t mean downloading some files off of a Japanese server. While bad documentation mostly plagues code actually hosted on EmacsWiki, GitHub encourages everyone to have a bare minimum of non-technical documentation (do this to start using it, here are some things you might want to tweak). Collaboration on a single perfect solution is easier than ever before, and life is pretty good for both developers and users.
Here’s a somewhat abstract problem, solved with flying colours by collaboration: when programming, you often want to select some chunk of code and do something with it. Usually, this is a “semantic” chunk - in prose, imagine selecting a word vs a sentence vs a paragraph. You can see a video of this in action here, and see for yourself how awesome this actually is. I can’t track them down any more, but I saw at least one “80%” solution to the same problem by Xah Lee, and another somewhere else. This is the Dark Age of Emacs at work - nobody knew what anyone else had developed.
Magnar Sveen’s expand-region.el is, as far as I can tell, a nearly perfect implementation of selecting semantic units. Better yet, it’s not limited by his imagination. If you scroll down, you’ll see that there are at least eight other contributors to expand-region. If you scroll up, you’ll see there are many specialized X-mode-expansions.el files. If your language of choice isn’t supported, contribute! And now there’s a definitive solution to this problem.
I don’t know, first-hand, how things stand for Lisps other than Emacs Lisp. Or whether this is going to be true for new dialects of Lisp going forward, thanks to new tools. From reading people’s reactions to the essay on HackerNews (in two different threads!) and Reddit, it seems like the problem is real… depending on who you ask. The fact that it’s so easy to solve problems, everyone does it their own way had at least one piece of anecdotal evidence in its favour. Lots of people disagreed, obviously.
Points in favour of thinking this may not be true going forward: a lot of people threw in a vote for Clojure, a newer Lisp dialect that runs on the JVM (which has definite overlap with the Emacs community). I’ve seen some pretty cool tools (lieningen, Light Table - no surprise that the two work together) and libraries (Noir for web development, Overtone for making music) for Clojure, and they’re all hosted on GitHub. Perhaps programmers finally have the social tools we need to avoid not invented here syndrome and the other composite parts of the Lisp Curse!