By day I work as a software engineer for a heartless global corporation. By night I shitpost about hypertext and leftist politics. For a little while I worked on Project Xanadu, and I write freelance on medium (and for publications like Tedium) as a side hustle. Every november I participate in NaNoGenMo, a 'contest' for writing programs that write novels. I have released nearly 50 albums worth of experimental electronica under the name 'Infocalypse', and published two essay collections. I've been on this site for a few years, but I rarely post.
I was originally brought on in 2011 to bring the XanaduSpace 'prototype' written by Rob Smith up to releasable quality (after Ted came across coverage of my ZigZag-inspired operating system iX on hackaday).
XanaduSpace (or, at least the version we pieced together from chunks of various different versions -- the author didn't use revision control) was more of a demo & a POC than a prototype, and so salvaging it was more work than we expected (especially because we needed it to be cross-platform and needed to integrate a nice, responsive editor). We (myself and my buddy) ended up rewriting it entirely, and that became a different (never-released) project called XanaSpace.
Part of the XanaSpace rewrite was switching from OpenGL 1.1 to modern OpenGL -- necessary to make editing responsive, and necessary to fulfill certain demands about the amount of text we can display. But fulfilling the text quantity demands (we needed to support arbitrary unicode in arbitrary truetype fonts & be able to display the whole king james bible on screen at once) were tough, and my partner and I burnt out on it. We were working as volunteers anyhow, so we sort of skated along for a few years.
I worked a little bit on the web-based OpenXanadu, released in 2014 (wrote the code to display the little 'X' logo during loading, and also wrote a substantial amount of code to support a caching proxy that we never ended up releasing & an entire editor we also didn't end up releasing), though the current web-based version on the xanadu site (called XuCambridge, formerly XanaBurger) I didn't have any connection to. I'm still occasionally consulted on ZigZag.
Ultimately, the biggest impact of my tenure on Xanadu (aside from being able to brag about attending Ted Nelson's wedding) has been my work with documentation. Both official and internal Xanadu documentation has been a bit hard to make sense of for newcomers: Ted has a carnival-barker sensibility when it comes to style, a love of puns and neologisms that would put Pynchon to shame, extremely severe ADHD, and hasn't written a line of code since the 60s (though he has a deep intuitive understanding of data structures and their performance), so 'documentation' is mostly Ted making up new words and pontificating about how cool his ideas are -- a real shame because his ideas really are good, if you can figure out what they are. So, with his blessing (if not his oversight), I wrote an introduction to Xanadu internals aimed at software engineers not acquainted with the project: https://medium.com/@enkiv2/an-engineers-guide-to-the-docuverse-d080cdbb73a6?source=friends_link&...
because you posted a gopher link I decided to read this in gopher, which is great because it encouraged me to improve my client by adding line wrapping.
The author wants inline links, I'm not sure why links inside a paragraph is something they want so much. They also say no inline images - I can understand that. The thing I want is to add to gopher is (basic) markdown support including inline images.
They also talk about adding TLS which I personally really don't like and don't think we should.. but I understand if I'm outvoted on this one. I totally agree with you on tor and advocate using .onion for gophers where you need confidentiality and authentication - even though it's technically a much bigger codebase to include compared to openssl it requires zero change to existing gopher clients or the protocol.
I don't think there is really much need for encryption for gophers. A lot of people want it though. Why do they want it? I'd prefer looking into alternative solutions like .onion or even some a shared/trusted network you connect through.
Another argument against TLS in gopher is: Can you implement TLS? If you can't implement it maybe it shouldn't be part of the spec. There are light weight cryptosystems that you can implement.
Thanks for this lovely post, I'm happy to see all this activity around gopher just now. I'm adding a link to it from my phlog.
I think it's true of most proprietary applications, & most applications not intended for use by technical folks.
Even in cases where deep configurability & scriptability exists, it's generally hidden (as though it's embarassing) & 'normal' users never become aware unless using those features has been grandfathered in by a technical community. (For instance, some games are heavily moddable, but most players are not modders & modding is considered something special; as another example, Microsoft Word and Excel are highly scriptable, and many but not most non-programmer users are aware of this in a vague way because they belong to a group that uses existing scripts to make up for missing core features or adapt the program to a particular domain.)
Applications for programmers tend to be extremely scriptable, and tend to expose that extensibility.
(Even so: I'd really like to be able to do real intense modifications to running applications without a separate recompile step, which is something applications don't do outside smalltalk-land. Likewise, I'd love to be able to throw together widgets as casually as I write pipelines.)
For any dynamic language with a REPL, you can expose the language & make it so live modification can be done. GUI toolkits don't tend to expose the language by default, & applications don't tend to go to the effort to expose them themselves (or design their internal structures to be amenable to live-editing by non-programmers as opposed to modification during a normal development cycle).
It's not a problem of missing features generally (though sometimes it is -- like if a language, by default, loses the original source after bytecode compilation, & the compilation step can't be hooked to keep that source around), but of UI (though a whole host of unusual language features can make providing a reasonable UI to do this a lot easier -- like having an image-based system and having that image versioned internally).
Back in high school, I wrote a system intended for exposing live tcl scripting to a Tk-based set of widgets, as part of a 'desktop environment'. Doing such a thing is easy, if you don't mind doing it badly, even with a language & framework like tcl+tk that isn't really intended to support it.
Scriptability is, I think, a different (related but less interesting) version of this. Rarely is the whole application really scriptable -- it's unusual to have an application that can be turned into functionally an entirely different application through the exposed scripting API without a great deal of knowledge and effort (greater than the knowledge & effort necessary to write the thing from scratch in a normal environment); and then, scripting normally operates in the same way as a normal build process (wherein you edit files on the filesystem with your text editor & force a reload), which ultimately means unfamiliar tooling to non-technical users & no support for built-in documentation.
I think the article here describes a spectrum of end-user-programmability where the far end is what I termed 'composable UI' -- stuff that looks like smalltalk environments, in that the programming environment is one pop-up menu away from any widget, with full built-in documentation, and where a non-programmer can stumble into it accidentally & be glad they did because it let them solve their problem.
I really appreciate the way so much of this is Aaronson just really shutting down his interviewer about this Penrose 'quantum consciousness' stuff. Since he teaches QM for a living, he's a lot more clear about the mechanisms here than other folks.
(Pewdiepie is legitimately good, but he catches a lot of hate. Mostly it's just a difference in style that people react negatively to.)
In another life I'd do a Let's Play video for this. Always wanted to be a youtuber. Mana for our Malices has that kind of vibe where it'd make for an interesting video.
And also, self-promotion is absolutely cool on laarc (with obvious exceptions for spam and such). People rarely make things. It was partly the whole point of the site for people to be able to show off their own work.
I could convert this submission into a Show if you want. It'd stick around in /l/show.
> I could convert this submission into a Show if you want. It'd stick around in /l/show.
> What did you use to make the music?
The music is cherrypicked from stuff I've released over the years, so there's some variation in tooling. Earlier stuff was largely done in Audacity & is sample-based (though the samples have been mangled to full unrecognizability). Some tracks were produced by various music-generation experiments I worked on (and some of these produced MIDI). The chiptuney-sounding tracks were produced with my project Clisynth, which is a tracker-inspired system for unix that sits on top of sox & has various tools for partial procedural generation based on musical tools.
Do we have support for seeing a timeline filtered by a list of tags (other than all)? For instance, it might be useful to look at all the posts listed as either dev or programming.
Personally, I read through the tag list before making a post & use a new tag if I think some important part of categorization isn't captured -- but that's mostly because most tags are clearly not relevant to the stuff I post, & because I tend to stick to a relatively small set of topics.
I think the author applies ideas unique to declarative templating & 4GL to all of declarative languages, somewhat misleadingly. (This isn't unexpected -- most programmers have worked with declarative templating & SQL, but relatively few have worked with a declarative programming language that is actually intended for programming in, like PROLOG.)
He also conflates declarative languages and DSLs in various places. A declarative language can be as general-purpose as an imperative one (although I maintain that there is no such thing as a truly general purpose language: all languages can be applied with varying degrees of difficulty to any task, and the languages we call 'general' eschew a good fit for one domain in favor of roughly equally poor fit across all domains).
Nevertheless, I agree with the idea (implied by his introduction but ultimately never stated in his conclusion somehow) that our declarative languages ought to be able to embed imperative blocks & our imperative languages ought to support declarative sublanguages. (The only system I can think of that did this well is Icon, unfortunately.)
"that our declarative languages ought to be able to embed imperative blocks & our imperative languages ought to support declarative sublanguages. (The only system I can think of that did this well is Icon, unfortunately.)"
I don't know. sklogic's tool (below) looked pretty impressive. Submitted it to discuss it in its own thread.
This looks cool! Thanks for bringing it to my attention.
I should rephrase my complaint. I'm not annoyed that one can't embed declarative constraint programming into popular languages -- minikanren is pretty widely available & swi-prolog has bindings to a lot of languages too. Instead, I'm annoyed that the industry doesn't make heavy use of declarative constraint programming in prototyping. After all, doing so would mean non-performance-vital imperative code wouldn't need to be written at all (just specified, with a naive implementation supplied by the compiler), formal methods could more easily be applied to verify production code (since even those parts that were implemented by a programmer would need clear specifications in order to be used by the prover), and projects structured this way could gain performance for free from advances in efficient code generation for constraint solvers. It's both a short term and a long term boost in effective engineer time. (And, of course, it slots nicely into test driven development: your formal representation of the problem domain can create tests, implementation, or both.)
Just backtracking by itself is really nice. If combined with a branching version system, backtracking in an AST could be used for capability-based security. If that branching version system forks into multiple threads with copy-on-write (and no side-effecting), multiple branches can be considered at once & backtracking could just kill the spawned process.
To the extent that normal programmers use this facility at all, it's in the context of a problem they have with SQL performance: "why is this query taking so long? why didn't the planner make it more efficient?" This is probably an indication that having a planner that you can't overrule with your own imperative code is a mistake.