EastLondonCoder

A few concrete mechanisms that made this work (happy to expand):

  * “Host layer”: greeting newcomers + making it safe to arrive alone mattered more than we expected.
  * Curation as governance: coherent music changes how people behave in the room.
  * Offline outreach outperformed posting: visiting local businesses in person built trust faster than Instagram.
  * Scale changes the social physics; we stayed small on purpose.

Curious if anyone here has built local repeatable formats (meetups, reading groups, hackerspaces), what made them stick?

This frames escalation as if it’s an inevitable byproduct of “not cooperating,” but that’s a choice. Sanctuary policies generally limit voluntary local participation (e.g., detainers without judicial warrants), they don’t “block” federal enforcement.

“If you don’t want door-to-door, cooperate” is basically saying federal agencies get to punish jurisdictions for lawful policy choices by switching to more coercive tactics. That’s not normal enforcement; it’s politicized leverage. And once you normalize that logic, it won’t stay confined to immigration.

[flagged]

“Optics” is the wrong frame: this is about legitimacy and consent. A referendum demanded by outsiders under pressure is just coercion with a procedural costume. Imagine Cuba proposing a referendum on Puerto Rico joining Cuba and calling it “bad optics” if people won’t play along, the absurdity is the premise, not the lack of voting.

Not American. Also: reputational damage isn’t a skin that sheds when a government changes; allies and markets adapt structurally.

This isn’t really about Greenland’s strategic value; it’s about the category error. You can trade goods, sign treaties, and negotiate basing rights. You can’t “buy” a people or their sovereignty especially when they don’t consent. That’s why Europe responds with process and principle: normalize coercion-as-bargaining among allies and you’re reviving a pre-1945 model of politics Europe built institutions to prevent.

It’s also lose-lose for the US. There isn’t a positive outcome. If it’s dropped, the damage is “just” reputational and partly repairable. If it’s pursued: tariffs, threats, coercion. It burns trust inside NATO, accelerates European strategic decoupling, and hands a propaganda gift to every US adversary. A forced takeover would be a catastrophic own-goal: legitimacy crisis, sanctions/retaliation, and a long-term security headache the US doesn’t need.

And the deeper issue is credibility. The dollar’s reserve status and US financial leverage rest on the assumption that the US is broadly predictable and rule-bound. When you start treating allies like extractive targets, you’re not “winning” you’re encouraging everyone to build workarounds. Part of the postwar setup was that Europe outsourced a lot of hard security while the US underwrote the system; if the US turns that security guarantee into leverage against allies, you should expect Europe to reprice the relationship and invest accordingly.

The least-bad outcome is a face-saving off-ramp and dropping the whole line of inquiry. Nothing good comes from keeping it on the table.

Staff-level frontend/system engineer based in Sweden. 20+ years experience shipping performance-critical, real-time, and composable interfaces in production. Previous work includes:

• Custom poker clients and in-house game engines (Gamesys, OpenBet)

• Embedded media platforms (Xperi/TiVo smart TVs)

• Large-scale e-commerce widgets (Stylitics, tens of millions of daily hits)

• LLM-assisted pipelines and tooling (CMS ingestion, visual diffing, media automation)

Strengths include UI architecture, latency-aware design, composable systems, fast iteration, and taking projects from prototype to production with minimal overhead.

Stack/tools: React, TypeScript, Web Components, Canvas/WebGL, ClojureScript Tauri, SQLite, Payload CMS, ffmpeg, Cloudflare Workers GitHub Actions, Playwright, Codex-based AI workflows

Recent personal projects:

• Socken : local-first genealogy tool (Tauri + SQLite + GEDCOM)

• Kolibri Club : cultural site with CMS, ingestion pipeline, and live video workflows

• grabfilm : Filmarkivet + Archive.org media archiver with idempotent metadata handling

Looking for small, focused teams working on tools, infrastructure, creative software, or low-latency systems. Open to consulting, contracting, or embedded long-term roles. Prefer high agency, low management overhead, and no hype-driven development.

Contact: jonatan.wallgren@gmail.com Site: https://www.kolibrinkpg.com

I’ve ended up with a workflow that lines up pretty closely with the guidance/oversight framing in the article, but with one extra separation that’s been critical for me.

I’m working on a fairly messy ingestion pipeline (Instagram exports → thumbnails → grouped “posts” → frontend rendering). The data is inconsistent, partially undocumented, and correctness is only visible once you actually look at the rendered output. That makes it a bad fit for naïve one-shotting.

What’s worked is splitting responsibility very explicitly:

• Human (me): judge correctness against reality. I look at the data, the UI, and say things like “these six media files must collapse into one post”, “stories should not appear in this mode”, “timestamps are wrong”. This part is non-negotiably human.

• LLM as planner/architect: translate those judgments into invariants and constraints (“group by export container, never flatten before grouping”, “IG mode must only consider media/posts/*”, “fallback must never yield empty output”). This model is reasoning about structure, not typing code.

• LLM as implementor (Codex-style): receives a very boring, very explicit prompt derived from the plan. Exact files, exact functions, no interpretation, no design freedom. Its job is mechanical execution.

Crucially, I don’t ask the same model to both decide what should change and how to change it. When I do, rework explodes, especially in pipelines where the ground truth lives outside the code (real data + rendered output).

This also mirrors something the article hints at but doesn’t fully spell out: the codebase isn’t just context, it’s a contract. Once the planner layer encodes the rules, the implementor can one-shot surprisingly large changes because it’s no longer guessing intent.

The challenges are mostly around discipline:

• You have to resist letting the implementor improvise.

• You have to keep plans small and concrete.

• You still need guardrails (build-time checks, sanity logs) because mistakes are silent otherwise.

But when it works, it scales much better than long conversational prompts. It feels less like “pair programming with an AI” and more like supervising a very fast, very literal junior engineer who never gets tired, which, in practice, is exactly what these tools are good at.

That’s deliberate. “Correct” implies anchoring to a truth function the model doesn’t have. “Plausible” is what it’s actually optimising for, and the disconnect between the two is where most of the surprises (and pitfalls) show up.

As someone else put it well: what an LLM does is confabulate stories. Some of them just happen to be true.

I think of it like improvising with a very skilled but slightly alien musician.

If you just hand it a chord chart, it’ll follow the structure. But if you understand the kinds of patterns it tends to favour, the statistical shapes it moves through, you can start composing with it, not just prompting it.

That’s where Gärdenfors helped me reframe things. The model isn’t retrieving facts. It’s traversing a conceptual space. Once you stop expecting grounded truth and start tracking coherence, internal consistency, narrative stability, you get a much better sense of where it’s likely to go off course.

It reminds me of salespeople who speak fluently without being aligned with the underlying subject. Everything sounds plausible, but something’s off. LLMs do that too. You can learn to spot the mismatch, but it takes practice, a bit like learning to jam. You stop reading notes and start listening for shape.

I’ve been using GPT-4o and now 5.2 pretty much daily, mostly for creative and technical work. What helped me get more out of it was to stop thinking of it as a chatbot or knowledge engine, and instead try to model how it actually works on a structural level.

The closest parallel I’ve found is Peter Gärdenfors’ work on conceptual spaces, where meaning isn’t symbolic but geometric. Fedorenko’s research on predictive sequencing in the brain fits too. In both cases, the idea is that language follows a trajectory through a shaped mental space, and that’s basically what GPT is doing. It doesn’t know anything, but it generates plausible paths through a statistical terrain built from our own language use.

So when it “hallucinates”, that’s not a bug so much as a result of the system not being grounded. It’s doing what it was designed to do: complete the next step in a pattern. Sometimes that’s wildly useful. Sometimes it’s nonsense. The trick is knowing which is which.

What’s weird is that once you internalise this, you can work with it as a kind of improvisational system. If you stay in the loop, challenge it, steer it, it feels more like a collaborator than a tool.

That’s how I use it anyway. Not as a source of truth, but as a way of moving through ideas faster.

I’m with the people pushing back on the “confidence scores” framing, but I think the deeper issue is that we’re still stuck in the wrong mental model.

It’s tempting to think of a language model as a shallow search engine that happens to output text, but that metaphor doesn’t actually match what’s happening under the hood. A model doesn’t “know” facts or measure uncertainty in a Bayesian sense. All it really does is traverse a high‑dimensional statistical manifold of language usage, trying to produce the most plausible continuation.

That’s why a confidence number that looks sensible can still be as made up as the underlying output, because both are just sequences of tokens tied to trained patterns, not anchored truth values. If you want truth, you want something that couples probability distributions to real world evidence sources and flags when it doesn’t have enough grounding to answer, ideally with explicit uncertainty, not hand‑waviness.

People talk about hallucination like it’s a bug that can be patched at the surface level. I think it’s actually a feature of the architecture we’re using: generating plausible continuations by design. You have to change the shape of the model or augment it with tooling that directly references verified knowledge sources before you get reliability that matters.

System developer with 20+ years of experience building performant, component-based UIs and real-time systems. I enjoy functional programming and use functional techniques daily for clarity and composability. Recent work includes the TiVo smart TV platform at Xperi/Vewd, a JavaScript game engine at Gamesys, and Clojure/ClojureScript applications at Stylitics.

Location: Norrköping, Sweden

Remote: Yes

Willing to relocate: Within Sweden

Technologies: JavaScript, TypeScript, React, Node.js, Clojure, ClojureScript, SQL, HTML/CSS, Git, Docker, Linux

Résumé/CV: https://www.linkedin.com/in/jonatanwallgren

Email: jonatan.wallgren@gmail.com

I agree that the explicit timeline you get with immutability is certainly helpful, but I also think its much easier to understand the total state of a program. When an imperative program runs you almost always have to reproduce a bug in order to understate the state that caused it, fairly often in Clojure you can actually deduct whats happening.

After a 2 year Clojure stint I find it very hard to explain the clarity that comes with immutability for programmers used to trigger effects with a mutation.

I think it may be one of those things you have to see in order to understand.

I’ve been using git for remote collaboration music production for 5 years. We sometimes use branches as well when we are working in let’s two ideas for a bass line. We’ve not really had any issues other than that we need git lfs.

The workflow is based on having the same software, ableton and plugins are largely mirrored.

We communicate over FaceTime which is good enough to assess ideas. When then record track for track and build the songs that way.

Many years ago I used to work for a company in the gambling domain. There was a story going around from years before I joined that hardware TNRGs where used. And one day they failed. I can't remember precisely but heat was involved in one way or another and the failure mode they encountered was caused by overheating and repeatedly giving an endless series ones. A switch to PNRGs was promptly introduced.

Clojure/Script and JavaScript/TypeScript dev with 25 years of experience.

I've built high performance 2d game engines, 2 poker clients and quite a few MVC frameworks. I like functional techniques, react/redux, react hooks, clojurescript. Somewhat unusual is that I tend to enjoy and be good at the last slog of a development project, to get the application in front of users.

Location: Sweden

Remote: Preferred

Relocate: No, but prepared to commute to Stockholm

Technologies: JavaScript/ClojureScript, React/redux or hooks. Comfortable with all web tech.

CV: https://www.linkedin.com/in/jonatanwallgren/

Email: jonatan dot wallgren at gmail

Clojure/Script and JavaScript/TypeScript dev with 25 years of experience. I've built high performance 2d game engines, 2 poker clients and quite a few MVC frameworks. I like functional techniques, react/redux, react hooks, clojurescript. Somewhat unusual is that I tend to enjoy and be good at the last slog of a development project, to get the application in front of users.

Location: Sweden

Remote: Preferred

Relocate: No, but prepared to commute to Stockholm

Technologies: JavaScript/ClojureScript, React/redux or hooks. Comfortable with all web tech.

CV: https://www.linkedin.com/in/jonatanwallgren/

Email: jonatan dot wallgren at gmail

Made by the design agency Söderhavet in Stockholm. More info here https://soderhavet.com/work/sweden/

Is it really that hard though? On the top of my mind I can come up with several success stories of solving tragedy of the commons type of problems. For example:

Global regulation around CFCs made the ozone hole shrink

The don't mess with texas anti littering campaign and similar outreach programs worldwide reduced littering

In general taxing negative externalities seems to have an effect

One of the first things I did as a professional programmer was to make a game for blind people where you used audio for navigation. The game was developed in cooperation with a school for blind kids and them using echo location to various degrees was quite prevalent. A common use case was to identify the direction of open doors when passing by. Some where quite reliant on using it but skill levels varied quite a lot.

This is true, my partner is a social worker and applied for this. It works.

What about https://xtdb.com/

Apparently Eviation is looking into aluminium air batteries https://en.wikipedia.org/wiki/Eviation_Alice

And it can be replicated in a school setting! https://www.youtube.com/watch?v=MbucRPiL92Q

ClojureScript is great and it'd be my first choice if performance doesn't matter. For me the drawbacks are that bundlesizes tend to be bigger than using js. Profiling is much harder due to the output from the google closure compiler is somewhat opaque. Reasoning about memory allocation and leaks can be quite difficult even in a complex js app, having persistent data structures makes this an order of magnitude more difficult.

Here are my observations after doing clojure for a bit more than a year coming from doing js for two decades.

It’s fast, both clj and cljs but performance is non deterministic and as with most functional languages it can be hard to reason about performance. Profiling cljs is very hard

Coming from the js world I feel that tooling generally works. Especially when it comes to build systems. Very happy to not deal with webpack inconsistencies. With regards to ides there’s cursive for IntelliJ users, Calva for vscode.

I can’t comment that much on Java interop. Js interop is a mild inconvenience.

With regards to ecosystem, google ability is an issue but tempered by the simplicity of both clj and cljs.

About types, there are a class of bugs they will help to avoid. It does help with understanding intent of the code you work with. The drawback is that they help facilitate abstraction and does not help with reasoning that much about a program actually runs.

Yes cljs is a different language. But in practice it feels very much the same. I do however have a big issue with being able to push deterministic performance out of it. Keeping execution time for any frame below 16ms can be a challenge and for some type of front end stuff js is to be preferred

All of these things are quite insignificant on how fast a team can churn out good quality code using clojure. I’ve never seen any team that I’m with at the moment write correct, readable and fast code as quick.

It seems like some of the interpretations of quantum mechanics can be falsifiable with this method. Very Cool! In fact it looks like it would be possible to probe my favorite solution to the measurement problem: https://en.wikipedia.org/wiki/Objective-collapse_theory

I would like to recommend this recent documentary on Atwoods life https://www.youtube.com/watch?v=Btn7S9vR02A