34 Matching Annotations
  1. Dec 2022
    1. programs with type errors must still be specified to have a well-defined semantics

      Use this to explain why Bernhardt's JS wat (or, really, folks' gut reaction to what they're seeing) is misleading.

  2. Nov 2022
    1. unused classes

      again: unmatched class selectors

      additionally, it's not the fact that they are unmatched (or that they are class selectors specifically) that it's a problem—it's the fact that there are a lot of them

      the entire choice of focusing on classes and class selectors here is basically a red herring

    1. That's a whole different topic. Mastodon isn't built for single-user instances.

      That's the entire topic, my guy!

      "We should be optimising Mastodon so it incentivises more serve[r]s with fewer people." is the very premise of the conversation!

      Mastodon "push[ing] the direction of the protocol or make it harder to cultivate an ecosystem of smaller ones."? "it needs to be easier to start smaller ones"? Are you just not paying attention to the conversations you're responding to?

      Reminds me of:

      What fascinated me was that, with every single issue we discussed, we went around in a similar circle — and Kurt didn’t seem to see any problem with this, just so long as the number of 2SAT clauses that he had to resolve to get a contradiction was large enough.

      https://scottaaronson.blog/?p=232

    1. layers of wat are essentially hacks to build something resembling a UI toolkit on top of a document markup language

      So make your application document-driven (i.e. actually RESTful).

      It's interesting that we have Web forms and that we call them that and yet very few people seem to have grokked the significance of the term and connected it to, you know, actual forms—that you fill out on paper and hand over to someone to process, etc. The "application" lies in that latter part—the process; it is not the visual representation of any on-screen controls. So start with something like that, and then build a specialized user agent for it if you can (and if you want to). If you find that you can't? No big deal! It's not what the Web was meant for.

    1. I have a suspicion that you're not putting the source for the specific versions of glibc and Linux you used into every one of your projects.

      Why are people so seduced by this dumb argument—to the point that they almost seem proud of it?

      First, it's presumptuous. Who says we're even using glibc instead of some other libc—which I just might choose to include in the projects I work on? Who says we're even using Linux, for that matter?

      Secondly, even if we were, let's assume that we're not, and then see if that teaches us anything about the overall line of reasoning. The original comment was about NPM. NPM is used a fair bit for not just backend stuff but for managing packages used in the browser, too. Let's assume, for simplicity, that our program is entirely a browser-based JS+HTML+CSS app with no backend to speak of. Would the same people argue that, among other things, the Web browser sources would need to be included? Does it even make sense to argue that? Asking the system software question betrays a failure to accurately grapple with the classes of software artifacts we're dealing with, their role in the overall project, and our responsibility for them.

  3. Oct 2022
    1. This shifts the responsibility of checking which posts are new new/updated onto the parser

      For checking which posts are new/updated, this is always the case. The only thing the HTTP cache-related headers can tell is that the feed itself has/hasn't changed.

    1. That's an interesting point about empirical testing. If you just ask lawyers and judges in the abstract whether they'd like citations up in the body or down in footnotes, they'll vote for the former. But if you show them actual examples of well-written opinions in which the citations are subordinated, the results are very different.
    1. In the past whenwe attempted to share it, we foundourselves spending more time gettingoutsiders up to speed than on our ownresearch. So I finally had to establishthe policy that we will not provide thesource code outside the group
  4. Sep 2022
    1. 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.

    2. 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"...

  5. Aug 2022
    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. 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. 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).

    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. 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...

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

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

  6. Jul 2022
    1. Yes, it’s making it easier than ever to write code collaboratively in the browser with zero configuration and setup. That’s amazing! I’m a HUGE believer in this mission.

      Until those things go away.

      A case study: DuckDuckHack used Codio, which "worked" until DDG decided to call it a wrap on accepting outside contributions. DDG stopped paying for Codio, and because of that, there was no longer an easy way to replicate the development environment—the DuckDuckHack repos remained available (still do), but you can't pop over into Codio and play around with it. Furthermore, because Codio had been functioning as a sort of crutch to paper over the shortcomings in the onboarding/startup process for DuckDuckHack, there was never any pressure to make sure that contributors could easily get up and running without access to a Codio-based development environment.

      It's interesting that, no matter how many times cloud-based Web IDEs have been attempted and failed to displace traditional, local development, people keep getting suckered into it, despite the history of observable downsides.

      What's also interesting is the conflation of two things:

      1. software that works by treating the Web browser as a ubiquitous, reliable interpreter (in a way that neither /usr/local/bin/node nor /usr/bin/python3 are reliably ubiquitous)—NB: and running locally, just like Node or Python (or go build or make run or...)—and

      2. the idea that development toolchains aiming for "zero configuration and setup" should defer to and depend upon the continued operation of third-party servers

      That is, even though the Web browser is an attractive target for its consistency (in behavior and availability), most Web IDE advocates aren't actually leveraging its benefits—they still end up targeting (e.g.) /usr/local/bin/node and /usr/local/python3—except the executables in question are expected to run on some server(s) instead of the contributor's own machine. These browser-based IDEs aren't so browser-based after all, since they're just shelling out to some non-browser process (over RPC over HTTP). The "World Wide Wruntime" is relegated to merely interpreting the code for a thin client that handles its half of the transactions to/from said remote processes, which end up handling the bulk of the computing (even if that computing isn't heavyweight and/or the client code on its own is full of bloat, owing to the modern trends in Web design).

      It's sort of crazy how common it is to encounter this "mental slippery slope": "We can lean on the Web browser, since it's available everywhere!" → "That involves offloading it to the cloud (because that's how you 'do' stuff for the browser, right?)".

      So: want to see an actual boom in collaborative development spurred by zero-configuration dev environments? The prescription is straightforward: make all these tools truly run in the browser. The experience we should all be shooting for resemble something like this: Step 1: clone the repo Step 2: double click README.html Step 3: you're off to the races—because project upstream has given you all the tools you need to nurture your desire to contribute

      You can also watch this space for more examples of the need for an alternative take on working to actually manage to achieve the promise of increased collaboration through friction-free (or at least friction-reduced) development: * https://hypothes.is/search?q=%22the+repo+is+the+IDE%22 * https://hypothes.is/search?q=%22builds+and+burdens%22

  7. Jun 2022
    1. you get so used to the way things are you don't think of the obvious next step and you know that can be so frustrating
  8. May 2022
    1. I think adding automated deployments would be a nice quality-of-life feature and would definitely encourage me to write more. Currently, I have to upload a new text file to my server and refresh the pm2 job.

      Is "automated deployments" really the solution?

    1. That said, I've since realized I was wrong of course. Trying to maintain projects that haven't been touched in more than a year led to hours of fixing dependency issues.
    1. Linux (and Wine) may prove to be an alternative here.

      If what we're discussing here is the decision to no longer opt in to playing along with the "Western" regime for IP, then why would they limit themselves to Linux and Wine—two products of attempts to play by the rules of the now-deprioritized regime? Why wouldn't they react by shamelessly embracing "pirated" forms of the (Windows) systems that they clearly have a revealed preference for? If hackability is the issue*, then that's ameliorated by the fact that NT/2000 source code and XP source code was leaked awhile ago—again: the only thing stopping anyone from embracing those before was a willingness to play along and recognize that some game states are unreachable when (artificially) restricting one's own options to things that are considered legal moves. But that's not important anymore, right?

      * i.e. malleability, and it's not obvious that it should be—it wasn't already, so what does this change?

    1. State exact versions and checksums of all deps plus run your own server hosting the deps

      In other words, do a lot of work to route around the problems introduced by the way that using npm routes around your existing version control system.

    1. all the exception handling these packages do

      These packages don't/can't do the amount of exception handling suggested by this comment.

    1. The events list is created with JS, yes. But that's the only thing on the whole site (~25 pages) that works that way.Here's another site I maintain this way where the events list is plain HTML: https://www.kingfisherband.com

      There's an unnecessary dichotomy here between uses JS and page is served as HTML. There's a middle ground, where the JS can do the same thing that it does now, but it only does so at edit time—in the post author's own browser, but not in others'. Once the post author is ready to publish an update, the client-side generated content is captured as plain HTML, and then they upload that. It still "uses JS", but crucially it doesn't require the visitor to have their browser do it (and for it to be repeated N times, once per page visit)...

  9. Apr 2022
    1. I'm not sure what $name is

      This post is filled with programming/debugging missteps that are the result of nothing other than overlooking what's already right in front of the person who's writing.

  10. small-tech.org small-tech.org
    1. Ongoing research Building on our work with Site.js, we’ve begun working on two interrelated tools: NodeKit The successor to Site.js, NodeKit brings back the original ease of buildless web development to a modern stack based on Node.js that includes a superset of Svelte called NodeScript, JSDB, automatic TLS support, WebSockets, and more.

      "How much of your love of chocolate has to do with your designs for life that are informed by your religious creed? Is it incidental or essential?"

    1. Interestingly, though, expertise appears to influence persuasion only if the individual is identified as an expert before they communicate their message. Research has found that when a person is told the source is an expert after listening to the message, this new information does not increase the person’s likelihood of believing the message.
    1. So far it works great. I can now execute my bookmarklets from Twitter, Facebook, Google, and anywhere else, including all https:// "secure" websites.

      In addition to the note above about this being susceptible to sites that deny execution of inline scripts, this also isn't really solving the problem. At this point, these are effectively GreaseMonkey scripts (not bookmarklets), except initialized in a really roundabout way...

  11. Mar 2022
    1. it's usually due to the misapplication of healthy open source principles

      The effect of handling open source the way it's popularly practiced on GitHub does not get nearly enough scrutiny for its role in e.g. maintainer burnout. Pretty much every project I see on GitHub does things that are obviously bad—or at least it should be obvious*—and neither are they sustainable, nor even a particularly good way to try to get work done, assuming that that's your imperative. It is probably the case, however, that that assumption is a bad one.

      * I've slowly come to realize and accept that this stuff is not obvious to lots of people, because it's all they know—whether that means that that should affect whether its negative consequences are obvious is something that I'm inclined heavily to argue that "no, it shouldn't affect it; it should still be obvious that it's bad even then", but empirically, it seems that my instinct is wrong.

  12. Jan 2022
    1. it’s insecure unless the credentials are served over an encrypted HTTPS connection

      The same is true for login systems that use cookies, but no one cites that as a downside. There's an asymmetric standard being applied to HTTP native authentication.

  13. Aug 2021
    1. you interpret the past as "the present, but cruder"

      Like people who can't wrap their head around the idea that evolution has nothing to do with any kind of purpose to produce humans. (Even starting from the position that humans are the "end result" is fundamentally flawed.)

  14. Jul 2021
    1. PDFs used to be large, and although they are still larger thanequivalent HTML, they are still an order of magnitude smaller than thetorrent of JavaScript sewage pumped down to your browser by mostsites

      It was only 6 days ago that an effective takedown of this type of argument was hoisted to the top of the discussion on HN:

      This latter error leads people into thinking the characteristics of an individual group member are reflective of the group as a whole, so "When someone in my tribe does something bad, they're not really in my tribe (No True Scotsman / it's a false flag)" whereas "When someone in the other tribe does something bad, that proves that everyone in that tribe deserves to be punished".

      and:

      I'm pretty sure the combination of those two is 90% of the "cyclists don't obey the law" meme. When a cyclist breaks the law they make the whole out-group look bad, but a driver who breaks the law is just "one bad driver."¶ The other 10% is confirmation bias.

      https://news.ycombinator.com/item?id=27816612

  15. May 2020