Most of what I want out of a website is unformatted text and jump links. Given that, the appropriate (already existing) technology to deliver it with the minimum of fuss is not HTML+CSS but gophermaps! I’d love to see people use gopher+gophermaps instead of HTML+HTTP when formatting isn’t necessary, though that’s an even bigger leap than getting people to avoid CMSes for that use case.

This is interesting, but another 20 years of software development continues to prove him wrong.

The current dominant paradigm is flat, single-ordered lists, and search (perhaps augmented with tags like our dear lobste.rs here).

This is even more of all the bad stuff he’s railing against at the start of the article, but this is the stuff that works and there are innumerable other approaches dead or dying.

It suspect that for UI’s less freedom is simpler (one button, one list, one query, one purpose, etc.) and not the other way around.

For developers, I think he was right, and it’s also what we’ve got today. It’s clearly preferable for developers to have a simple model to work against (Like URIs + JSON).

apt-get install firefox (Which unpacks to a resource identifier and a standardized, machine-readable package file) is quite probably as good as it gets. It’s a directed graph instead of an undirected graph like his zipper system, but undirected graphs require an unrealistic (and in my opinion probably harmful) amount of federation between producers of API’s and their consumers.

This guy is absolutely terrible at communicating his ideas.

I agree that it would be nice to have rich content formats. As he puts it “hypermedia” might be ok: it’s a medium that spans several dimensions of expressions, and can thus be read in several ways.

But his example is terrible, the execution is poor, his drawings are a joke, even the argumentation is full of circumvolutions. This is obvious, to me, that this guy has no idea what he is talking about. He has no idea about the complexity of implementing what he is talking about (properly I mean, not as PoC).

When we look at history and what finally happened, I contend that while at a base level we can see that economic or political factors could sway computer science one way or another, but I think that’s for trivial stuff, like choosing one encoding over another, because for example designing an ASIC capable of doing it in hardware cost less, even if the other encoding is better in pretty much all other ways. But looking at the big picture, what won was simplicity, the least (overall) effort.

This is, I think, what he means when he says that current content is in the format choosen by computer scientists. And this is true. Because all technic will evolve this way.

His idea are infeasible IMO. I would love to receive an article one day where I will be able to open it using mathematica to look at graphs and play with the data, read the content in another interface, navigate the cited papers and have more context about the authors for example. But all of this is already possible. There is no need for a data-structure to be specifically designed for it, this is implementation detail, abstraction leakage. ZigZag is just a bad idea. It should not exist (and I can’t help but be extremely sceptical at the amount of trademark this guy uses, as if his ideas were worth anything).

What I find weird actually, is to be speaking about hypertext like some kind of invention. The concept is just so trivial and so self-evident, no one invented it! What was invented was a proper grammar to describe the object and protocols to communicate about. But the concept is trivially simple. Same stuff for hypermedia, but then, the implementation is infeasible (in a standardized, content-agnostic way).

MUMPS is still in active usage, I think? A few years ago I interviewed someone out of the midwest (Minneapolis or Michigan, I think) who worked for a large health software vendor. They’ve been around for a long time, and they’re in a lot of hospitals across the US. I’m pretty sure their whole system is built in MUMPS.

The more I learn about MUMPS, the less ‘awful’ it seems.

It’s a strange language, sure – but so is Python (semantically-meaningful indentation), Lua (use of tilde for negation, combined array-dictionary-object type), FORTH & LISP (for obvious reasons), JavaScript (ditto), and basically every popular language besides. There’s so much variety in languages that we can’t reject something like indenting with period as an indicator of quality.

MUMPS has language features I wish were more common! For instance:

• first-order arbitrarily-nested non-relational databases with autovivification
• an almost smalltalk-like image/persistence, because all variables prefixed with ^ become persistent across runs

Between these two features, MUMPS as a computing environment has an out-of-the-box usability that shames more ‘modern’ languages & REPLs for certain types of problems (in particular, problems involving big, complex, free-form relationships between different kinds of objects).

Don’t sacrafice fonts for being “minimal”, though. That font and text size is not great for reading if that’s your primary goal.

I’m about halfway through your article, & a lot of the ideas you float here are familiar from Xanadu work.

With regard to link creation, we had a planned editing system for XanaSpace that uses selection in a similar way but might be a little more intuitive. Specifically, we had the idea that each window might have its own persistent selections, and because links here are bidirectional, dragging a selection into another selection produces a link, while dragging a selection to a point produces a transclusion (and is the equivalent of a copy-and-paste). Since editing documents is intended to be transclusion-heavy, the idea is that text you’ve typed goes into an unnamed (but permanent) scratch document (perhaps the private permascroll) – appearing as a noodle of floating text – and gets dragged into another document or snapped into place alongside another orphan noodle.

Unfortunately, two things made this awkward: cross-platform inter-window communication supporting drag & drop isn’t really well-supported by UI libraries, and neither is dragging between distinct text objects on a canvas. Already, for XanaSpace, we were rolling our own text layout for 3d, but this meant that the 2d version was also going to be difficult to manipulate this way, so we put actually implementing it on hold until the (never-completed) large text rendering optimizations.

I also like the ‘management view’; we had a similar thing in XanaSpace done just with 3d zoom, and planned a ‘lolly-pop’ view wherein links/beams remained visible between documents but their actual content was collapsed sideways, with a ball on the top indicating the total document length.

I don’t separate my technical posts from other topics. I publish to https://medium.com/@enkiv2 with periodic backups to http://www.lord-enki.net/medium-backup/ & highlights periodically featured & categorized on http://www.lord-enki.net/

After spending a few months with Forth earlier this year, I absolutely agree that Forth can be extraordinarily simple and compact, that mainstream software is an endless brittle tower of abstractions, and that the aha moment when you find the right abstractions of a problem can be transcendent. But writings like this also indicate limitations that the Forth community unquestioningly accepts.

Forth is quite “individualistic”, tailored to single persons or small groups of programmers.. nobody says that code can’t be shared, that one should not learn to understand other people’s code or that designs should be hoarded by lone rangers. But we should understand that in many cases it is a single programmer or very small team that does the main design and implementation work.

This is fine. However, the next step is not:

once it becomes infeasible for a single person to rewrite the core functionality from scratch, it is dead. The ideal is: you write it, you understand it, you maintain and change it, you rewrite it as often as necessary, you throw it away and do something else.

I’ll suggest an alternative meaning of “dead”: when it stops being used. By this definition, most Forth programs are dead. (duck) More seriously, it is abuse of privilege to claim some software is dead just because it’s hard to modify. If people are using it, it is providing value.

It is the fundamental property and fate of all software to outlive its creator. The mainstream approach, for all of its many problems, allows software to continue to serve its users long after the original authors leave the scene. They decay, yes, but in some halting, limping fashion they continue to work for a long time. It’s worth acknowledging the value of this longevity. Any serious attempt to replace mainstream software must design for longevity. That requires improving on our ability to comprehend each other’s creations. And Forth (just like Scheme and Prolog) doesn’t really improve things much here. Even though ‘understanding’ is mentioned above, it is in passing and clearly not a priority. Even insightful Forth programs can take long periods of work to appreciate. If a tree has value in the forest but nobody can appreciate it, does it really have value? I believe comprehensibility is the last missing piece that will help Forth take over the world. Though it may have to change beyond recognition in the process.

(This comment further develops themes I wrote about earlier this year. Lately I’ve been working on more ergonomic machine code, adding only the minimum syntax necessary to improve checking of programs, adding guardrails to help other programmers comprehend somebody else’s creation. Extremely rudimentary, highly speculative, very much experimental.)

This is getting a lot of hate. I thought it was pretty even-handed. Do people dislike it because I said culture fit should only matter when it impacts effectiveness, or because I think culture matters at all?

Someone who writes ostensibly production-ready code in PHP or Perl should be treated like someone who refuses to vaccinate their children: their behavior should be considered acceptable only if they are extremely careful and they have a very good excuse.

I think the author is a bit melodramatic, and that is the toxic part – there’s criticism, and then there’s criticism without concern for the humans receiving the criticism. I agree with the author that there’s a vast majority of programmers who could benefit from better tooling (I put myself in this camp), but how that knowledge is conveyed makes all the difference (as they mention in the article itself).

It sounds like the author has knowledge and wants to spread it – either by mentoring or teaching directly. To be successful at that, they need to understand where a mentee/student is and jump into their worldview before moving them forward. There is a huge difference between “here is where I think you are, which means you’ve probably seen these kind of frustrations pop up, why not try X instead” and “hey you’re doing this all wrong, here’s the best way.”

Sidney Dekker talks about how people don’t show up at work to do a bad job – everyone is usually trying their best, but is working within constraints (“my boss won’t let me use X”, “I haven’t heard about this,” “I have outdated knowledge about this,” “I don’t want to support this organization for moral reasons,” “I’m under a tight deadline and can’t afford the rewrite,” etc). People will only be receptive if you acknowledge that they are doing their best within constraints, and you are removing a constraint. “You use PHP, therefore you are bad” statements make you feel good and self-righteous, but are less effective than “do you hit these kinds of errors?” “yes!” “then you might consider this other language, it’s easier than you think.”

As I write this I feel a bit hypocritical as I’ve spent a long time criticising {large, well known software product with a defensive, tribal culture} for not doing {well established modern software engineering practice} and releasing a buggy and infuriating product. My ranting and raving did nothing. Absolutely nothing. What was effective? Another team got merged into that one and started flooding the mailing lists with “you thought {software engineering practice} was impossible at this scale but it’s actually doable.” It worked. That’s how you effect change in organizations that might even be hostile to you: meet them where they are, treat them as doing their best within constraints, and show how to remove the constraints.

That is a very reductionist view of what people use the web for. And I am saying this as someone who’s personal site pretty much matches everything prescribed except comments (which I still have).

Btw, Medium, given as a positive example, is not in any way minimal and certainly not by metrics given in this article.

Haven’t read the paper entirely, but enjoyed the walkthrough of design decision references and the list of other implementations. You may also want to share your work to https://twitter.com/clausatz who’s trying to make a museum of xanadu/zigzag implementations.

(fenfire was one of the projects that still makes me think of how where zigzag could go, https://twitter.com/i/web/status/1012438773253263361 )

I’m getting a 404. Do you have a mirror?

I ought to rewrite this to bring it up to my current quality standards. Something like a third of the document is just bitching about bad UI libraries.

Nevertheless, if somebody is looking at my open source ZigZag backend and wondering how to write a frontend for it, this probably answers their question.

I recently finished Karel Čapek’s “War With the Newts”, which I highly recommend. Fantastic sci-fi satire.

Now I’m in reading limbo. I’ve read a few chapters into several books that seem interesting (on fluid simulation, computer vision, knot theory, computation geometry), but haven’t had one really capture my interest yet. At some point I’ll just have to pick one.

In progress:

• Impro: Improvisation and the Theatre, suggested to me by @pushcx and written by Keith Johnstone. No opinions yet, though the intro is neat.

Recently finished:

• Building E-commerce Applications, a complete waste of money and basically just a lazy compilation of undedited blog posts. Booooo.

• Come and Take It: The Gun Printer’s Guide to Thinking Free, by Cody Wilson of Defense Distributed fame. I finished this probably a week before the current kerfluffle started. There’s a whoooole lot of self-congratulatory bullshit and bluster in this, as Wilson is first and foremost (in my opinion) an attention whore, but buried in there are a couple of good reflections on the role of toolmakers in the pursuit of independence.

• Come as You Are, a delightful book by Emily Nagoski that I heard about through OhJoySexToy (webcomic about sexual health and practices). It covers a lot of interesting academic information about sex, attraction, and romance, and can help in debugging certain failure modes of relationships or in preemptively being a better partner.

The challenging open issue I see with this sort of idea is the question of what links people will see by default when they view a page. If they see only the links the author put in, then we will generally have a situation no different than today (as most people will never change that default). If they see some additional set of links by default, then there will be ferocious competition from spammers to get their links included in that set and in general large arguments about what links will be included in it.

For better or worse, HTML and browser technology today has a simple, distributed, scalable, and clearly fair answer to the question of ‘what links appear in a page by default’, and it’s one that keeps browsers and other central parties out of disputes (and generally out of the game of influencing the answer).

(I admit that these days I look at all new protocols through the lens of ‘how can they be abused by spammers and other bad people’, but partly this is because we know spammers and other bad people are out there and will actively attempt to abuse anything they can.)

I usually read a weird mixed bag of books about computer history and cyberculture books from the ‘90s where everyone thinks the future is awesome or the future is scary.

I’m currently reading Net Slaves 2.0, from the website of the same name, focusing on little stories from the dot-com crash, https://www.amazon.com/Net-Slaves-2-0-Tales-Surviving/dp/1581152841

I recently started Occulture, an essay collection by Carl Abrahamsson. I haven’t heard of the guy, but Erik Davis, Gary Lachmann, and Mitch Horowitz have all given it the thumbs-up (and they are my go-to authors for clear-eyed, unobscurantist histories of the impact of occult ideas on wider society).

I’m slowly working my way through Baudrillard’s Simulation and Simulacra, which though short is very dense. I’m pretty sure I’ve read the whole thing before, but I didn’t have the historical context to really understand some of the examples given back then. It’s easier to understand once you’ve read Society of the Spectacle or become familiar with the ideas of semiotics. The tendency among midcentury french thinkers to look down on signalling as shallow rubs me the wrong way, but I’m sure there’s stuff in here that hasn’t yet been reinvented in cogsci, so it’s worth diving in.

I’ve been slowly plodding my way through Playing at the World for nearly a year. It’s an exhaustive history of D&D (emphasis on exhaustive), and it covers a lot of interesting material just by digging very deep. The part I’m on right now is an extensive history of the prussian tradition in wargaming and its influence on the marketing of british toy soldier accessories.

I recently finished Jeff VanderMeer’s Annihilation, and before that, the VanderMeers’ anthology The New Weird.