251
 
 

This is a devlog from my learning of a quick prototype, I hope it can fit in this space too. It's partially code, partially archtecture and a fair lot of notes and discussion with myself. Maybe this can be the cup of tea of someone reading this.

252
253
254
submitted 2 months ago* (last edited 2 months ago) by to c/programming@programming.dev
255
 
 

Has anyone tried in organization to use self hosted llm models for agentic programming?

Im curious if it makes any sense. My organization spends fortune on tokens from us companies. I want to recommend something…

256
257
 
 

Nell’articolo precedente abbiamo visto come si possono mettere le note a piè di pagina in una pagina web. Ora vediamo, invece, come possiamo inserire un separatore.

Apriamo l’editor OneCompiler e dopo aver cancellato tutto, digitiamo: L’HTML è un linguaggio di markup che serve a creare ed abbellire una pagina web

258
259
 
 

Voiden is an offline-first, git-native API tool built on Markdown.

Instead of keeping API requests inside a cloud workspace, Voiden stores them as .void files that can live with your codebase, be versioned in Git, reviewed in PRs, and reused across a team.

We have now released the beta of @voiden/runner, a headless CLI for running those .void files outside the desktop app.

The runner executes the request, prints the result, and exits with a standard exit code that CI systems can use.

Important bits:

  • runs on Node.js 18+
  • works in terminal, CI/CD, Docker, and cron jobs
  • supports REST, WebSocket, gRPC, and GraphQL
  • supports JSON and CSV output
  • supports request chaining through runtime variables
  • works with core Voiden plugins like scripting, assertions, faker, - - advanced auth, and GraphQL

This is still beta, so APIs and flags may change.

The goal is to make .void files executable API workflows, not just files used inside the desktop app.

Github: https://github.com/VoidenHQ/voiden

Voiden CLI Runner : https://github.com/VoidenHQ/voiden/tree/beta/packages/voiden-runner

Visit Voiden here : https://voiden.md/

260
 
 

One of the tenets from a software-craft site I've been building. The idea is to keep state and dependencies as local as you can, and only promote something to a wider scope (module, shared, then global) once it's actually used widely enough to earn it. Most of the 'shared' code I've had to untangle started local and got hoisted up a tier too early.

261
262
 
 

Running Code in a Programming Language Nobody Knows

Last month, I ran code in a programming language that nobody knew.

I'm not the first to do a thing like that. Ben Olmstead created Malbolge in 1998. It's a deliberately incomprehensible programming language that's likely impossible for anyone to really know; it took a search algorithm to generate the first program for it. Finding examples of an old, obscure language with no surviving practitioners is another potential method I imagine has been done a few times.

Nobody had ever known Nucleus when its compiler bootstrapped. Since it's 2026, I imagine many readers have already guessed large language models were involved. I gave a sample program and output to an LLM tool and told it to write a compiler in C. I then told the tool to add features to the language until it could rewrite the Nucleus compiler in Nucleus, resulting in a language that I did not know. LLMs do not "know" things and aren't somebody, so at that point, nobody knew Nucleus, yet there were about 4000 lines of it running in the compiler, able to produce real binaries that run on real computers.

Someone I mentioned this to asked why I would want to design a programming language without designing a programming language. I don't actually want to do that, but just as the compiler needed an initial implementation in another language in order to bootstrap, I found it much easier to work from a minimal working language than a blank slate. I had the idea for Nucleus for a long time and have not yet read the Dragon Book and written a compiler from scratch like I told myself I was going to.

As for the language itself, the basic idea is a language for manipulating memory at a low level like C, but with Lisp-like syntax and structural macros providing compile-time abstractions and safety-enhancing constructs with no runtime overhead. By the time it hits 1.0, Nucleus should be usable as a drop-in replacement for C anywhere C is used. I'm not the first to do a thing like that either, but other implementations I've seen actually compile a Lisp-like language to C. Nucleus targets LLVM directly.

@programming

@programming@programming.dev

#lisp #LanguageDesign #compilers

263
264
265
 
 

I proposed this project to improve on Radicle's p2p model by using Tor for universal, straightforward seeding of git repos.

Original discussion thread - https://bounties.monero.social/posts/207/

One of the project's git repos linked in that thread - https://radicle.network/nodes/iris.radicle.network/rad:z2ydYmUCJvDfNFTVTpEbQmm55EPt1/history

Project website - https://cradicle.xyz/

The dev who took the project also expanded it into a project to reimplement Radicle in C.

Since I'm not a coder and I don't have any git repos of my own, I can only test from the viewpoint of an average layman using the GUI app to seed repos.

It's impossible for me to properly gauge how the project is progressing without engagement from coders who try using it for their git repos.

If the project doesn't currently interest you, your suggestions on how to start getting users on board would also be welcome.

Edit - bear in mind that because decentralized discussion platforms like this are currently quite broken, there are comments showing up in the thread when I'm not signed in that don't show up for me when I'm signed in. Here's a screenshot of all the comments showing up for me right now where I'm signed in and able to reply, as of UNIX time 1779670288

aqhH5rVg9opRagM.png

I'd encourage discussion of this project moreso on nostr (equally broken but my preferred platform) or the discussion thread linked above (seemingly more functional)

266
267
 
 

A lot of work in this release was related to porting to other platforms. We did a large number of refactorings to put ELF-specific behaviour behind traits. We've also started work on porting to Mach-O and WebAssembly. These aren't yet ready for use, but if you'd like to help out with porting, get in touch.

Wild now supports the linker plugin API that was originally part of the Gold linker, but which is also supported by GNU ld and Mold. This lets us do linker-plugin LTO (link time optimisation). There are still a few known issues, but it's already working on a good range of programs. Pure Rust projects generally don't use linker plugins, since Rust can do LTO within the compiler, so this is mostly helpful for C, C++ or mixed language projects. Note that when using a linker plugin, link times will be very slow.

Lots more linker-script features were implemented during this release.

[...]

268
wake up! 16b (hellmood.111mb.de)
269
270
271
272
The elephant in the room (www.joshwcomeau.com)
273
Stop Using Pull Requests (a4al6a.substack.com)
submitted 2 months ago* (last edited 2 months ago) by to c/programming@programming.dev
 
 

TL;DR

  • Pull requests were designed for open source contributions from untrusted strangers. Applying them to trusted teams is a category error.
  • Peer-reviewed research shows code review’s primary value is knowledge transfer, not bug detection. Less than 15% of review comments relate to actual bugs.
  • Async PR workflows mean your code spends 86-99% of its lead time waiting. One organisation spent 130,000 hours in a single year waiting on PRs that received zero comments.
  • DORA research across 36,000+ professionals shows trunk-based development correlates with dramatically higher software delivery performance, and faster code reviews alone improve performance by 50%.
  • The alternative is T*D: Test-Driven Development (build quality in), Trunk-Based Development (integrate continuously), and Team-focused Development (review during creation, not after).
  • The transition is gradual: optimise PRs first, adopt Ship/Show/Ask, then move to pairing and trunk-based development as trust and automation mature.-
274
275
view more: ‹ prev next ›