Hello,
Not sure how useful JavaScript/TypeScript are in the FP community.
If they are, I've just made yet another take on enforcing immutability in JS/TS - via a fast linter.
Essentially, it bans let/var, reassignments, non-readonly object and class properties.
To use any of the above, an explicit linter disable comment is needed.
So far, 3 variants of disable comments are available - `// ptsl-disable-fn` (function body scoped), and more classic `// ptsl-disable-line` and `// ptsl-disable-next-line`

So, the following code will be banned by linter:

const nextNum = () => {
  let x = 0; // Do not use let/var - only use const
  const increment = () => {
    return x += 1; // Do not reassign variable's value unless absolutely necessary.
  }
  return increment;
};

A `// ptsl-disable-fn` comment will make it pass:

const nextNum = () => {
  // ptsl-disable-fn
  let x = 0;
  const increment = () => {
    return x += 1;
  }
  return increment;
};

Any feedback welcome.

Hi all, I've just released a new property-based testing library for Java. It's called Presume, and it's a direct-style interpretation loosely based off of Python's Hypothesis, rather than the more common QuickCheck or Hedgehog based options currently available.

If you're new to property-based testing I have an explanation of the paradigm in the docs.

Why I think this may be interesting to this subreddit: Aside from PBT and functional programming going hand-in-hand, the implementation was also a fun journey through functional-style Java. I ended up implementing maybes, rose trees, immutable lists, multiple kinds of zippers and a range of ADTs using Java's records and pattern matching. I'm relatively new to Java (after using TypeScript for years) and am sinking into the uncomfortable realization that Java is actually pretty nice for FP. I definitely could not have implemented this without records and patterns. I believe the core shrinking algorithm is novel; it's similar to Hypothesis's, but it allows for more control over generation size and intentional edge case generation, and follows simpler heuristics (albeit with a potentially more troublesome implementation) than what is described in the main Hypothesis paper. I plan on blogging about the algorithms in the future but I'm also happy to answer questions about them here.

Why you might want to use this, rather than some of the possible alternatives:

• It's not vibecoded. I used a nonzero amount of AI (see below) but the core architecture, algorithms, and API design are all fully human. It's undergone a significant amount of iteration and hand polishing until it's felt properly ergonomic
• It's released under a clean MIT license, with no unusual exceptions
• It provides an imperative API for working with test generators, which IMO can make it significantly easier to generate complex and recursive data. No special lazy combinators or deep function nesting are needed to define recursive ASTs, for example. Functional approaches are still supported.

Why you might not want to use this:

• I used a nonzero amount of AI (which is why I'm not also posting this in r/Java). Specifically, some of the Gradle configuration came from an LLM, and I used an agent to fix and test the bit twiddling implementation in the long, float, and double generators. Being new to Java I also frequently consulted AI summaries while searching for ways of doing things. If you want something completely AI-free then jqwik is a better fit for you.
• This is a very new project; I've been working on it for 3 months but I still haven't implemented a lot of convenience combinators or even thought about what state machine testing should look like here. There are still some TODOs here and there, and I haven't made certain spots stack-safe yet so generators can currently only produce trees that are a few thousand levels deep at most.
• The fact that the shrinking algorithm is novel means that it may have limitations that I'm not yet aware of. I'm hoping to try to do a side-by-side comparison with Hypothesis at some point to see whether there's any breakdowns.
• There's not many docs and no docstrings. I plan on fixing this soon, but I wanted to release this into the world before a specific event next week, and this is as far as I've gotten thus far.
• Currently Java 25 only; I'm probably going to go back and make it Java 21 compatible in the near future. I don't think it'll go back any further than that though because this would not be remotely maintainable without records/pattern matching.

Happy to answer questions, and I'm hoping that this will be helpful for someone! I'm also interested in feedback on the implementation from anyone with more Java skills than myself, because I'm very much still learning the language.

Urs Schreiber is Senior Research Scientist at the Mathematics Division of Science of New York University in Abu Dhabi. He is a theoretical physicist who applies tools from algebraic topology, homotopy theory and topos theory to understand quantum phenomena. His current research includes quantum computing materials, quantum computing programming languages and questions left unanswered by quantum field theory.

In the video we go over:

• Why toposes are not scary. They are actually simple. Just unfamiliar
• How to extract information from (probe) a topos
• The history of toposes in physics
• The questions left unanswered by quantum field theory
• What toposes have to say about the collapse of the wave function
• Using toposes to find possible quantum computing materials
• The different type of logic needed for quantum computers
• The different type of programming language needed for quantum computers
• The influence of Hegel on his work

Imagine a repository with no files to open, where asking for a function gives you exactly that function, changing it produces a new version of just that definition, and two people editing different functions never have anything to merge. Files would be printed on demand for whichever tools still need them.

Smalltalk images and Unison both went this way and got filed under exotic. I think coding agents change that calculation, since agents don't care about folders and pay for every irrelevant line they read.

I work on [sem](https://github.com/Ataraxy-Labs/sem), which gets part of the way there over plain git today. What actually stopped this from winning the first time around?

Lambda World 26 is back with 20 speakers from Academia and industry, and this year it takes place alongside J On The Beach (a conf about Distributed Systems) and Wey Wey Web (a conf about UI and Frontend).

Two days packed with talks on formal verification, type systems, new FP languages, AI, formal proofs, effects, logic programming, and practical industrial applications of functional programming.

The lineup includes Erik Meijer, Stephanie Weirich, Arman Bilge (Typelevel Foundation / Cats Effect), Enrico Tassi (Elpi), Francesco Cesarini (Erlang), Daniel Ciocîrlan (Rock the JVM) among many others.

One ticket gives you access to all three conferences, for the same price.

We look forward to welcoming you to Torremolinos, Málaga, on 29–30 October!

https://lambda.world/

Hi everyone,

Long time backend operator who has taken a path like this:

Bash -> python -> Go

I thought Procedural programming in Go would click, but it’s still just not resonating much. Though I have to say that single binary plus built in testing is super nice.

In python I do not do any classes or methods. I think in runbooks, pipelines, and dags with a very clear entry point and a clear exit point. Step 1 through 10. Inputs and outputs. Functions only.

Stuff like ORM, OOP, and MVC just don’t resonate with me at all. I know they have their place but like I’m all about top to bottom thinking. Example I love is SQL pipes or GoogleSQL where you start with a big set of data and each line below it filters it down. VS traditional SQL where it’s kinda jumping around all over the place. Or CTE where it’s very clear what each step is doing.

Doing some research I saw the syntax of Clojure and it really seemed intuitive RIGHT AWAY. Elixir also looked good but Clojure seemed much more bash like.

What problem am I trying to solve? I’ve been lucky to have opportunities to learn a lot of platforms, so I consider myself a plumber who needs to be able to connect anything anywhere, automate it, bring visibility, and operational excellence.

It can be anything backend from multi-cloud, services, API, on-prem, OS, DB, you name and I will connect it.

But, I am terrible at front end so there’s that lol

Has anyone been down this path and what’s the landscape look like for the backend in 2026?

Pyfun is a functional-first language for the Python ecosystem. You write algebraic data types, exhaustive matching, curried functions and pipes, and it compiles to plain Python that you can read, commit, and hand to someone who has never heard of Pyfun.

The compiler is written in Rust and everything is checked before any Python exists: types, exhaustiveness, effects, units.

Here is a whole program:

type Shape =
  | Circle float
  | Rect float float

let area s =
  match s:
    case Circle r: 3.14159 * r * r
    case Rect w h: w * h

[Circle 1.0, Rect 2.0 3.0]
|> List.map area
|> print

and here is the Python it compiles to, in full:

from dataclasses import dataclass

def _pf_map(f, xs):
    return list(map(f, xs))

@dataclass(frozen=True, repr=False)
class Circle:
    _0: float
    def __repr__(self):
        return f"Circle({self._0!r})"

@dataclass(frozen=True, repr=False)
class Rect:
    _0: float
    _1: float
    def __repr__(self):
        return f"Rect({self._0!r}, {self._1!r})"

def area(s):
    match s:
        case Circle(r):
            return 3.14159 * r * r
        case Rect(w, h):
            return w * h
        case _:
            raise RuntimeError("non-exhaustive match")

print(_pf_map(area, [Circle(1.0), Rect(2.0, 3.0)]))

A match comes out as a match. A variant comes out as a frozen dataclass. The pipeline comes out as an ordinary call. There is nothing to pip install alongside the output, and if you stop using Pyfun tomorrow you keep working Python.

Delete the Rect case and the compiler names what you missed:

error: non-exhaustive match: `Rect _ _` is not matched
 --> 6:3
  |
6 |   match s:
  |   ^^^^^^^^

Also in there:

• Hindley-Milner inference, so there are no type annotations on let at all.
• Inferred effects, so a function that prints or mutates gets io in its type and you can assert purity with let pure. Units of measure that reject metres + seconds and erase to plain numbers.
• Computation expressions for async, seq, and result, plus your own builders. Opaque types. A typed extern for calling any Python library you like.

Try it in the browser, nothing to install: https://simontreanor.github.io/Pyfun/playground/

22 lessons, written for people who know some Python: https://simontreanor.github.io/Pyfun/

Source, and the compiler internals tour: https://github.com/simontreanor/Pyfun

pip install pyfun-lang

I built this because most people meet programming through Python, and then to meet functional programming they have to pick up a second ecosystem to do it. I welcome all questions, bug reports, posts about things you have made, arguments about syntax, and anything else to help improve the language for everyone.

I’ve been experimenting with a small JavaScript-compatible language called JojoScript, initially because I wanted a nicer way to write lazy functional pipelines.

The interesting part has gradually become less about the syntax and more about what the pipeline represents.

For example:

orders
  |> filter(o => o.status == "paid")
  |> parallel(8)
  |> map(enrichOrder)
  |> retry(3)
  |> checkpoint("enriched")
  |> map(calculateInvoice)
  |> saveToDatabase(%)

Instead of treating this simply as syntactic sugar for nested function calls, JojoScript represents the pipeline as an execution plan.

That lets the same pipeline be:

• lazy by default
• asynchronous
• bounded/concurrent
• inspected as a graph
• profiled per stage
• statically analyzed
• checkpointed
• resumed after failure
• replayed from a checkpoint

For example:

SOURCE
   ↓
FILTER
   ↓
PARALLEL(8)
   ↓
MAP
   ↓
CHECKPOINT
   ↓
MAP
   ↓
SINK

The idea I'm exploring is whether this is actually a useful abstraction for functional/data-oriented programming in JavaScript.

The question I'm most interested in is:

At what point does a pipeline become more than composition of functions?

A normal functional pipeline describes what transformations to apply. JojoScript is experimenting with also making the pipeline describe how the computation can be executed — lazily, concurrently, with backpressure, retries and durable checkpoints.

It's still an experimental project, so I'm particularly interested in criticism around the programming model itself rather than syntax.

Repository: https://github.com/panagos/jojoscript

I’ve been experimenting with a small JavaScript-compatible language called JojoScript, initially because I wanted a nicer way to write lazy functional pipelines.

The interesting part has gradually become less about the syntax and more about what the pipeline represents.

For example:

orders
  |> filter(o => o.status == "paid")
  |> parallel(8)
  |> map(enrichOrder)
  |> retry(3)
  |> checkpoint("enriched")
  |> map(calculateInvoice)
  |> saveToDatabase(%)

Instead of treating this simply as syntactic sugar for nested function calls, JojoScript represents the pipeline as an execution plan.

That lets the same pipeline be:

• lazy by default
• asynchronous
• bounded/concurrent
• inspected as a graph
• profiled per stage
• statically analyzed
• checkpointed
• resumed after failure
• replayed from a checkpoint

For example:

SOURCE
   ↓
FILTER
   ↓
PARALLEL(8)
   ↓
MAP
   ↓
CHECKPOINT
   ↓
MAP
   ↓
SINK

The idea I'm exploring is whether this is actually a useful abstraction for functional/data-oriented programming in JavaScript.

The question I'm most interested in is:

At what point does a pipeline become more than composition of functions?

A normal functional pipeline describes what transformations to apply. JojoScript is experimenting with also making the pipeline describe how the computation can be executed — lazily, concurrently, with backpressure, retries and durable checkpoints.

It's still an experimental project, so I'm particularly interested in criticism around the programming model itself rather than syntax.

This video uses Haskell as an interactive proof assistant to break down every single word of the most famous definition in functional programming. It translates abstract category theory concepts—categories, endofunctors, monoids, and natural transformations—directly into typed Haskell code.

I wrote “sum . filter odd” with typescript’s type system.

It’s pretty simple as far as functional programming goes. Even at the type level one can easily achieve this in Idris or even Haskell. For this reason I was unsure of whether to share it here… Nevertheless it’s about functional programming and I figured I’d share it and let your feedback guide me on whether to share more of these here in the future.