• 5 Posts
  • 622 Comments
Joined 3 years ago
cake
Cake day: July 14th, 2023

help-circle


  • Patching a library is fine if you’re building a final executable — something where you know what the final dependency graph looks like ahead of time.

    It’s not fine if you’re building a library. You don’t know if a consumer will also want to use an unpatched version of that library, and depending on the scenario that could result in duplicated instances (each with their own internal state), failure to build or load, or mismatches in data layout or function definitions.

    I would avoid using a library like that if I could.

    Of course, sometimes the person who can make that decision is the creator of npm itself, and says “No I don’t believe I will”: https://github.com/isaacs/jackspeak/issues/20









  • I agree with Prime on most things, but I think he’s getting this one wrong.

    There are more options than just “light-hearted satire” and “earnest business idea”.

    The FOSDEM talk is silly, and reads like a skit, but it has a gravely serious undertone.

    The security guy has posted on Twitter “I still can’t believe he hooked it up to Stripe lol”.

    Meanwhile the LinkedIn of the other guy describes him as a “researcher of political economy of FOSS” at Rochester Institute of Technology, and he runs a non-profit about FOSS for humanitarian aid.

    He’s also been very active replying to people talking about the conference talk or the Malus site, asking whether they think this should be legal and what we can do to protect the future of open source.

    I think these are people who take this threat very seriously, and are willing to expose themselves to litigation in order to force the issue into courts.








  • JS for sure.

    It has a reputation among programmers as being a bit of a mess, but I think the reasons behind that reputation are largely irrelevant to your use case.

    Basically:

    1. It has some bad decisions about basic stuff, like truthiness, equality, coercion. But those aren’t major stumbling blocks, really. When they run into those situations, they’ll probably already be aware that they’re trying something weird and won’t have the same already-developed intuition about “how it should work” that many of us are bringing to the table.
    2. Production deployment can easily turn into a Rube Goldberg machine. I think this is mostly what the kneejerk “really? JS?” response is about. Different ES versions, module systems, WASM, dependency hell, transpilers on top of transpilers, and a billion different runtimes. And the fact that everyone and their grandma apparently wants to build a custom DSL on top of JS that requires additional transpiler plugins or codegen steps. But your students won’t have to worry about that shit. Just pick one environment and do that. Maybe warn them that stackoverflow might use different syntax (require vs import) or try to import stuff that doesn’t exist in their environment though.