> https://blog.softwarewrighter.com/2026/10/16/array-languages...

I originally wrote gpu extensions that use OpenCL/CUDA. I more recently added a modular mojo backend that allows me to use Metal instead of OpenCL on Apple Silicon.

I should mention that I am trying to apply a Jev-inspired approch to a trained-from scratch, in-browser typed decision model that attempts to recreate the deterministic classic Eliza program.

This work is helping me with dogfooding my language. I am now adding several improvements to the language to improve ergonomics, readability, and possibly speed (one example in sw-MLPL actually runs faster than my Rust port). I was able to express the code more compactly than the Python or Rust versions.

The planned improvements will allow me to simplify many downstream demo projects that have been working around language deficiencies.

The link includes literate programming explanations of the code with math equations.

Comments URL: https://news.ycombinator.com/item?id=49818692

Points: 2

# Comments: 0

I do not mean to anthropomorphize their work, but I do need to improve what they produce. I think a lot of push-back to vibe-coded projects is that the person asking an AI Agent to make something do not or cannot improve what it produces, which goes back to the question asked. Is it worthwhile to learn programming now. I argue that it is.

So, it would be better if models were trained to produce provably correct code, and agent harnesses are improving to help do this, but the models themselves have been shown to be trained to provide the answer they think you want to hear, and declare a task done as fast as possible. They hallucinate (or lie) about running tests, even about writing code at all (sometimes).

How do cloud models "learn" to write better code? Where are the projects that fine-tune an open/local LLM to "learn" from its mistakes. I have yet to see any model improve on its own.

A lot of the best code I've seen is closed source, and unlikely to be represented in existing training data. A lot of the worse code I've see was online. Maybe newer coding models are getting trained better, but most I've tried are years out of date. Maybe my view is affected by trying so many LLMs. Very few have been great.

Newer APLs support lazy evaluation. My eager language has a workaround for this. The Z combinator is the standard strict-language fix: wrap the self-application in one extra function layer (λv. x x v), so the recursion is a value (a delayed call) rather than an executing expression. sw-MLPL expresses that delay as a named partial — z_step/z_recur/applicative_sage — because the language has no anonymous lambdas.

Z has no Smullyan name (and no zebra in the aviary, despite the letter). The book predates and ignores the strictness problem, so it has no applicative-order variant. "Z combinator" is programmer folklore for the eta-expanded Y

Comments URL: https://news.ycombinator.com/item?id=49790937

Points: 11

# Comments: 0

One thing that is missing from both of our approaches is the ability re-train (fine-tune) coding models "overnight" so that they can "learn" from the prior day and changes since their training cutoff date.

I have found some things I can do to improve my work based on this, thanks.

_Pentad idea_ -/- _MLOS relevance_ -/- _Action_

Closed autonomic loops -/- Very high -/- Adopt architecture vocabulary

Deterministic replay -/- Very high -/- Strengthen event/replay contract

Model minimalism -/- Very high. -/- Extend later to compute-placement ladder

Durable vs active population -/- High -/- Define registered vs resident capacity metrics

Standing queries -/- High -/- Future policy/watch abstraction

Provenance by construction -/- High -/- Record policy decision causality

No model/NLP in hot path -/- High -/- State explicitly as invariant

If I used a macro to generate code that gets compiled and linked to code someone else provided, how is that different from asking a coding agent to generate similar code and linking to other coding agent code?

Is your concern that the output is probabilistic vs. a macro or code generator producing code deterministically? I apply engineering practices to ensure the results are suitable.

I do understand that AI is fundamentally different (and I've been studying ML in depth for more than a year). My comparison was in terms of tools increasing productivity, not how they do that.

I was a "10x programmer" on several projects and I am 10x more productive now than I was then (at least). I can create in a few days by myself (with agents) what used to take months (with a team of people).

Maybe I'm producing what some consider "AI slop" but the things I've built this year work to my satisfaction, are fun to make, and I am constantly learning new things. And I am doing this for fun but also to learn by teaching, so I build educational, visual things to share with others.

https://github.com/sw-ml-study/sw-os-ml

I also have been implementing small model inference:

https://github.com/sw-ml-study/moe-microscope

I should clarify that by Apple Silicon I mean it boots Rust no_std on ARM. Does not use GPU yet. Plan is to use Rust without CUDA libraries. This project is more likely to use an NPU on a ARM dev board before it can use an NVIDIA GPU, and might never be able to use Apple GPUs. Goal: run on no-longer-supported by CUDA GPUs.

Part of the fun is solving puzzles where the coding agent gets stuck and me then giving it technical direction. Especially when an agent says that something cannot be done in software (I show them how it actually can be done).

I am in the more motivated than ever camp.

Your posted link is helpful, thanks.

The blog post includes link to the repos (MIT Licensed), a video of the agent in action, sample code produced, and an Emacs org-mode literate programming document explaining the implementation and tests. There are links to an interactive playground for the sw-MLPL language.

The git repo can be used to run this agent locally on a system with Ollama and a coding LLM. Does not yet connect to cloud LLMs.

I hope this helps someone learn how a coding agent can be built. Inspired by (but not ported from) OpenCode.

Comments URL: https://news.ycombinator.com/item?id=49729456

Points: 2

# Comments: 0

Is the intent just to use it to view markdown with colors, spacing?

Do you plan to provide ways to export it to something like PDF, html w/css, etc.?

Let's say I wanted to take a README from my github repo and blog about it with the pretty version in a blog post, how would I do that?

Each tool, abstraction, language feature elevates coding to get more done with less (more concisely). Programming is a social activity, since source code is meant to be read by humans (at least historically) even if it is just yourself later.

I'm not trying to talk you into using AI coding agents, but explain why I find them fun, and I've written a lot of code by hand over decades, from spaghetti assembler code to structureed programming to object oriented to functional, etc. Each advance in the industry has been a new and diiferent kind of fun for me.

I think AI is a great tool, but requires safeguards. I use it every day, but I use a lot of tools to reign it in, keep it on task, check its results, and force it to follow an engineering process.

I don't know about the "as quickly as possible" part, since there needs to be guardrails, but improving AI should be done sooner rather than later. e.g, instead of training to give the answer it thinks you want to hear, it should be trained to give provably correct answers. instead of being trained and fine tuned and then let loose, it should be able to continuously learn and improve.

While people keep chasing tokens/second and vibe-coding, I'm more interested in correct results per kWh, sustainable and ethical AI. Also, I'm worried that there will be an increasing digital divide between the wealthy and the rest of us, so I do want AI to be available and not locked up just for corporations and governments.

To me, the fun is solving problems, and AI let's me solve more problems, harder problems and more quickly. I was happy to move from assembler programming to high level programming languages, to 4GL, to frameworks, tech stacks, etc. Moving to AI coding is just another shift in solving problems at a higher level with more productivity.

hacking microprocessors was fun. building complex systems using AI is fun, too.

I'm curious about:

- how to "upcycle" end-of-life NVIDIA GPUs, like K80, M40, P100, etc.

- how to offload MoE expert calculations to MCUs with NPUs, possibly FPGAs

- how to manage a 10G LAN-attached network of older Xeon servers with the above GPUs and USB-attached MCUs as a machine learning "fabric"

- do ideas from IBM's ACP/TPF O/S (now Z/TPF) carry over?

- do ideas from IBM's Workload Manager (business priorities managed resources) carry over?

- can I bypass end-of-life CUDA driver support for older NVIDIA hardware by using Rust/Vulcan?

- can I leverage the architecture of Freetoken (MoE caching/routing, Engram, KV-cache compression) and other approaches like Baby Dragon Hatchlings, Hierarchical Reasoning Models, Tiny Recursive Models, Recurisve Language Models, Multi-token predicion, etc?

- is anyone else intersted in actually building something like this?

I've explored many of these parts individually, now combining them...

Also, I'm working towards running my code on embedded systems, including bare metal (no Linux, no RTOS). I'm looking into custom FPGA circuits, too.

Python isn't great for me, for these uses. Rust is, and my language is a Rust DSL.

This inspired me to use my ML tools to build a tiny MoE model from scratch so I can experiment with different agent optimizations and things like Engram, recursive models, hierarchical modeles, KV Cache compression etc.

My link above shows results of building different tiny models, one dense, the rest MoE variants. There is a lot of code and tooling behind this.

Goals: - build tiny MoE models that run in a browser to give interactive help (today I use deterministic matchers to respond to user queries; still researching how to improve this with better trained MoE models). - build tiny MoE models that run on small ARM and RISC-V development boards, possibly using NPUs (using no_std Rust).

My tools are an alternative to Python, ML libraries, Jupyter notebooks, and Google Colab.

My approach is a REPL and/or AOT Compilable array-programming DSL written in Rust. This language has ML concepts as first class language elements and built in visualization primitives.

It runs in a browser via WASM. It runs at the CLI on both Apple and Linux (supporting Apple GPU and NVIDIA GPU libraries, Ollama-based REPL context-senstive help). It is extensible via dyamic plug-in Rust libraries.

I have created many demo repos showing how to use this ML array language for ML tasks, learning Math concepts, general purpose programming. You can build desktop apps, (Ruby on Rails inspired) CRUD apps. So you can create ML experiments and visualize data in the browser or on the desktop.

It also supports Emacs org-mode for literate programming.

This tiny MOE Microscope is just my latest demo of this approach. I hope it helps someone learn more about MoE experts, routing, Engram, etc. It helped me learn more.

Comments URL: https://news.ycombinator.com/item?id=49690947

Points: 2

# Comments: 0