This is a file I keep open in emacs for taking down quick notes. Some of the notes might become more polished, but by thinking of them as quick notes, I can use this one weird Žižek trick:
It's psychologically impossible for me to sit down [and write]... So I trick myself. I put down ideas, in a relatively sophisticated form, a line of thought, full sentences and so on. So up to a certain point, I'm telling myself, "no, I'm not yet writing, I'm just putting down ideas." Then at a certain point, I tell myself, "everything is already there – I just have to edit it." So that's it – I split it into two: I put down notes, I edit it. "Writing" disappears.
These notes are written in Markdown, and then automatically converted on save using a .convert-markdown script. This script also notes the changes in a local git repo, and pushes a delta of the changes to the server using rsync:
git add -A &> /dev/null
git commit -m $(date -u +%Y-%m-%dT%H:%M:%SZ) &> /dev/null
rsync -az $OUT server:/path/$OUT
I was going to use Octavo and Orinoco for this, but I realised that I wanted just a single page of notes. Maintaining the connections between files is sort of a nuisance. Consider using a multiple page manual for software on the web. You always choose the single page version instead! Also, it was difficult to port the Orinoco code, because it depends on the site being in the root, whereas I wanted to use a subdirectory.
TODO: Fastest rsync command. There's a commandlinefu tip about this that says not using -z can actually speed it up. Network vs CPU, who will win?
One idea I've had for a while is making a # syntax for searching in files, probably just #/some%20string. Possibly underscores should automatically be converted to spaces so that you can use #/some_string. I made a Single Page Application that isolates sections of a document called jQuery Paginator that is somewhat related to this idea.
The idea behind this was having a JSON homepage:
{"name": "Sean B. Palmer",
"email": ["compute", "this", "yourself"],
"twitter": {
"nick": "@sbp",
"url": "https://twitter.com/sbp"}}
(TODO: Find post where I discuss primary data and derivations. Also, having people compute my email address by working on SETI, or mining bitcoin for me, would be somewhat interesting.)
Of course, if I change any of the data then it's a pain for people. This is basically an API, and APIs tend to be rather fragile—often even more fragile than just scraping a webpage.
But I wondered what it would look like if you used something more like Python's pickle format, actually serialising ADTs and putting them on the web. The most obvious example above is the url. Of course, pickling that doesn't work so well:
>>> import pickle
>>> import urllib.request
>>> req = urllib.request.urlopen("https://twitter.com/sbp")
>>> pickle.dumps(req)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: cannot serialize '_io.BufferedReader' object
Let's say, though, that you could. Then you'd have something like:
{"twitter": URL("https://twitter.com/sbp")}
Now, it's easy enough to just add constructors in a JSON-compatible way, just by adding some syntax that shows it to be a constructor:
{"twitter": ["URL()", "https://twitter.com/sbp"]}
Of course, then you want some standard datatypes: Integer, String, URL, in addition to List and Mapping/Dictionary that are already in JSON. The actual implementation of these classes can be up to the language that loads the data, just like with existing JSON. For example, are [] lists always mutable in JSON implementations? Do they always support exactly the same indexing and sorting methods and so on? Obviously there's variation between languages.
Bootstrapping code: In unix, emacs, and other modular systems, the more that you work on improving the tools that you have available and making them work together, the more you bootstrap new possibilities. It would be nice to do this on the web, not running isolated JavaScript islands, but having an archipelago of code.
The manual for Robot Odyssey, which I learned about from Slate, is available on archive.org. There's a binary patch which makes the DOS version of the game playable on dosbox, but you have to patch the patch by converting jmp end in asmPad to jmp word end. The robot-odyssey.zip that I found to work has an SHA1 of 1a7645cfba8f56738f2ca2e8dea6ff0a695592b2.
There was a similar game for the PlayStation called Carnage Heart which was released in 1995, but the programming of these robots seems like it may have been easier than Robot Odyssey and ChipWits. It's not clear whether Carnage Heart was based on either Robot Odyssey or ChipWits. There was a cool looking Carnage Heart software image creator which seems to have disappeared from the web. Aran Johnson said in 2007 that Carnage Heart "sounds a lot like an evolution of an Apple IIc game I had called Robot Odyssey." TV Tropes has a good list of programming games.
Due to the emacs distnoted bug, I upgraded to HEAD. There are some instructions to switch to a different Homebrew installation on Stack Overflow. One nice feature in HEAD, which is the upcoming 24.4, is dired-hide-details-mode.
One of the things that makes emacs stand out compared to other kinds of programming is that so much is built into the language. There are so many batteries included. This means that you very rarely make things using the primitives of the language. Usually you're using far richer functions.
Imagine if such richer functions were available like pages in a database. You should also be able to make interactive versions of them just by scribbling them down. You could draw a box and it would turn into a text input, for example.
Algernon posted Hy: the Logical Choice, and I made some comments on it:
I used to do a lot of logic programming, but it was all a holdover from the crappy AI stuff of the 1970s and 1980s pretty much. I don't like prolog. My work in cognitive science meant I kind of went into constructivism, which really put me off of AI-oriented formal systems. This meant that I didn't really like logic programming anymore, because most logic programming is infected by this stuff.
I guess I should take a look at miniKanren and see whether it's cooler and sleeker than the old crap.
The reversible macros in adderall are nice. You could even rewrite the Hy compiler using adderall, and then you could decompile Python to Hy. It'd be nice, because whole-structural-transforms are much rarer than macros, but much more powerful. I can't think of many languages that have them. XSLT... also some domain specific SQL-derivatives. Like, you can push an XSLT stylesheet through itself. It would also theoretically make extending the compiler much easier, more modular. And it'd be possible at runtime! You could have mixin compiler extensions.
Of course, the line then starts to blur between macros and compilers. You know is it a new part of the compiler, or a macro? It doesn't really matter how you think of it. I remember thinking this about some Common Lisp stuff. I made a simple while macro:
(defmacro while (condition &rest body)
`(loop while ,condition do
,@body))
And a simple nonsensical example like this:
(while (> 2 1)
(+ 1 1)
(+ 1 2))
Gets macro expanded once to:
(LOOP WHILE (> 2 1)
DO (+ 1 1) (+ 1 2))
But when you do macroexpand-all, you get almost incomprensible results!
(BLOCK NIL
(TAGBODY
SB-LOOP::NEXT-LOOP
(IF (> 2 1)
NIL
(PROGN (GO SB-LOOP::END-LOOP)))
(PROGN (+ 1 1) (+ 1 2))
(GO SB-LOOP::NEXT-LOOP)
SB-LOOP::END-LOOP))
Now it contains so many optimisations and low level hints. I thought that actually it's half way to compilation just through the macros. A macro is really just a very constrained form of compilation, where a compilation is just a transformation from one arbitrary AST to another. When you think about nanopass compilers, I expect they could actually benefit from this approach. It would be a crazy amount of work, and probably involve some real cutting edge research to do properly. But at least if you're working in the logic domain, making proofs that the IRs are consistent should be easy. Essentially every transform would make a new IR, so you just have to prove it for each transform. I did try this myself, and I got pretty bamboozled pretty quickly. Some of the transforms require side-effects and stuff that make it a bit hard to track. Always a problem with declarative programming.
There's a good miniKanren tutorial available for free on the web. I don't like The Reasoned Schemer very much.
Single long document forms of notes or weblogs are suprisingly rare on the web. Taylor R. Campbell keeps a "blag" in this style, and Tav used to keep some notes in this form too.
Ted Nelson talks about the Xerox PARC GUI (or PUI) as being inferior to the possibilities of NLS and Xanadu. I was thinking about this when playing Robot Odyssey. If I were a researcher at Xerox PARC, I can't imagine having come up with the PUI. I'd try to come up with something much better. Games seem to have evolved far better interfaces, independently of the office mindset.
One of the things that is apparent in games is that every object is given a presentation that you can interact with. Games usually have physics, which are rules about presentations that help to keep things consistent, and usually have a direct real world metaphor. But the world of information ought to make us think beyond real world metaphors too.
Instead of having a mutable document which is composed of a structure, such as a sequence of unicode characters or a DOM, imagine a journal of user interface actions used to create a document. Such a journal would be immutable, and could be incrementally cached. As well as noting UIAs like "inserted this text", you could note the source of the text: "inserted this text, which was copied from a particular webpage".
(From IRC)
Why doesn't github offer OpenID? Cf. an SO thread. Interestingly, you can use <link> for openid2. Github, as a useful service, being an OpenID provider might give it some more credence. This idea is part of my useful data homepage idea. Other things that could be on a data homepage:
Probably don't need much else. Basically these are things that you want automatic discovery for. If blogs were still being used, automatic links to specific feeds might be helpful. If twitter were open, then you should be able to link to the data there. I thought perhaps identi.ca publish open data, but instead it appears that they have closed down my account without telling me, even though I had sent at least one public message using their service.
The difference between OpenID and OAuth is quite minimal, and this probably doesn't help for OpenID. There's also Mozilla Persona, and the underlying Browser ID, which you basically don't hear about anywhere. Apparently you can use Gmail with Persona.
It seems from the Persona Setup Guide that the X-UA-Compatible: IE=Edge HTTP header may be equivalent to the duty of <!doctype html> for IE.
When did Gravatar get such a monopoly on avatars? I think basically every site uses that, except for twitter.
Compare the .well-known scheme.
Keep wondering about a Firefox WebOS, i.e. some kind of interface to the web written as a Firefox extension. You can imagine the web as being an imaginary place where vector capable hardware preceded the first OSes.
You'd want to be able to make a forward extensible interface using the HTML5 stack as much as possible. Probably wouldn't be very good. Imagine making your own new interfaces down to the pixel level. It's also difficult to imagine what would actually replace the PUI. Still like the idea of drawing things to make them come to life. Just draw anything and the computer will make it interactive for you. Type things in and it can enrich your objects.
For example, you draw a crude mailbox. That becomes your actual mailbox, just a "link to an application". (Cf. the essay someone wrote about things always just being links to applications.) Perhaps it shouldn't be a link to the mailbox. What else could it be? Could be a collection of the data in memory and on the disc that pertains to the mailbox. If it's a POP3 mailbox, then you'd have authorisation details, a link to local archives, probably some caches for displaying the most recent stuff.
Asking people to draw things isn't very efficient. In emacs we'd use something like C-c m to open email. In OS X it might be Command-Space Mai <ENTER>. On the web we'd load a bookmark, or type mai <ENTER> into the address bar. On a Windows desktop, or on iOS or Android, we'd click a mail icon. On an older mobile you might have to select Mail from a menu. These are all quite simple forms of interaction.
Mail is an amusing example, really, because it's so difficult to run a mail server without it being blacklisted, or without it mishandling spam. So we delegate these tasks now to cloud companies, who don't treat our data as kindly as they should.
Could transform embedded Markdown to HTML by extracting. In other words, the document would look like:
<!--
# Markdown goes here
This is an example
-->
<h1>Markdown goes here</h1>
<p>This is an example
The only problem with this is that automatically saving will of course mutate the bottom of the document, which means you'll also have to make it automatically reload from disc upon changes.