2,977 Matching Annotations
  1. Sep 2022
    1. for both access and persistent identity

      This highlights a problem with the Web: the fusion of document identifiers and the channel through which the (or "an") information/service provider makes it available.

      Suppose stakeholder S wants to mirror a document D (published in an HTML-based format) originally distributed by authority A. This will probably involve having to touch D in order to rewrite links to point at S's copies of auxiliary resources instead of A's originals. Simply copying the representation's bytestream is not sufficient.

    1. a URI is like a proper name and baptism is given by the registration of the domain name, which gives a legally binding owner to a URI

      "[... temporarily]"

    1. Before asking the question, how do I build AGI, you first must ask the question, what would I recognize as AGI?

      Wrong. Here, I'll show you:

      Forget about AGI for a moment. Instead, pretend we're talking about pecan pie. Most people probably can't answer the question, "What would I recognize as a pecan pie?" (or a sandwich). And yet thousands of people are able to make (and thousands more people are able to enjoy) pecan pie all the time—probably every day.

    1. This RFC lacks any acknowledgement of the text/uri-list media type.

    2. In some cases, it is not straightforward to write links to the HTTP "Link" header field from an application. This can, for example, be the case because not all required link information is available to the application or because the application does not have the capability to directly write HTTP fields.
    1. The answer is simple – stop using these services and look for privacy respecting alternatives where possible.

      Also: just don't take photos/videos and reduce your social media "footprint" generally.

      Privacy-respecting alternatives don't address the issue raised earlier with the comparison to the celebrity iCloud leaks. Because, to reiterate, privacy and security are different things.

    2. If someone came up to you in the street, said they’re from an online service provider and requested you store all of the above data about you with them, I imagine for many the answer would be a resounding NO!
    1. I’ll read through a dependency, start refactoring, and realize that it’s going to be simpler to write it myself
    2. a bigger source tree

      Someone is going to need to eventually explain their convoluted reasons for labeling this a downside.

      Sure, strictly speaking, a bigger source tree is bad, but delegating to package.json and npm install doesn't actually change anything here. It's the same amount of code whether you eagerly fetch all of it at the same time or whether you resort to late fetching.

      Almost none of the hypothetical benefits apply to the way development is handled in practice. There was one arguably nice benefit, but it was a benefit for the application author's repo host (not the application author), and the argument in favor of it evaporated when GitHub acquired NPM, Inc.

    3. Vendoring means that you aren’t going to get automatic bugfixes, or new bugs, from dependencies

      No, those are orthogonal. Whether you obtain the code for your dependency* at the same time you clone your repo or whether you get it by binding by name and then late-fetching it after the clone finishes, neither approach has any irreversible, distinct consequences re bugs/fixes.

      * and it still is a dependency, even when it's "vendored"...

    1. If the program provides accurate real-time feedback about how user manipulations affect program state, it reduces user errors and surprises. A good GUI provides this service.
    1. The LISP part, though, is not going well. Porting clever 1970s Stanford AI Lab macros written on the original SAIL machine to modern Common LISP is hard. Anybody with a knowledge of MACLISP want to help?
    1. Performance. Running a research project in a browser isslower than running it natively. Fortunately, performanceis not generally critical for evaluating usability. Thus weprioritize compatibility and ease-of-use over performance.

      Additionally, as more time passes, it will become less and less of a problem.

    2. There are several issues to consider when translating re-search projects into JavaScript and running in a browser

      It's a little bit of a misapprehension/mistake to describe this as translation into JS.

    3. We propose building an infrastructure that makes it easy tocompile existing projects to JavaScript and optionally collectusage data. We plan to leverage existing tools to translateprograms into JavaScript. One such tool is Emscripten [15],which compiles C/C++ code and LLVM [14] bitcode toJavaScript.

      It only occurred to me reading this now, and musing about the code size and relative performance of simple programs written first in a to-be-compiled-to-JS language and then in JS, that the folks associated with these pushes are taking the sufficiently smart compiler position. Connected to superinferiority?

    4. the tools can be distributed within static web-pages, which can easily be hosted on any number of exter-nal services, so researchers need not run servers themselves
    5. We propose helping researchers compile their tools toJavaScript

      This is probably too ambitious, impractical. For most cases, it would suffice to make sure that the tools used to produce "traditional" release packages can run in the browser. (I.e., the release itself need not be able to run in the browser—though it doesn't hurt if it can.)

    6. not designed to be secure

      "secure" is used in this context to mean, roughly, "work with adversarial input"

    7. Many research projects are publicly available but rarely useddue to the difficulty of building and installing them
  2. schasins.com schasins.com
    1. Ringer is a low-level programming language for web automation tasks. Many statements in the high-level Helena language are implemented with Ringer. Ringer comes with a record and replay tool; when a user demonstrates how to complete an interaction in a normal browser, the tool writes a straight-line Ringer program that completes the same interaction on the same pages. GitHub
    1. wehave found instances of people using relatively heavy-weightJavascript frameworks like Exhibit [11] just for the compar-atively minuscule feature of sortable HTML tables
    1. Some other things:

      • If I visit https://www.zylstra.org/blog/ and content from e.g. this blog post https://www.zylstra.org/blog/2022/09/10-thoughts-after-100-annotations-in-hypothes-is/ has been inlined, Hypothesis doesn't know how to deal with this—it doesn't know that the annotations that apply to the latter can also be layered onto the inlined content at /blog/. This is a minor quibble insofar as you can measure it on terms of mere convenience. Less minor, however, is that if a user attaches their annotations to /blog/, then it will eventually be orphaned (as more posts are written and the now-current ones get bumped off the page), and will never appear in the correct place on the actual post.

      • When people annotate Wikipedia there's a high likelihood that the annotation will become orphaned as the content changes, even though the version that was actually annotated will usually be available from the article history.

    2. Despite the social nature of h., discovery is very difficult. Purposefully ‘finding the others’ is mostly impossible.

      This was Peter's motivation to create annotations.lindylearn.io.

    3. H.’s marketing director has 1348 public annotations over almost 6 years, its founder 1200 in a decade.

      Public ones, at least.

    1. If you need a site that’s just a single page I think I would use a word processor and do a “save as html”.
    2. Over in the IndieWeb community we were having a conversation about how easy it should be for people to create their own websites (also for small local businesses etc.) Where making the site is basically the same as writing the text you want to put on it. Social media silos do that for you, but out on the open web?
    1. When I go to use some software it takes an inordinate amount of time to set things up.
    2. Some of my ruby, nodejs and python projects no longer run due to dependencies not being pinned at creation time.
    1. XBL is a proprietary technology developed by Mozilla

      Example of when "proprietary" is not an antonym of "open source".

    1. use-cases such as representing a 410 Gone deleted resource on static hosting that often disallow setting HTTP headers directly
  3. Aug 2022
    1. 1) get an extra 'search' attribute on to the <a> tag in HTML so that we have: e.g. <a href='...' search='...'>link text</a> 2) If there's take-up, then later on push for adding a date-time of creation attribute to <a>. This will add link history to the internet. The way (1) works is someone sticks the basic href to a page in the href attribute, and then sticks the text they want to link to in the search attr. The browser fetches the page, and as a secondary action (at user option) searches for the text.

      Another approach, inspired by the <label> element, would be to encode these selectors as separate <link> elements in the head. You could write your links as normal, and then add these <link rel="selector" for="foo" href="XXX[...]X" /> to your document (where foo is the ID of the <a> element, and the href value is selector).

    1. Documents may be retrieved by URL: by sending mail to listserv@info.cern.ch with a line containing the command SEND followed by the URL of the document

      Neat.

    1. If you refer to a particular place in a node, how does one follow it in a new version, if that place ceases to exist?

      The answer is: linking party pays. I.e., after 30-ish years of the Web put into practice, what has emerged is that it is the linking party's responsibility to ensure:

      • that the material remains available (by keeping a copy around, or arranging for the same thing by delegating to a third-party), and
      • there is some reliable way to establish provenance (which can be handled in tandem with delegation to same third-party, as with availability)

      These are only necessary if these two (availability and reputable provenance) are actually desirable properties. But in the event that one or the other or both is desired, the rule is that linking party pays.

    1. Linking by context In this case, the annotater refers to a part of the document by the context: for example, he quotes the first and last pieces. See for, example, the section "In this case...". This method is clearly heuristic and prone to failures just as is the automatic generation of differences above..

      This is the only realistic one—and the only way to reconcile the vast pre-Web corpus that is ostensibly meant to be ingested to occupy a first-class status on the Web.

      It still ~requires some amount of versioning (though not necessarily with the cooperation of the publisher, from whom it would be prudent to assume harbors a mildly adversarial outlook; cf Wayback Machine, Perma.cc, etc).

    2. The solution set is as follows: take your pick.

      It's almost like a pick two/impossible trinity.

      You can either have: - a resource that stays up-to-date (e.g. by a convenient URL that always points to the most recent revision, i.e. documents are mutable) - links that don't break

      You can't have both.

      If you choose the latter, your document can never change--not even to say the current version is out of date. This also means using unique ("versioned", you could say) URLs--one for every revision, with it only* being possible for later revisions to point to earlier ones, almost like a Git-like DAG.

      If you choose the former, you're gonna be breaking your links (and those of others, too).

      * The workaround would be to include in rev A (which predates rev B) a URL to a non-existent resource, and you preregister your commitment to deposit a document (rev B) there. Not possible in systems which rely on content hashes, but imminently doable under the norms of the way URLs get minted. (Still doesn't fix the problem of have a clean and up-to-date URL like /pricing or /about/team, though.)

    1. A disadvantage seemed to me to be that it is not obvious which words take one to particularly important new material, but I imagine that one could indicate that in the text.

      I don't understand this.

    2. A feature of Microcosm is that links are made using keywords in the following way. Within a certain region (for example, a set of documents), a keyword is connected to a particular destination. This means that a large number of links may be declared rapidly, and markup in the document itself is not needed.

      Presaging lightweight wikilinks? (Or at least WikiWords?)

    1. One might want to make a private annotation to something which is visible world-wide but unwritable. The annotation would be invisible to another reader
    1. In practice, a system in which different parts of the web have different capabilities cannot insist on bidirectional links. Imagine, for example the publisher of a large and famous book to which many people refer but who has no interest in maintaining his end of their links or indeed in knowing who has refered to the book.

      Why it's pointless to insist that links should have been bidirectional: it's unenforceable.

    1. Obnoxious.

      As someone recently pointed out on HN, it's very common nowadays to encounter the no-one-knows-else-what-they're-doing-here refrain as cover—I don't have to feel insecure about not understanding this because not only am I not alone, nobody else understands it either.

      Secondly, if your code is hard to understand regarding its use of this, then your code his hard to understand. this isn't super easy, but it's also not hard. Your code (or the code you're being made to wade into) probably just sucks. The this confusion is making you confront it, though, instead of letting it otherwise fly under the radar.* So fix it and stop going in for the low-effort, this-centric clapter.

      * Not claiming here that this is unique; there are allowed to be other things that work as the same sort of indicator.

    2. And by the way, if you ever do do anything good with it, it'll just become a cesspool of people posting Donald Trump memes and complaining about what movie didn't have the right people in it on Twitter. That's what your inventions will be used for, right? Not advancing humankind and producing some kind of good future for everybody.

      ... says the guy who has dedicated his life to video games.

      Previously: https://hypothes.is/a/tCHXEvj-Eey1N3dRiP4I4Q

    1. Best of all, there is no software to install, it just works from the Web!

      Nice property. It would be nice if HTML Tidy could do the same.

    1. This is the earliest known reference to HTML's class attribute that I've found in a public document so far: 1995 May 6 in draft spec 02 (i.e. the third revision) of the HTML 2.0 spec.

      This postdate's Håkon W Lie's original CSS proposal (from 1994 and which doesn't mention classes) and predates the first CSS draft specification (dated to 1995 May 31 in one place and which mention's HTML's ability to subclass in order to "increase the granularity of vcontrol" [sic]).

    1. To increase the granularity of vcontrol, HTML elements can be subclasssed

      The "subclassing" word choice here is interesting. It matches the model eventually suggested in HTML 3.x, but at the time of this draft, HTML was in a draft specification stage (third revision — "02") for HTML 2.0

      I'm interested in the discussion that led to this.

    1. It seems the Web is still in a primitive state of formation: loose bands of individuals hunting and gathering. I look forward to great nations in this new medium.

      You sure about that, Dan-from-25-years-ago?

    1. Especially if CouchDB were an integrated part of the browser

      It's always funny/interesting to read these not-quite-projections about overhyped tech from a far enough vantage point, but this sounds a little like what I've advocated for in the past, which is resurrecting Google Gears.

    1. Of the two, the html version is the one where I've spent a bunch of time trying to understand and improve the performance. In the dear imgui version I've done the easiest possible thing at every step and the performance is still fine.
    1. So what’s wrong with all the different languages? Nothing, if you enjoy the mental exercise of creating and/or learning new languages. But usually that’s all they are: a mental exercise.
    2. Editorial: The real reason I wanted Cmm to succeed: to democratize programming. It wouldn’t belong in any business plan, and I seldom mentioned to anyone, but the real reason I wanted Cmm to succeed was not about making money (although paying the mortgage was always important). The real reason was because of the feeling I had when I programmed a computer to perform work for me
    3. Another thing I’ll do when I’m King of the World is declare that executable code will always be inseparable from it’s source code. Using a script language solves that, of course, because a script is it’s source. For compiled code a second-best solution is the executable always contain pointers to where the source originated, but since that source may disappear the better solution is for language compilers to simply tack the original source code (and related make files and resources) onto the end of the executable in a way that can be commonly extracted. The law will be known as the “All boots shall contain their own bootstraps” decree.
    4. lack of a common powerful hi-level language available on every computer remains. You still cannot write a script file and send it to everyone and expect them to be able to run it without installing something first. The closest we probably have is HTML with JS embedded, since everyone has an HTML browser installed
    1. It's often a good idea to replace common primitives, such as strings, with appropriate value objects.
    1. You can use terribly slow scripting and techniques and get something working, not because the tooling is genius, but because the hardware is so incredibly fast.

      If the thesis is sound, then logically we should expect the instances where people have decided to "use terribly slow scripting and techniques" to produce better programs; the not-slow (non-"scripting") stuff to be worse.

      You can only pick one:

      • software is worse because hardware improvements mean that what were previously noticeable inefficiencies are no longer noticeable
      • programs that are written in low-level languages and don't as much incur runtime overheads are better on average because they're written in low-level languages that aren't as wasteful
    1. I think we can define an "archival virtual machine" specification that is efficient enough to be usable but simple enough that it never needs to be updated and is easy to implement on any platform; then we can compile our explorable explanations into binaries for that machine. Thenceforth we only need to write new implementations of the archival virtual machine platform as new platforms come along

      We have that. It's the Web platform. The hard part is getting people to admit this, and then getting them to actually stop acting counter to these interests. Sometimes that involves getting them to admit that their preferred software stack (and their devotion to it) is the problem, and it's not going to just fix itself.

      See also: Lorie and the UVC

    2. software collapse

      Is this not just a new name for what was already described in the 1960s as the "software crisis"?

    1. browsers aren’t magic! All the information browsers send to your backend is just HTTP requests. So if I copy all of the HTTP headers that my browser is sending, I think there’s literally no way for the backend to tell that the request isn’t sent by my browser and is actually being sent by a random Python program

      This calls for a perspective shift: that "random Python program" is your browser.

    1. And it’s like, no, no, you know? This is an adaptation thing. You know, computers are almost as old as television now, and we’re still treating them like, “ooh, mysterious technology thing.” And it’s like, no, no, no! Okay, we’re manipulating information. And everybody knows what information is. When you bleach out any technical stuff about computers, everybody understands the social dynamics of telling this person this and not telling that person that, and the kinds of decorum and how you comport yourself in public and so on and so forth. Everybody kind of understands how information works innately, but then you like you try it in the computer and they just go blank and you know, like 50 IQ points go out the window and they’re like, “doh, I don’t get it?” And it’s the same thing, it’s just mediated by a machine.
    1. :

      Notice with the line about Tom and Huck being boys, the bottom-up description sounds unnatural.

    2. or a not very significant change is made to an existing feature in a way which probably won’t cause anybody problems

      not what semver is actually about

    3. The git repositories for Inform
    1. his ostensible real life (which is actually staged)

      You accidentally a word.

    2. This piece would benefit from better editing—e.g. its use of pronouns with an unnatural (or too-far-away) antecedent, dubious phrasing like "all the more", etc.

    1. The more the reimplementation differs from the original authors’ code, the better it is as a verification aid
    2. the published journal article, or some supplementary material to that article, contains a precise enough human-readable description of the algorithms that a scientist competent in the field can write a new implementation from scratch
    1. The lack of CPU power in those days also meant there was deep skepticism about the performance of interpreters in general, and in the user interface in particular. Mention "interpreted language" and what sprung to mind was BASIC or UCSD Pascal, neither regarded as fast.

      still widely held today

    2. symmetric

      traditional compilation foils "symmetric authoring"

    1. I can't get behind the call to anger here, even if I don't approve of Apple's stance on being the gatekeeper for the software that runs on your phone.

      Elsewhere (in the comments by the author on HN), he or she writes:

      The biggest problem I try to convey is that you have no way of knowing you'll get the rejection

      No, I think there were pretty good odds that before even submitting the first iteration it would have been rejected, based purely on the concept alone. This is not an app. It's a set of pages—only implemented with the iOS SDK (and without any of the affordances, therefore, that you'd get if you were visiting in a Web browser. For whatever reason, the author both thought this was a good idea and didn't review the App Store guidelines and decided to proceed anyway.

      Then comes the part where Apple sends the rejection and tells the author that it's no different from a Web page and doesn't belong on the App Store.

      Here's where the problem lies: at the point where you're - getting rejections, and then - trying to add arbitrary complexity to the non-app for no reason other than to try to get around the rejection

      ... that's the point where you know you're wasting your time, if it wasn't already clear before—and, once again, it should have been. This is a series of Web pages. It belongs on the Web. (Or dumped into a ZIP and passed around via email.) It is not an app.

      The author in the same HN comment says to another user:

      So you, like me, wasted probably days (if not weeks) to create a fully functional app, spent much of that time on user-facing functions that you would have probably not needed

      In other words, the author is solely responsible for wasting his or her own time.

      To top it off, they finish their HN comment with this lament:

      It's not like on Android where you can just share an APK with your friends.

      Yeah. Know what else allows you to "just" share your work...? (No APK required, even!)

      Suppose you were taking classes and wanted to know the rubric and midterm schedule. Only rather than pointing you to the appropriate course Web page or sharing a PDF or Word document with that information, the professor tells you to download an executable which you are expected to run on your computer and which will paint that information on the screen. You (and everyone else) would hate them—and you wouldn't be wrong to.

      I'm actually baffled why an experienced iOS developer is surprised by any of the events that unfolded here.

    1. Not to dispute "deathanatos"'s (presumably) thorough refutation, and although the Wat behavior remains the default for compatibility reasons, but most of these problems are fixed with a single pragma.

    1. The JS that is being run is essentially IE6 or IE5-level, so none of the modern features introduced in IE8

      Odd way to describe it! You could easily have said "Chrome 1.0" or "Firefox 1.x-level" (or even "Firefox 2.x" or "Firefox 3"), since JS didn't really change between 2000 and 2010. (ECMAScript 5 was standardized in 2009 but not bene, that's December 2009. IE 8 didn't introduce ES5, and it definitely wasn't available in IE at the tail end of the year. Full ES5 compliance didn't even really show up in browser until 2012-ish, not even Chrome—the one browser that had short release periods at the time.)

    1. Corollary: Spolsky (at least at the time of this article) didn't really understand types, having about the same grasp on computing fundamentals as your average C programmer.

    1. It should be dead simple to distribute content (eg. static content).It should be easy to build apps.It should be not too hard to build a platform.

      The thing that gets me about takes like this is that it's all the stuff below the Web content layer that accounts for what makes all this stuff harder than it needs to be.

      What's the hard part about distributing content (static or not, but let's go with static for simplicity)? It's registering a domain, updating DNS, and keeping a Web server up—all systems that have nothing to do with the "infernal" trio and also generally programmed in what are typically described as saner languages and their traditions. It's either that, or it's relying on somebody else, like GitHub Pages, and integrating the implementation details/design decisions for their value-add into your workflow.

      To "build a platform" is ambiguous, but it sounds a lot like "creating a server-side application to serve non-static content and handle associated requests". Is the infernal trio to blame for the difficulties of that, too?

    1. Dynamic typing makes that harder

      So run a typechecker on the code to check your work if you want type checking. That is what TypeScript does, after all. And it's been around long enough that people shouldn't be making the mistake that a runtime that support dynamic types at runtime means that you can't use a static typechecker at "compile time" (i.e. while the code is still on the developer workstation).

    2. The point is to write bug-free code.

      With this comment, the anti-JS position is becoming increasingly untenable. The author earlier suggested C as an alternative. So their contention is that it's easier to write bug-free code in C than it is in JS. This is silly.

      C hackers like Fabrice Bellard don't choose C for the things they do because it's easier to write bug-free code in C.

    1. If you’re still worried, do note that the Space Telescope Science Institute’s document mentions that the script processor itself is written in C++, which is known for being... well, the type of language you’d want to use if you were programming a spacecraft.

      The author might as well have written, "I have no idea what I'm talking about and rely on pattern matching based on social cues I have observed."

    2. written in arcane code that you’d have to recompile

      What is the relationship between "arcane code" and "code that you'd have to recompile"?

    3. therefore likely less error-prone
    4. what’s the point of going with web-like scripts instead of more traditional code

      Where does it say they're "going with web-like scripts"? (And what is "more traditional code"?)

    1. Usually the philosophy is akin to turning an antique coffee-grinder into the base for a lamp: it's there, so why not find a way to put it to some use.
    1. Bob Nystrom used something like this while writing Crafting Interpreters. He wrote a post about its bespoke build system.

      https://journal.stuffwithstuff.com/2020/04/05/crafting-crafting-interpreters/

    1. This became a serious practical issue as version control was adopted as a tool for collaboration, with members of a team communicating through commit messages. Git therefore introduced the approach of “rewriting history”.

      I'm not sure that the narrative implied by these statements is accurate.

    2. this basic wisdom was lost with the adoption of computers. Computers make it very easy to modify information, to the point that version control had to be invented to prevent massive information loss by careless editing.
    3. Since facts and narratives live in different universes, we should avoid mixing them carelessly. Crossing the boundary between the two universes should always be explicit. A narrative should not include copies of pieces of facts, but references to locations in a fact universe. And facts should not refer to narratives at all.
    1. I add mass to each of these… mental clusters? planetary bodies in the Mindscape? by hyperlinking the phrase as I type.

      Nothing particular to what's described here, but this gives me an idea for a design of an efficient IME that doesn't require manually adding the brackets or even starting with an a priori intention of linking when you begin writing the to-be-linked phrase. The idea is that you start typing something, realize you want to link it, and then do so—from the keyboard, without having to go back and insert the open brackets—at least not with ordinary text editing commands. Here's how it goes:

      Suppose you begin typing "I want to go to Mars someday", but after you type "Mars", you realize you want to link "go to Mars", as this example shows. The idea is that, with your cursor positioned just after "Mars", you invoke a key sequence, use Vim-inspired keys b and w (or h and l for finer movements) to select the appropriate number of words back from your current position, and then complete the action by pressing Enter.

      This should work really well here and reasonably well in the freeform editor originally envisioned for w2g/graph.global.

    1. The linear structure of a notebook that forces the narrative to follow the order of the computation.

      I disagree that this is harmful. Striving to linearize things has payoffs. The resistance to doing so, on the other hand, is definitely what I would call harmful (to "communication", as the author put it, esp.).

      Have you ever delivered (or witnessed) a lecture in non-linear time? You can't. Because you can't help but grapple with the inherent linearity arising from the base substrate of our existence, eventually.

    1. It comes to the conclusion that the closest existing approximation to a good platform is the Java virtual machine.

      That's probably not a bad conclusion—if you insert the phrase "one of" before "the closest". (And there's no bias fueling my agreement; I don't work with the JVM).

      For my bet, the Web platform is still the better option, though, and it has to do not just with its current ubiquity, but the factors that have led to that ubiquity, including versatility and relative ease of implementation (cf Kling et al).

    2. we need to think about what the required platform is for each variety of canned computation

      Yes! This is essential. Ask, "What does this probably actually require?"

    3. The fundamental problem is that VirtualBox emulates arcane details of PC hardware in order to work with existing operating systems, and then the installed operating system recognizes that arcane hardware and installs drivers etc. that rely on it. That means we have to emulate the same arcane hardware 20 years from now just to be able to boot the old virtual system.

      in other words, it captures too many irrelevant details whose effect sums to null (and in the best case should be replaced by NOP).

    4. See also DSHR on preservation, along with Rothenberg and Lorie (independently).

    5. around in 10 years
    6. no matter how ill-adapted it is to our needs

      I dunno. I think the common argument that the Web was not intended to be an application delivery platform is both (a) ignorant of basic facts in subtle ways that are materially relevant to the particular use case described here and (b) poorly applied to this use case, given those particulars.

      I don't like most traditional Web apps or what passes for best practices in the contemporary culture. I don't write them, and I'm not defending them.

      But we're talking about scientific literature here. I'll dispute the general argument as it applies to the specific use case under discussion by pointing out that a document-centric platform is in fact exactly the correct tool for the job in this case. The only thing that could be better is if you were able to write your paper more or less as you ordinarily do for journal publication and then feed the journal article into a machine able to comprehend the methods at a deep level and then simulate what it describes. We don't have that, though. But we can to author documents that are a little more explicit instead. This is not a terrible consolation prize. So we really should start seizing the benefits of the current circumstances, lest the Web platform actually turn into something unsuited for this. (Which, perversely, is most likely to happen as a result of pursuing the vision of making it more suited for traditional software development.)

      Again—by all means, don't compile to asm.js (or WASM, or from TypeScript, etc.). Put it to use on its strengths and in the spirit of its original vision.

    7. perhaps we will end up compiling our software to asm.js and run in the browser

      Better yet, not compiling to asm.js at all. Just WYGIWYG (What You've Got Is What You Give [Me, Too]).

    8. Note however that it’s not “any of today’s virtual machine managers”

      I agree. And this very reason (along with the complexity, mentioned in the following paragraph) is what should disqualify VirtualBox.

      The virtual machine manager you should use is the one you assumed would be available when you published this post (and that you were correct about, and that I am using right now to read it): the Web browser.

    9. For the 2013 Web platform, you may hope that its sheer popularity will motivate someone to keep it alive, but I wouldn’t bet on it either. The Web platform is too complex and too ill-defined to be kept alive reliably when no one uses it in daily life any more.

      There's some sleight of hand here, which treats "when no one uses it in daily life anymore" as a given. That (folks continuing to use it) is the stability of the Web platform.

      Besides, even if we suppose that people have stopped using it (dubious), the entirety of what constitutes "the 2013 Web platform" is not necessary—only the parts that are actually used for computation and I/O. That's much smaller.

    10. if you want to use an archived copy of a 2013 Web site, you need the 2013 Web platform

      Fortunately, the 2013 platform is a subset of the later one.

    1. we can’t know what trivial change to the environment might stop the experiment working, or (worse) make it appear to work but actually have a major change in it

      "can't is too strong a word here"

    2. The more I think about it, the less I think there is a meaningful definition of the one true run time. I have put significant effort into making sure that runtimes are consistent but, however we do this, it makes our experiments less realistic. With rare exceptions (perhaps some safety critical systems) our algorithms will not be used in highly controlled situations, moderated to reduce variability between runs or to maximise speed of this particular process. Algorithms will be run as part of a larger system, in a computer sometimes with many other processes and sometimes with few and, because of the way that computing has developed, sometimes in raw silicon and sometimes in virtual machines. So the more I think about it, the more I think that what matters is the distribution of run times. For this, your experiment on your hardware is important, but so are future recomputations on a wide variety of VMs running on a variety of different hardware.

      The truth of this has consequences not just for the metaissue of recomputation, but the entire raison d'etre of doing performance studies to begin with.

    3. If I can’t run your experiment at all, then I can’t reproduce your times.
    4. We are not asking people to send us VMs, but to send us what they think we need to get the experiment to run. This is usually a few megabytes of code and maybe executables. Assuming we can run it in a standard environment, we can make our own VM without one ever being sent to us.

      X for thee, not for me

    5. Code you make available today can be built with only minor pain by many people on current computers
    6. Before running it you need two free tools, Vagrant and Virtual Box.

      This kills the crab.

    7. There has been significant pressure for scientists to make their code open, but this is not enough. Even if I hired the only postdoc who can get the code to work, she might have forgotten the exact details of how an experiment was run. Or she might not know about a critical dependency on an obsolete version of a library.
    1. Other examples of tech stacks that are very stable are C, C++, and Fortran.

      Category error; C, C++, and Fortran are programming languages, not tech stacks.

    1. the reason a lot of studies are made of these price and volume variables is that now, in the age of computers, there are almost endless data available about them. It isn’t necessarily because such studies have any utility; it’s simply that the data are there and academicians have worked hard to learn the mathematical skills needed to manipulate them. Once these skills are acquired, it seems sinful not to use them, even if the usage has no utility or negative utility.

      Applicable as criticism for: - marketing analytics for "data-driven" campaigns - the sort of resume-driven development that is fashionable on Github - naive code reuse, generally

    1. In a world where all scientifically relevant information is stored in stable and well-defined open file formats, software tools can evolve much more freely without disturbing ongoing work or harming reproducibility.

      Good formulation! All scientifically relevant information—this demands that the programs themselves be "stored in stable and well-defined open file formats". This is precisely what is missing (both the mindset and the practice).

      I suspect, though, that the author themself has missed this and is thinking of the "software environments" (that he later refers to in this conclusion) as being outside this purview. But it need not (and should not) be.

    2. David Cournape made the interesting observation that no technology less than 20 years old is better than Python in terms of stability.

      Not true. The standardized Web platform is not just more stable than Python, it's probably one of the most stable platforms in existence. It just moves (read: improves) slowly.*

      Most people don't recognize this, because they pack the stable, standardized parts all in the same mental bag as the shiny, non-standardized parts (like Flash, for an example of decades past, or experimental vendor-specific stuff for a more evergreen problem), then end up getting bit in a similar way and blaming the environment rather than communal tendencies towards recklessness.

      It also turns out that the Web's original academic underpinnings are deeply aligned with the goals of researchers looking for a way to work together—even if the final puzzle piece (ECMA-262) didn't come into existence until later in the decade when the Web first appeared. It's still old enough that it passes the litmus test proposed here.

      * for good reason; after all, look at the evidence

    3. Every beginner-level tutorial for scientists should state during the first five minutes that you cannot expect stability and that you should either use Python only for throw-away code or else
    4. My conclusion: the scientific computing community—and many Python programmers, generally—have done themselves a disservice by standardizing on Python. The problems that have been shown to arise here and in similar cases comes down to an impedance mismatch between what these programmers want Python to be and what Python actually is.

      Another insight comes from observing the way in which folks from the affected group have tended to approach the problem—wading in with a sort of undisciplined, YOLO mindset and then thrashing when they've gotten in over the heads because it turns out that a lack of discipline permeates the actions of everyone else, too—which includes, crucially, those they look for to be disciplined so that there's something that can be relied upon.

      Food for thought: although I'm not a Java programmer it's not hard to see that had they standardized instead on the JVM (doesn't necessarily have to be Java—could be a Python lookalike), then this would have almost certainly served them better here on the matter of stability and had the nice benefit of sidestepping the performance issues that Python is known for.

    5. The technical solutions proposed all depend on yet more infrastructure whose longevity is uncertain.

      The "every problem in computing can be solved with another layer of hacks" school of thought.

    1. Finally, in anticipation of an argument that I expect to see, let me stress that this is not a technical issue. Computing technology moves at a fast pace, but that doesn’t mean that lack of stability is a fatality. My last Fortran code, published in 1994, still works without changing a single line. Banks have been running Cobol code unchanged for decades. Today’s Java implementations will run the very first Java code from 1995 without changes, and even much faster thanks to JIT technology. This last example also shows that stability is not in contradiction with progress. You can have both if that’s a design goal. It’s all a matter of policy, not technology.
    2. What is not OK is what I perceive as the dominant attitude today: sell SciPy as a great easy-to-use tool for all scientists, and then, when people get bitten by breaking changes, tell them that it’s their fault for not having a solid maintenance plan for their code.
    3. coding-intensive research

      This is still not the best way to put it. Decisions come at the expense of writing code. This maintenance work is something else.

    4. the poor reproducibility of Python-based computer-aided research
    1. What I find surprising in the frequent heated debates is that the nature of the type system is rarely even discussed. People talk about static vs. dynamic types as if there were only one static and one dynamic type system.

      Good point.

      We can go further. Suppose I have a project written in TypeScript, and your affinity for TypeScript is well-known. Only—surprise!—I'm actually using TypeScript 1.x from n years ago. Are you still happy?

    2. The closest technology I am aware of in this space is F# type providers
    3. every computation on a modern computing system is actually a staged computation, with reproducibility of the last stage (the one we most care about) requires the reproducibility of all prior stages

      This is not strictly true, but it's not the worst thing in the world to pretend that it is.

    1. explicit documentation of both the execution environment used to run the software and all requirements and dependencies of systems, software, and libraries should be clearly noted in the code and/or readme file (Benureau and Rougier 2018). While time passing can make software obsolete, it also fades the memories of researchers. For that reason alone, it is important to annotate source code to explain the intended operations, which supports reproducibility for the original research team while also supporting future reusers (Benureau and Rougier 2018)
    1. An ActivePaper is, by defini-tion, a package combining the code, data, and documentationthat describe together a computational scientific study.
    2. today’s notebook implementations require note-book authors to take various precautions to ensure repro-ducibility, which are exactly the same as required for makingscripts reproducible: a detailed documentation of the soft-ware environment that was used, listing all dependencieswith detailed version information
    3. A recent study [25]of more than a million notebooks in public GitHub reposito-ries found many indicators of poor quality, some of whichsupport earlier criticisms of notebooks encouraging bad soft-ware engineering habits
    1. C, Fortran, BLAS, and Unix
    2. over the seven years of the project, I ended upspending a lot of time catching up with dependencies. Newreleases of NumPy and matplotlib made my code collapse,and the increasing complexity of Python installations addedanother dose of instability. When I got a new computer in2013 and installed the then-current versions of everything,some of my scripts no longer worked and, worse, oneof them produced different results. Since then, softwarecollapse has become an increasingly serious issue for mywork. NumPy 1.9 caused the collapse of my MolecularModelling Toolkit, and it seems hardly worth doing muchabout it because the upcoming end of support for Python 2in 2020 will be the final death blow.
    3. perhaps the mostfrequent motivation for adding dependencies in layer-3 soft-ware is the desire to write less code oneself
    4. Accept that your construction is short-lived. In caseof collapse, start from scratch

      This seems to be the position adopted by many developers. More than is reasonable. #3 and #4 probably account for most developers.

    5. a blog post
    6. There is a good chance that you have never heard ofsoftware collapse before, for the simple reason that it’s aterm I have made up myself two years ago in a blog post.
    1. What I call software collapse is what is more commonly referred to as software rot: the fact that software stops working eventually if is not actively maintained. The rot/maintenance metaphor is not appropriate in my opinion because it blames the phenomenon on the wrong part. Software does not disintegrate with time. It stops working because the foundations on which it was built start to move.
    1. The “work around” was to detect users in an IAB and display a message on first navigation attempt to prompt them to click the “open in browser” button early.

      That's a pretty deficient workaround, given the obvious downsides. A more robust workaround would be to make the cart stateless, as far as the server is concerned, for non-logged-in users; don't depend on cookies. A page request instead amounts to a request for the form that has this and this and this pre-selected ("in the cart"). Like with paper.

    1. Roughly stated, my overarching career mission is to design, build, and deploy software platforms that put end users in control of their computing and data, in part by making it easy and natural for programmers to create software that honors user desire.
    1. The idea here is to emulate the hardware platform WordPerfect ran on

      That seems like unnecessarily tight coupling. Surely there's a better level of abstraction that's higher than "emulate the hardware platform".

    1. We also see the usual conceit of totalizing systems like Microsoft Word: plain ASCII text files are accepted, as input files, but only “for compatibility reasons”. Ugh.

      Huh?

    2. in Oberon (as in Python, but very much not as in C or Pascal) a character is a string of length 1

      nope

    1. I can't possibly keep updating software to deal with new JavaScript versions

      There's a fundamental misunderstanding (alternatively, misdirection) about what the source of breakage is. JS is not an SDK, and neither is the Web platform. Whatever worked in the old "JavaScript version" will work in the new one.

    1. A complete description on implementing eventhe simple IMGUI would take too much space. Iinvite you instead to watch Casey’s video lecturemirrored on my web site, and look at the samplecode I’ve posted. I’d like to thank Casey Muratori, JonathanBlow, and Atman Binstock for feedback on thisarticle, some of which you can read on Casey’sweb site forum.
    2. a “global variable” which identifies whichwidget is active
    3. Instead, we simplydescribe them from scratch every frame, whichdoesn’t actually result in more code. It’s more likewe run the “create” code every frame.

      Now imagine, as a performance optimization, a lib where you can write in IMGUI style, so you write the same amount of code, but behind the scenes, the lib is managing things, so it's actually free to do all the retained mode heavy lifting.

      We just invented declarative programming.

    4. This is less efficient than the previousapproach, but it’s less likely to have bugs.If we have CPU speed to spare, we can get rid ofall the bugs.

      Interesting remarks, given the Muratori school on profligate misuse of computing resources by modern developers.

    5. Game Developer. September 2005.

    Tags

    Annotators

    1. This describes one of the most pleasing hacks I've ever come across. I just now tracked it down and added it to my bookmarks. (Not sure why it wasn't already there.)

      You could also conceive of going one step further. When your app (doesn't actually have to be a game, though admittedly it's much easier for you if it is) is compiled with tweak.h, it gives it the power to paint the source file on the screen—so you don't actually have to switch over to your text editor to save it, etc. Suppose you want to provide custom inputs like Bret Victor-style sliders for numeric values. You could edit it in your text editor, or you could derp around with it in-app. Tweaking the value in-app should of course both update it wrt the app runtime but also still write the file to disk, too, so if live reloading is turned on in your text editor, whatever changes you make inside the live process image gets synced out.

  4. scattered-thoughts.net scattered-thoughts.net
    1. I like to organize all the state in a program so that it's reachable from some root pointer. This makes it easy for the reader to understand all the resources allocated by the program by just following the tree of types. It also makes it easy to find any piece of state from within a debugger, or to write little debugging helpers that eg check global invariants or print queue lengths.
    1. I've gotten to where "if I can't make sense of it and be productive in it with just vim, grep, and find, your code is too complex".

      See Too DRY - The Grep Test.

      But even allowing for grep is too lax, in my view. It's too high a cost. If I've got some file open and am looking at some Identifier X, I should be able to both deterministically and easily figure out exactly which file X lives in.

      Violating this is what sucks about C's text-pasting anti-module system, and it's annoying that Go's "package" system ends up causing similar problems. I shouldn't have to have a whole-project view. I should be able to just follow my nose.

    1. Maybe that’s why Wordpress has always struggled so much with building any kind of network effect

      I think it is the beneficiary of a network effect—it's just driven by a professional class, and not end users.

    1. and free of globals

      Ah! This remark highlights a fundamental difference in understanding between two camps, which I have been (painfully) aware of, but the source of this confusion has eluded me until only just right now. (Really, this is a source of frustration going back years.)

      In one camp, the advice "don't use global variables" is a way of attacking a bunch of things endemic to their use, most notably unnecessary coupling to spooky state. In another camp "no global variables" is understood to mean literally that and taken no further—so you can have as much spookiness as you like, and so long as the value is not directly accessible (visible) from, say, another given piece of code appearing at the top-level ("global") context, as with the way i is bound to the activation record in this example but is not accessible outside the scope of getGetNext, then you're good.

      That is, there are two aspects to variables: visibility and extent, and the first interpretation seeks to avoid the negative effects on both dimensions, while the second is satisfied by narrowly prohibiting direct visibility across boundaries.

      I find the latter interpretation bizarre and completely at odds with the spirit of the exhortation for avoiding globals in the first place.

      (What's worse is the the second interpretation usually goes hand in hand with the practice of making extensive use of closures, which because they are propped up as being closely associated with functions, then leads people to regretfully refer to this style as functional programming. This is a grave error—and, to repeat, totally at odds with the spirit of the thing.)

    1. I don't like bloat and the JavaScript fuelled Win98-isation of the web. Therefore I tend to write very spartan webpages. This one for example is generated from a lightweight markup format that I created, and uses only the P and A elements.
      • The Web has suffered bloating
      • This page, therefore, is simple:
      • All that's involved here is a de novo language that was created in such a way that this page has to be generated from a separate, canonical source file written in that format

      This is silly set of statements to make in series.

      Just make the published form of this document the canonical representation—treat it as suitable for reading and editing alike (since it is).

    1. I avoided using languages that I don't know how to bootstrap like node.js

      There's a weird (read: "weirdly obvious") category error here. NodeJS is not a language. (This wouldn't be so notable if the comment didn't go on to say "The key point is writing to an interface and not an implementation.")

      The puzzle piece that fits the shape of the hole here is "JS". JS is the language, NodeJS is one of its implementations—and chubot knew both of these things already, so it's odd that it was expressed this way. Plus, there's a lot more diversity of JS implementations than exist for e.g. Python...

    2. IMO avoiding things like CommonMark and Python will just make your site worse right now

      I don't see how avoiding Python "will just make your site worse"—whether right now, or ever. Is there supposed to be something inevitable about Python?

    1. Its account of how Heft made his flag closely resembled the standard story, but instead of any assertion that it became the basis for the official design, it merely said that it was “considered Lancaster’s first.”

      I'm having trouble parsing this.

    1. I basically think of it as an "executable README". A README or blog post often contains shell commands. So I just copy those into a script.

      Suppose that instead of shell commands, the snippets were JS, and the README, rather than being named README.markdown or README.txt, were actually named e.g. README.txt.htm. it wouldn't be basically like an executable README—it would actually be executable. You could double click it to open, and then read through it and use it to actually do the stuff that the README is documenting (like build the project in question).

    1. they're called objects, and everybody has them

      Even most ostensible FP practitioners who swear they don't.

  5. gbracha.blogspot.com gbracha.blogspot.com
    1. Static variables are bad for re-entrancy. Code that accesses such state is not re-entrant. It is all too easy to produce such code. Case in point: javac. Originally conceived as a batch compiler, javac had to undergo extensive reconstructive surgery to make it suitable for use in IDEs. A major problem was that one could not create multiple instances of the compiler to be used by different parts of an IDE, because javac had significant static state.

      Walter Bright described similar issues with the Digital Mars compiler in a recent NWCPP talk "Adding Modules to C in 10 Lines of Code", albeit Walter's compiler sounds like it was far easier to fix.

      It's funny that this happens with compilers. Wirth's Oberon compiler (module ORP) also depends on static state. But compilers seem natural to me to be something that you want to allow multiple instances of—it's not even among the list of things I'd expect people to make excuses for (cf https://kentonshouse.com/singletons).

    1. There are no static variables and no initialization
    2. Since the original Pascal was implemented with a one-pass compiler, the language believes strongly in declaration before use.  In particular, procedures and functions must be declared (body and all) before they are used.  The result is that a typical Pascal program reads from the bottom up - all the procedures and functions are displayed before any of the code that calls them, at all levels.  This is essentially opposite to the order in which the functions are designed and used.

      Worth noting that almost every C program is impaired by a similar limitation in the C language (despite the disclaimer that follows this passage about the use of the preproccessor), and many programmers' thought processes suffer because of it—no consideration for the presentability of code (even when not in languages that are affected by this limitation!)

    1. JavaScript Tips

      This is a 404.

    2. see {{bug(442099, “bug”, 19)}}

      That's bug 442099, comment 19, i.e. trying to substantiate the opinionated claim that "an operator at the front" is better for human factors.

    3. In JavaScript, == is preferred to ===.
    1. And second it was not immediately visible in a program text, where an imported identifier was declared.

      The problem of multiple import forms plagues ECMAScript today. Additionally the lack of "immediate" visibility of "where an imported identifier was declared" continues to plague Golang, to an extent even worse than described here for Modula-2 (because at least when you're iteratively jumping through the file with naive text search, you'll eventually reach the Modula-2 import statement, even though it involves wrapping around after reaching the bottom). It's explicit at some point. With Golang, on the other hand, having not been sufficiently wounded by the problems of C, the team designed it such that it has magical name resolution, making it tedious to carry out (as a human) the process that the compiler uses.

    2. identifiers may now appear that are neither locally declared, nor qualified by a module name, nor visible in an import list; an entirely undesirable situation in a structured language

    Annotators

    1. I've been perusing codetriage.com/ this morning and most projects are essentially for the benefit of other developers.

      This is the dirty secret of the neo-OSS era—that it's mostly devops shovelware (to a degree that makes it look like Sturgeon was being conservative)

    1. The effort got him accolades and commit access to the Rails repo.

      But having commit access and the having ability to fiddle with bugs are two orthogonal sets of privileges...

    2. The creator of CodeTriage, Richard Schneeman, was surprised to learn one day that the Ruby on Rails core team (of about 7 or so people) were responsible for handling ALL the issues opened on the Rails GitHub repo. At the time, there were about 700 or so issues. These maintainers are hugely valuable to the project due to their depth of knowledge, however keeping up with issues was taking a huge amount of time. Would you rather these highly specialized maintainers spend their time developing new features and actually fix bugs, or would you want them to spend their days responding to hundreds of issues? Asking for simple questions like "what version of Rails are you using?", and "can you provide an example app?", and "is this fixed on master?”. While asking these questions might only take 5 or 10 minutes of time, the sheer volume of issues per maintainer was unreasonable. This was highlighted by the herculean efforts of another developer Steve Klabnik, who went through every single issue and responded to all of them in a marathon session spanning multiple days. The effort got him accolades and commit access to the Rails repo. While he deserves the praise, the efforts were ultimately unsustainable.

      Surprise: going all in on GitHub—including abandoning traditional practices governing bugtrackers in favor of GitHub's anemic project management tools—has a negative impact.