I'm interested in machine learning, distributed systems, programming languages, and entrepreneurship. I have a personal site at https://noelwelsh.com/
I'm a partner at Inner Product (http://inner-product.com) and Underscore (http://underscore.io), where I teach, mentor, and develop Scala.
I'm previously was a co-founder of a startup called Myna which applied multi-armed bandit algorithms to the problem of content optimisation -- where A/B testing is traditionally used.
Submissions
Coaxing quality (writing) output from generative AI
scala-lang.org
3 points·by noelwelsh··1 comments
Artificial Adventures
scattered-thoughts.net
2 points·by noelwelsh··0 comments
Show HN: Functional Programming Strategies, the book I'm working on
functionalprogrammingstrategies.com
5 points·by noelwelsh··1 comments
Completion is a Substrate, not a UI
chiply.dev
2 points·by noelwelsh··0 comments
Unreleased Pixel Watch 5 Found by Diver in St Martins
xcancel.com
2 points·by noelwelsh··0 comments
Practical Effect Handlers in Capability-Passing Style
link.springer.com
2 points·by noelwelsh··1 comments
Doodle: Compositional 2D Graphics
creativescala.org
1 points·by noelwelsh··0 comments
Parametricity, or Comptime Is Bonkers
noelwelsh.com
2 points·by noelwelsh··0 comments
A Quick Introduction to OxCaml
noelwelsh.com
1 points·by noelwelsh··0 comments
My fast zero-allocation webserver using OxCaml
anil.recoil.org
159 points·by noelwelsh··50 comments
Httpz – Zero-Allocation HTTP/1.1 Parser for OxCaml
github.com
88 points·by noelwelsh··19 comments
Designing Custom UUIDs
noelwelsh.com
1 points·by noelwelsh··0 comments
Harvard considered as a long-lived biological organism (2022)
frankhecker.com
3 points·by noelwelsh··0 comments
Stack Overflow and the Programming Language Rankings
redmonk.com
2 points·by noelwelsh··0 comments
The Performance Effects of Virtual-Machine Instruction Pointer Updates [pdf]
drops.dagstuhl.de
1 points·by noelwelsh··1 comments
Understanding Virtual Machine Dispatch Through Duality (2023)
noelwelsh.com
1 points·by noelwelsh··0 comments
Operational and Denotational Strategies for Understanding Code
noelwelsh.com
1 points·by noelwelsh··0 comments
Designing a DSL for Terminal Interaction
noelwelsh.com
1 points·by noelwelsh··0 comments
Terminus, a Scala 3 library for working with the terminal
creativescala.org
1 points·by noelwelsh··0 comments
If you want to play tennis at the top level there's a benefit to being ____
Good article. Not much to add to it, other than I think more people should look at modal type systems like found in Scala 3 and OxCaml. If you want safe arena allocation they are a lot more ergonomic than Rust's approach.
You might enjoy digging into the world of effect handlers: it's a very neat model for expressing these features and boils down to continuations in the implementation.
A nice thing about being left handed is there a few things I can't get precious about. Fountain pens are never going to feature in my life as I'll just smudge everything. Similarly, I'll never end up collecting gaming mice as most of them are not usable for lefties.
Can anyone explain how this works? Humans have 3 (sometimes 4) cones, so I thought that going beyond 3 primaries wouldn't increase the perceivable gamut.
A collection of thoughts I had while reading the article:
0. Overall, a nice article.
1. There are several places where the (LLM assisted?) writing is a bit odd. For example, the code for hash table insertion is irrelevant. The "“Un-freeable” Nature of Arenas" paragraph sets up a problem that I expect the next section to resolve, but the next section goes in a different direction.
2. It feels like the author is on the verge of rediscovering some classic PL concepts. E.g. tries or regular expressions for faster lexing (why would you ever do strcmp in a loop in a lexer?); de Bruijn indices for disambiguating lexically scoped variables; strong normalization in type systems to canonicalize types.
There is no real evidence that we'll reach AGI any time soon. It relies on AI continuing to scale, and we have no proof that will continue to be possible.
There is an alternative interpretation, which is that Demis looked at the US government's ham-fisted handling of Fable, and deciding that setting up a body to act as a buffer between the Trump admin and the AI companies would be a good thing.
The premise is "Artificial General Intelligence (AGI), a system that exhibits all the cognitive capabilities the brain has, is probably only a few short years away".
If this is true, establishing an institution to ensure things like "publishing model cards with technical details, maintaining strong internal cybersecurity, vetting key personnel, and providing sufficient resourcing for safety and security research" is really mostly irrelevant.
TFA does talk about what really needs to be done, but punts this into future work: "Even if we solve these hard technical challenges, there will be further complex economic and philosophical questions to tackle: what sorts of new economic models will be needed to help everyone thrive in a post-scarcity world? What values do we want to live by, what will meaning and purpose be, and how might even the human condition itself change?"
There's also a need to consider the rights that this new intelligence should have.
A quick summary: the modern university is really a "multiversity", combining research, trade school, broad "liberal arts" education, and residential coming-of-age in one organization. The author argues this model is finished, and the pieces should be separated. I don't know if the author is correct, but I think the idea that the university is many things is important to recognize for this discussion (and just about every discussion around universities).
This law, in sense, wants to distinguish the trade school and general education parts of the university (though I suspect it more aimed at owning the libs than anything else).
Wow. Not a Haskell user, but a big user of other languages with expressive type systems (mostly Scala; some Rust). My experience is the complete opposite. I can't imagine using a language without a good type system to catch all the junk the LLM produces. In fact I thought people would move away from languages from poor type systems, like Python, given the cost of using languages with expressive type systems has decreased with LLMs.
This is the book I'm working on about mental models for better code. It's getting very close to complete, and there is a 150 page free sample.
The book is all about making explicit the structure in code, and the structure in the process of creating code, and using the structure to produce code more effectively. In more academic jargon, it's about metacognitive strategies.
That's a reasonable way of looking at it, but capabilities are not restricted to low-level system properties. Here's a terminal UI system built around three main capabilities:
- layout (adding components to the component tree)
- event (handling user input events)
- react (reacting to changes in reactive values)
You're right, they are related. One difference is simply lineage. Capabilities come out of the erights / security world (e.g. [0]), while dependency injection comes from the XP / agile / Martin Fowler world. More interesting is that to do capabilities correctly you need some type system extensions, namely capture checking. Essentially, this means you delimit where a program can hold a reference to a value derived from a capability. So if you have a function that allocates memory, you can say "there are no references to any allocated memory outside this function call" and hence no use-after-free bugs. It gives a form of resource management that is simpler than Rust's lifetimes. See [1] and [2]. (Technically it's a modal type system versus Rust's substructural type system.) To my mind it's an obvious thing for Zig to add.
Shameless plug. If you're interested in more on this, for a programmer's rather than academic perspective, this is going into my book [3]. I'm writing the chapter of capability passing right now.
What Zig is doing is called "capability passing". I don't know if the Zig team is aware of this field of work, or have independently arrived upon it, but that's what is achieved by passing IO, memory allocators, and other stuff around.
The core idea is that you create a "capability" for any action you want to track, such as using IO, allocating memory, or in your example making cross core or cross server calls. Now to perform these actions code has to have access to the capability. It's a very simple, but powerful, model.
The Effekt language formalizes this, and adds safety properties: https://effekt-lang.org/ Scala 3 also has this.
The papers are pretty readable, if you ignore the middle bits which go into the formal models.
Exactly. I don't understand why people think the ternary operator is needed when you can just make `if` an expression instead of a statement. Then there is no new syntax to learn and `if` just becomes more useful.
The "shovels for gold miners" analogy is generally a good one. It applies to Nvidia, for example. It doesn't generally apply to developers though. Developer tooling is notoriously difficult to monetize. Developers themselves are a shovel.
* The core idea sounds interesting. Make it the first paragraph, not paragraph seven.
* Spend more words describing what makes Oak different.
* "I built a version control system in my free-time called Jam". You probably didn't name your free time. "I built a version control system, called Jam, in my free time."
I'm currently writing up what is the last major chapter, which introduces capability-passing as an architecture, and builds a simple TUI framework using it. Fun stuff!
I'm a few months away from launching the book, but the early feedback is very positive. I find writing enjoyable but also, damn, do I need to get this book finished. :-)
I'm a partner at Inner Product (http://inner-product.com) and Underscore (http://underscore.io), where I teach, mentor, and develop Scala.
I'm previously was a co-founder of a startup called Myna which applied multi-armed bandit algorithms to the problem of content optimisation -- where A/B testing is traditionally used.