4 ms·

My own opinions: (1) Non-linear cell order (and in particular re-running all dependent cells anytime anything gets changed) is a huge improvement vs. mathemati

My own opinions: (1) Non-linear cell order (and in particular re-running all dependent cells anytime anything gets changed) is a huge improvement vs. mathematica/matlab/jupyter notebooks. Once you get used to it you will feel crippled when you try to go back. Being non-linear allows the author to optimize for whatever flow best matches the narrative, rather than ordering things based on arbitrary implementation-specific requirements of the programming environment. It is also possible to e.g. put simplified or brute-force implementations inline in the prose, and then move tricky optimized versions to technical appendices at the end of the document. Being non-linear also allows for showing some placeholder output right away and letting expensive-to-compute output (or slow-to-fetch data) execute after initial notebook load and progressively replace the placeholders. This lets readers get started reading the prose right away without needing to wait for slow operations. (2a) Being able to pin the source of a cell to be shown / hidden at the author’s discretion makes for an improved reader experience in the typical case (assuming a conscientious author). Nobody wants to read e.g. big blobs of redundant LaTeX source in addition to their mathematical formula output. Needing to sometimes click to show code that an author left hidden in the initial view is easy after just a tiny bit of experience as a reader. As an author I tend to mostly leave prose markup pinned closed and code cells pinned open (unless they contain too much distracting or overly technical detail) when publishing notebooks. (1 & 2a) These two features both change incentives for notebook authors: since code can be hidden in the default view authors are not afraid to use a better implementation which includes distracting technical details; in other notebook environments I have noticed authors intentionally use worse-performing but simpler implementations, and technical details often get moved to some external library, hiding the code much more deeply than just putting it in a cell with hidden source / moving the cell to the bottom of the document. (2b) I also prefer output below code, but the reason for the order here is so that showing/hiding the source won’t make the output jump up and down the page excessively; with a bit of experience the other order is not really an obstacle in practice. (3) It’s Javascript (with a few minor additions as shown in TFA), but you can use whatever javascript tagged template you want, including html, markdown, or anything else you can dream up. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#Tagged_templates https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... (4) It is fairly easy, but it’s a fair complaint that it takes some trust / involves some risk to build work on top of a closed-source platform, especially for folks with strong free software ideology; even if it is possible to mirror code outside observablehq.com, it is at least mildly inconveient, and necessarily loses access to some great platform features. I personally have a lot of faith in the Observable team’s commitment to not breaking documents published on their platform or letting them disappear. But when business is involved, there’s no absolute guarantee.

kragen 7y ago
Oh, this is interesting — Observablehq isn't free software? It hadn't even occurred to me that it might be proprietary and not even runnable off the platform. You say, "when business is involved, there's no absolute guarantee", but to me, that sounds like an absolute guarantee that your documents will disappear — consider how many companies are still around from only 3000 years ago, right before the Bronze Age Collapse, and compare to how many documents survive from that time.
- jacobolus 7y ago
  Your individual documents can be pretty easily exported and self-hosted. The parser, runtime, standard library, etc. is free software. https://github.com/observablehq https://github.com/observablehq It’s just not going to have all of the editor GUI, community features, etc. of the Observable platform. > absolute guarantee that your documents will disappear Okay sure, but that is true of every digital document. The documents that survive from <1000 BC are almost all either carved into stone or impressed into clay tablets. Pretty well everything that was written on a flexible organic surface from 2000+ years ago has been destroyed, but scattered bits of oral history retold by generations of storytellers and some written books repeatedly copied by generations of scribes have managed to survive. A tiny number of original documents written on papyrus, animal skins, etc. have stayed partially intact. If you want you can certainly carve your Javascript programs into stone, but I wouldn’t bet on anyone being able to run them in 4000 years.
  - kragen 7y ago
    In what sense is an Observablehq document without the editor GUI the same document? Isn't the whole point of Observablehq that your computation reacts correctly to modifications? Maybe I'm confused about which part exactly is free software and which part isn't, and I should try self-hosting some documents. It's good that you're aware of the basic aspects of the archival problem, but you're mistaken about the role of digitality — being digital makes it possible to copy documents losslessly, thus preserving them even when the original substrate is lost. That's the reason that, for example, the older books of the Tanakh survive from that time in some form, even though they weren't carved into stone: the alphabet is a digital technology, not an analog one, enabling verbatim copying. So digitality is an advantage for archival, not a disadvantage. (You alluded to the survival of the Tanakh in your comment, so you know about it, but somehow you got its significance backwards.) Media longevity and interpretability are, as you say, important problems. They require significant engineering effort to solve. Also, it is possible to engineer ways to sabotage media longevity and interpretability, thus greatly reducing the chance of archival success. Making your documents' interpretability conditional on the survival of a mere commercial interest is a good example of such archival sabotage, as many authors and historians have discovered, to their sorrow, in the Geocities era. I have the sense that you're not seriously engaging with the problem, but rather looking for a quick dismissal, so you may not be interested in the following: It's relatively straightforward to micro-engrave megabytes of programs onto copper, glass, silicon, nickel, and similarly stable materials, which will easily survive for a million years. Gigabytes are more expensive. Clay and stone are also pretty easy, but with the straightforward fabrication techniques, they have lower data capacity because of their grain structure. PET is commonly used as an archival material, and should easily last longer than paper, but it's less trustworthy — its combustibility in air means that a PET-air system is merely metastable, not stable, and the timespan of that metastability could easily be much less than that of glass. But even old hard disks could easily have media longevity exceeding the mere 3000-year timespan we're talking about.

kragen 7y ago

Oh, this is interesting — Observablehq isn't free software? It hadn't even occurred to me that it might be proprietary and not even runnable off the platform. You say, "when business is involved, there's no absolute guarantee", but to me, that sounds like an absolute guarantee that your documents will disappear — consider how many companies are still around from only 3000 years ago, right before the Bronze Age Collapse, and compare to how many documents survive from that time.

jacobolus 7y ago
Your individual documents can be pretty easily exported and self-hosted. The parser, runtime, standard library, etc. is free software. https://github.com/observablehq https://github.com/observablehq It’s just not going to have all of the editor GUI, community features, etc. of the Observable platform. > absolute guarantee that your documents will disappear Okay sure, but that is true of every digital document. The documents that survive from <1000 BC are almost all either carved into stone or impressed into clay tablets. Pretty well everything that was written on a flexible organic surface from 2000+ years ago has been destroyed, but scattered bits of oral history retold by generations of storytellers and some written books repeatedly copied by generations of scribes have managed to survive. A tiny number of original documents written on papyrus, animal skins, etc. have stayed partially intact. If you want you can certainly carve your Javascript programs into stone, but I wouldn’t bet on anyone being able to run them in 4000 years.
- kragen 7y ago
  In what sense is an Observablehq document without the editor GUI the same document? Isn't the whole point of Observablehq that your computation reacts correctly to modifications? Maybe I'm confused about which part exactly is free software and which part isn't, and I should try self-hosting some documents. It's good that you're aware of the basic aspects of the archival problem, but you're mistaken about the role of digitality — being digital makes it possible to copy documents losslessly, thus preserving them even when the original substrate is lost. That's the reason that, for example, the older books of the Tanakh survive from that time in some form, even though they weren't carved into stone: the alphabet is a digital technology, not an analog one, enabling verbatim copying. So digitality is an advantage for archival, not a disadvantage. (You alluded to the survival of the Tanakh in your comment, so you know about it, but somehow you got its significance backwards.) Media longevity and interpretability are, as you say, important problems. They require significant engineering effort to solve. Also, it is possible to engineer ways to sabotage media longevity and interpretability, thus greatly reducing the chance of archival success. Making your documents' interpretability conditional on the survival of a mere commercial interest is a good example of such archival sabotage, as many authors and historians have discovered, to their sorrow, in the Geocities era. I have the sense that you're not seriously engaging with the problem, but rather looking for a quick dismissal, so you may not be interested in the following: It's relatively straightforward to micro-engrave megabytes of programs onto copper, glass, silicon, nickel, and similarly stable materials, which will easily survive for a million years. Gigabytes are more expensive. Clay and stone are also pretty easy, but with the straightforward fabrication techniques, they have lower data capacity because of their grain structure. PET is commonly used as an archival material, and should easily last longer than paper, but it's less trustworthy — its combustibility in air means that a PET-air system is merely metastable, not stable, and the timespan of that metastability could easily be much less than that of glass. But even old hard disks could easily have media longevity exceeding the mere 3000-year timespan we're talking about.