mst

Given the intent to have relatively straightforward C code and a tiny runtime, you pretty much have to ditch them or you're not going to get anywhere at all.

Plus honestly most of the uses of continuations that would make sense in the sort of relatively low level code this is aimed at can be built out of a few special purpose macros (and possibly a small amount of crying) - scheme code tends to lean on first class continuations for a lot of things that don't really need them, Because It Can.

e.g. Paul Graham's On Lisp shows how to build (a subset of) continuations out of macros, and getting something like clojure's 'recur' out of that would probably give you simpler macros than pg's code uses.

I think that generally refactoring attempts have either failed or simply ended up bolting a bypass on the side that only helps somewhat, and most of the rest of the articles on the same site as the submission we're discussing contain at least one example thereof.

Nonetheless, I largely agree with your metaphor(s) as a projection of how a bunch of things are depressingly likely to go wrong in the short term.

PLATO based lessons seem to have helped as an augment to normal style education.

I don't think revolutionize is particularly on the horizon, but "doesn't really work" really depends on what you're defining your success condition to be.

It's fantastic - I read very little book length non-fiction (because I largely read books in bed to relax, 10k+ word essays or entire documentation sites are a different matter), but it was gripping, thoughtful, beautiful, and so, so much worth it.

It made enough of an impression on a subset of the users that I believe the free-to-access cyber1 system is still going and has (just) enough people on it to retain some of the social aspects.

Yes, although -

My bull case is not that I particularly like their reforms, but that they demonstrate that substantive rather than incremental changes are possible at all.

Also perhaps that they rip out things that are supposedly doing something useful but sufficiently terrible at it they're not meaningfully helping, such that somebody not-them can later at least attempt to introduce a replacement that does.

Or: The vetocracy problem is very much real and reducing that could, in the medium to long term, be a huge win on net even if the things they do having reduced it in the short term are absolutely not the kind I would like to see either.

I opened the devtools to narrow the page.

Given how much more aggravation I go through getting lots of sites that _do_ have formatting to contort into a shape I find comfortable to read, I found it hard to mind much.

foo, bar, baz, quux, fleem ... then I get stuck.

Well, more usually, then I ask myself wtf I'm doing that needs that many metasyntactic variables and try and figure out an approach that doesn't.

(I have no idea whatsoever where I got fleem from anymore)

I tend to start off a project with typeless zero-build JS, because I've been working with dynamic languages so long that the types mostly don't actually help me find bugs in the early days, but if I don't convert it to reasonably typed TS before I release a 0.001.001 then I would expect people to judge me for it, and I would consider them to have every right to do so.

Much of it is such minimal translation.

Much, not so much.

I see JSX as basically 'compiling augmented javascript to javascript,' much of decorators is much like that as well, and things like e.g. vue's turning expressions on its reactivity based signals seen in templates into something more clever is also in the category I was trying to gesture at.

(TS is awesome but I should've predeclared that it wasn't really what I had in mind, sorry for any confusion induced by that mistake on my part)

Right, even the most opinionated of modern formatters don't go quite that far.

The only thing I can think of that did is the Interlisp-D editing functionality provided by Interlisp Medley, where your code was stored within the system as parsed S-expr trees and when you opened an editor onto something it reverse engineered a textual expression of the thing according to your configuration.

Tagging every, single, node, with enough data to recreate the indentation and formatting seems theoretically doable, and if you're wanting to let people edit things that are, say, config file shaped, then you're going to have to do that if you want the resulting commit diffs to be sufficiently coherent that people will be willing to use it.

But taking the Medley approach for a first attempt/first release feels a lot more doable, and given the biggest obstacle to such a thing is almost certainly congruent to "being able to make a start over a weekend for the sheer fun of it" I think it's well worth considering :D

Having poked around https://evenrealities.com a bit: Yes.

Not sure I can convince myself to spend the money to find out, but they're definitely going in the direction I was thinking of.

Ta.

The systems *I* currently have at hetzner are, so far as I'm aware, on a "we don't charge for bandwidth but if you use a shitload you'll get throttled for the rest of the month" plan just like my ovh boxen.

But I only pull dedis from hetzner; my VPSen are all ovh based. So please nobody expect my experience to generalise without triple checking the terms just like I did in the process of signing up for those systems.

I keep my whois and NS entries elsewhere and my nameservers sufficiently distributed that I find the risk acceptable, but both hetzner and ovh are firmly in the "I have always felt I got a very cost effective 'exactly what I paid for' - and in the case of my rare interactions with their support more than I'd hoped for" category for me.

Neither has ever caused me a problem that didn't feel like "potentially having this level of problem occasionally is entirely in keeping with how little I'm paying" basically.

Some people are wired to find disrespectful complaints and unconstructive criticism genuinely upsetting (which is unfortunate in a bunch of ways, but OTOH the same personality traits often also make for somebody who's fantastic at handholding polite newbies through learning something).

I am excellent at finding such things either hilarious or grounds to say "well, if you're going to be like that, I can't say I care about your opinion, piss off" and moving on to the next complaint in the hopes I can get useful feedback out of that one.

But there's a fair swathe of newbies where I have to step back and let other people help them instead, because if I try I'll end up accidentally driving them off and feeling like a dickhead afterwards :D

(I have tried and failed repeatedly at "Not Being a Bastard," so I've settled for leveling up in "Being a Self Aware Bastard" instead; at least that reduces how often I end up causing *un*intentional offence ;)

I *really* wanted basically "google class without the frigging camera."

Being able to overlay an 80x24 terminal over one of my eyes (and drive it with a bluetooth keyboard or whatever) would've been fantastic for me.

Unfortunately for me, this is enough of an outlier desire that it doesn't seem likely anybody will ever want to sell me that at a price point I can convince myself of.

People tend to vastly underestimate how much the time needed for a new hire to come up to speed costs the employer.

This is true even of (theoretically simple) things like retail jobs, because even if you're proficient in the basic skill set on day one, coming up to speed on the rhythm of a specific workplace still takes time.

I'm buggered if I can remember where I saw it, but there was a study once that showed that (in that specific instance, I have no clue as to whether or not it generalises) a minimum wage increase actually *saved* retail/service employers in the area money overall, just because the reduced churn meant that over the lifetime of an employee with the company the fact that said lifetime was longer meant they were getting enough more value per hour out of each employee to more than compensate for the higher cost per hour.

Of course the study could always have been wrong, but it didn't seem obviously so back when I looked at it and it at the very least seems plausible to me.

> Proper preservation of where every folded token came from for byte-perfect reconstruction of the original code.

I wonder if you could cheat by insisting the original code must have been run through an opinionated formatter so there's a One True Represenation of the source and you can restrict the problem to byte-perfect reconstruction of -that-?

(I have the same dream too sometimes and keep wondering if that would, at least, be a more tractable goal for a version 0.1 if I ever get a round tuit)

I can't immediately find it but somebody once said something like "on a long enough timeline, all languages become CommonLispScript with different syntax" and there's definitely some truth to that.

What I find truly fascinating is that given the complexity of most build systems (especially ones that use babel) basically every node project I encounter is in fact effectively transpiled, it's just it's "javascript compiled to javascript" rather than having a different source syntax.

I don't even mind[0], I think it's actually kind of amazing.

[0] I have all the usual complaints about build systems and about the node ecosystem in general, but I don't think the fact that it's javascript compiled to javascript in and of itself is a problem, only, well, almost everything about how that's usually implemented/achieved :D

This is explicitly for software that's made an active choice to not guarantee 100% compatibility between successive releases, so that outcome is a feature.

I don't think I agree.

Part of the point is that this is for "rolling release" type software, so always implying there *could* be breaking changes is a reasonable approach - kind of a versioning equivalent of defensive programming.

Another comment elsethread notes that they call this out as a deliberate choice in the FAQ.

I've always been fond of blaming myself and asking everybody else to help make sure I don't cock it up a second time - when it works out I get lots of help, lots of useful feedback, and everybody else feels good about putting the effort in.

This does require management who won't punish you for recording it as your fault, though. I've been fairly lucky in that regard.

The article reads to me as pretty explicitly saying that the only real takeaway wrt k8s itself is "it was the wrong choice for us and then we compounded that wrong choice by making more wrong choices in how we implemented it."

"I am cutting this corner because I absolutely cannot make a business case I believe in for doing it the hard (but more correct) way but believe me I am still going to be low key paranoid about it indefinitely" is an experience that I think a lot of us can relate to.

I've actually asked for a task to be reassigned to somebody else before now on the grounds that I knew it deserved to be done the simple way but could not for the life of me bring myself to implement that.

(the trick is to find a colleague with a task you *can* do that they hate more and arrange a mutually beneficial swap)

Yeah, my hopes have the caveat of "this requires regulations to catch up to where technology is at rather than making everything worse" and in addition to my generally low opinion of politicians (the ones I've voted for absolutely included) there's a serious risk of a "boomers versus technology" incident spannering it even if everything else goes right ... but I can still *hope* even if I can see a number of possible futures where said hopes will turn out to be in vain.

Huh.

Genuinely nice to know EA circles are involving/including people who aren't already sufficiently steeped in the origin/history/context/whatever of the movement to find jargon like 'ratadj' as obvious as I thought it was when I originally typed it.

(and it was jargon and I've just edited this comment because my original phrasing almost certainly read as condescending in a way that was absolutely not why I was meaning to say; mea culpa and my apologies to anybody who read the first version)

This does quite seriously strike me as an excellent sign for its sustainability and while, yes, EA has a whole buuunch of weirdness to/around it, I'm unconvinced you could've got a first generation of something like EA without being tolerant of the people who brought the weirdness, so:

Cool!

Thanks. Should've spelled that out in the first place.

Too used to kicking around with people where it's a basically standard term (not always one used *positively* depending on which group of people, but I forgot it's not always clear).

I was under the impression that playwright was (a very good) how your code behaves when actually running in a browser testing library, and vitest was a how your code behaves on its own testing library.

But I'd tend to have relatively independent test suites for my frontend model/state layer and the "how it behaves live in a browser" stuff because that way if I'm not currently iterating on my view components I can test the rest of my frontend code changes without having to faff with headless browser instances.

(obviously you'd then want to run both before committing, and again under CI before merge, but still)

Depending on how thin your model/state layer is (and if you have a Sufficiently Rich Backend then it can probably be very thin without that being an issue) your situation may not match mine, of course.

But y'know, free data point, worth exactly what you paid :D

Circular dependencies almost always end up causing trouble *eventually* because the body of one of the modules involved has to be evaluated first (when the other participants in the cycle aren't a fully operational battlestation yet).

I've used p3rl.org/circular::require on perl projects before now to root out such dependencies and kill them with fire, and "figure out how to get equivalent technology in TS/JS codebases" is on my list of things to do.

Fundamentally, a circular dependency that currently (apparently) "works everywhere" should still be treated as an unexploded footbomb.

Excising them can absolutely be annoying and inconvenient, but IME not nearly as much as having the damn thing go off when a future maintainer makes an innocuous change an indeterminate amount of time later.

tl;dr: HUMBUG (and sorry I don't have a better answer yet)

There are organisations like the Software Freedom Conservancy who, even if they themselves can't help, can probably help you try and find somebody who can.

I'm not suggesting any particular maintainer *should* decide to fight, or even consider whether they want to try - that's very much up to them - but assuming that fighting is untenable in advance without exploring options is something I'd consider an unnecessarily unfortunate outcome.