mst

In perl, you can do

    use Some::Library v1.2.3;

and there's assorted tooling that will turn that into some sort of[0] centralised dependency spec that installers can consume.

Also e.g. https://p3rl.org/lib::xi will automatically install deps as it hits them, and the JS https://bun.sh/ runtime does similar natively (though I habitually use 'bun install <thing>' to get a package.json and a node_modules/ tree ... which may be inertia on my part).

Th e perl use is a pure >= thing though, whereas I believe raku (née perl6) has

    use Some::Raku::Library v1.*.*;

and similar but I'm really not at all an expert there.

[0] it's perl so there's more than one although META.json and cpanfile are both supported by pretty much everything I recall caring about in the past N years

If you're doing something something reasonably small, using preact rather than react and then wrapping it into a web component so you can just ... put it in there ... is a really nice option to have.

(it may not be the right option in any given case, but it's worth knowing it's there even so)

I don't think you could fit it to Go, no.

But see https://hackage.haskell.org/package/effectful for work in the general area that seems rather promising.

Reminded of back in '02 or so when the networking spods at $ISP would just install everything off every Red Hat Linux 9 CD when they built a machine so they "didn't have to worry about anything being missing."

Those were the only *n?x boxen at the place that I did my best to avoid touching. It was ... I don't recall that it ever caused a problem (a buggy RH kernel that made fork() only work statistically did once, but that was orthogonal) but it just bothered me as a matter of principle.

They're basically dynamic scoping and it's both a very useful and powerful and very dangerous feature ... scheme's dynamic-wind model makes it more obvious when the particular form of magic is in use but isn't otherwise a lot different.

I would like to think that somebody better at type systems than me could provide a way to encode it into one that doesn't require typing out the dynamic names and types on every single function but can instead infer them based on what other functions are being called therein, but even assuming you had that I'm not sure how much of the (very real) issues you describe it would ameliorate.

I think for golang the answer is probably "no, that sort of powerful but dangerous feature is not what we're going for here" ... and yet when used sufficiently sparingly in other languages, I've found it incredibly helpful.

Trade-offs all the way down as ever.

If the form is basically raw CRUD then it works out well, and being able to get up and running quickly and replace it with something more sophisticated later when you actually need that is a good thing.

It does require the discipline to actually _do_ the 'replace it' part when you reach that point and the results of failing to do that are ... not pleasant ... but that doesn't mean it's _always_ the wrong choice, especially when getting started.

The NHS is far from perfect (and was already far from perfect before the Tories spent a decade and a half making it worse) but given you -can- get private health insurance in the UK if you want it, IMO it's best to judge the NHS as 'universal basic healthcare' and accept that at that scale it's always going to suck sometimes but it's still better to have access to such a thing than not.

I know ariadne well enough that I'm pretty confident that the headline will have been chosen out of annoyance rather than click maximisation.

That doesn't mean I agree with the conclusion (I am ambivalent and would have to think rather more before having an opinion myself) but I'm reasonably sure of the motivation nonetheless.

C++ is the clear winner in what portability is possible.

But as they outlined, in a lot of cases achieving it is substantially more effort per arch+OS+version target than Rust.

Getting a better ROI on your time is a valid reason to consider something better for your use cases.

I would guess they're hoping that it'll get in front of some potential customers and augment their primarily word-of-mouth marketing strategy as a result.

I did appreciate that the "hired a car" story included a comment of "and this is worth doing because it gets us customers," the lack of pretense there was nice.

I was reading it thinking "their PR firm is earning its fees."

I enjoyed the article anyway, but still.

(every time there's a freakout on rightard twitter about "you will eat the bugs" the article about insect protein that triggered it pretty much always includes a reference to a company that closed a funding round not long ago - I am honestly impressed that their respective PR companies managed to get basically the same story published so many times)

You would likely be better with, say, Ian Hislop for me in terms of sarcasm, though while he's definitely a wit, no matter how hard I try I only ever seem to get half way.

Those are all claims about the accent (my understanding of said claims is basically "sounds reasonable but also I have no idea what I'm talking about").

I was more thinking about the words/grammar/idiom etc.

(also as a Lancastrian I find e.g. Deep Somerset barely comprehensible, especially when the speaker is a few pints in, but their wording is still usually closer to mine than the USians' is)

We Have Always Been At War With Eurasia.

I think because people are 'watching' in a situation where twenty years ago they'd've put the radio on but now they default to 'fire something up on Netflix' and so Netflix wants to make things amenable to those customers.

I'm not sure how I feel about this, but it does at least make sense in terms of why Netflix are doing so.

Being English-as-in-UK I often run into situations where my dry/sarcastic humour completely fails to be clear to USians.

Then again from the UK POV the leftpondians barely count as native English speakers anyway ;)

Egan would probably be my first thought of somebody who could take a concept like that and make something well worth reading out of it.

Second thought would probably be Derek Künsken. (no claim he's necessarily the second best option but he's definitely the second author I've read recently enough to have the name of in brain cache to come to mind as "could almost certainly pull it off")

Kindle Edition: £2.99

Sounds like at least £2.99's worth of fun to me from the blurb, so it's now queued up.

I swear I'll get to it eventually.

... honest.

This somehow reminds me of Egyptian mathematics where they refused to admit to the existence of any fraction with a numerator other than 1 (except for 2/3).

Learning how to expand e.g. 3/7 into 1/n + 1/m + ... using their methods was a fascinating experience.

I wouldn't want to suffer under such constraints day to day but it was one of the most memorable parts of the History of Mathematics course I took alongside what was other a mostly pure maths degree.

There's a parallel here with modern applications perl as compared to the crawling horrors people perpetrated in CGI scripts during the dot com boom.

Also present day javascript (the language; the ecosystem is another matter ;) compared to the 'var' and IIFEs-for-scoping era.

Also requires, which initially looks batshit insane but is in fact really quite cool: https://www.think-cell.com/en/career/devblog/if-constexpr-re...

> I think the author just finds C++ fun for some complex combination of personal factors, which is fine. Perhaps partly due to a "hacker" type personality.

I think that sums up the point of the article just fine.

To me at least, it's not so much that it's confused as that it's him being excited about having fun and doing his best to share his joy. Which means that, sure, it's not a proper essay at all, it's not really trying to convince you to agree so much as saying "if you find this relatable without me trying to actively convince you, maybe you'd find it fun too."

I think given you've been mugged by reality in commercial work to the point of tiredness, your not finding it to make sense at all is completely understandable, though.

I'm currently having a blast writing javascript of all things, and I imagine if I wrote up a similar blog post explaining why it'd come across just as badly to somebody burned out on the last decade of commercial javascript too.

But I'm glad he's having fun, and I'm glad he decided to share the joy.

I really like that book. A bunch of people I've mentioned it to said there was nothing in there that was new to them and they thought it was a waste of time.

I fear they missed the vocabulary part, which was what I found most valuable.

Having that shape become more important to a civilisation than the circle because it has something to do with the geometry of hyperspace seems like it could be an interesting conceit for a sci-fi setting.

TS would require you to have attrs typed as object|null rather than object before you even got to that line if you wanted to be able to pass a null value to the function/whatever.

It wouldn't complain about the ... usage itself because ...null is well defined and therefore not a type error.

(it would I think complain about trying to apply ... to something that isn't allowed, though I don't recall making that particular mistake yet in TS code to find out)

Though also, trivial example is trivial - I was looking for the simplest thing that was valid code and let me illustrate the general concept.

> Despite this, please use volatile anyway! When I do not see volatile it’s likely a defect. Stopping to consider if it’s this special case slows understanding and impedes code review.

There are quite a few things I reflexively write where I know that in the specific case I don't actually need to do that, but also know that it'll make the code easier to skim read later.

I hate having my skimming interrupted by "is this the case where this is safe?" type situations.

One can, of course, overdo it - and to what extent it's worth doing it depends on who you expect to be reading it - but it can often be quite handy.

A concrete example:

    this.attrs = { style: {}, ...attrs }

will work fine if the 'attrs' variable is null, because ...<null> is not an error in javascript and expands to nothing ... but I'll still often write

    this.attrs = { style: {}, ...(attrs??{}) }

instead because it makes it clear that the code is allowing the null case deliberately and because it means the person reading it doesn't have to remember that the null case would've worked anyway (and also because my brain finds it weird that the null case does work so it often makes me pause even though I well know it's fine once I stop and think for a second).

Slight oddities converting it into a one-liner but here's a copy and paste from a shell session running in my local WSL slice:

  demeisen=; perl -e 'my $in_fh = (defined $ARGV[0] and $ARGV[0] ne "-") ? do { open my $fh, "<", $ARGV[0] or die "Failed to open $ARGV[0]: $!"; $fh } : \*STDIN; print "Line: ".<$in_fh>;'
  HELLO
  Line: HELLO
  demeisen=; perl -e 'my $in_fh = (defined $ARGV[0] and $ARGV[0] ne "-") ? do { open my $fh, "<", $ARGV[0] or die "Failed to open $ARGV[0]: $!"; $fh } : \*STDIN; print "Line: ".<$in_fh>;' -
  HELLO
  Line: HELLO
  demeisen=; echo 'HI' >tmp/hi  
  demeisen=; perl -e 'my $in_fh = (defined $ARGV[0] and $ARGV[0] ne "-") ? do { open my $fh, "<", $ARGV[0] or die "Failed to open $ARGV[0]: $!"; $fh } : \*STDIN; print "Line: ".<$in_fh>;' tmp/hi
  Line: HI
  demeisen=;

See if Ctrl-[ works.

I tend to hit that instead of Esc everywhere I'm using a vi-like after having a weird keyboard issue that nerfed my Esc key for a while (long and uninteresting story) and then finding that Ctrl-[ was more comfortable for me anyway.

(of course that may not work at all in the lambda editor, I'm mostly using it in terminals with heirloom-ex-vi, but seems easy enough to TIAS some time)

I can't cope with python because of the lack of 'use strict' - I continue to be sad that 'explicit is better than implicit' is supposed to be a rule of python except apparently not for variable declarations (also I want block based lexical scoping damnit).

With the addition of 'let' - which to my brain is just "how javascript decided to spell 'my'" - I'm actually really quite enjoying it.

(and the javascript proposal for 'match' is written expecting the proposal for 'do BLOCK' to happen, and 'do BLOCK' is going to make me a _very_ happy mst)

Plain perl:

  open my $fh, '<', $filename or die "Couldn't open ${filename}: $!";

Nicer:

  use File::Open qw(fopen);
  ...
  my $fh = fopen $filename;

(and File::Open is simple pure perl code so if I need to distribute the script to random machines I throw App::FatPacker at it to produce a bundled version)