Chemaclass - open-source

Building a Game in Two Days

2026-04-05T00:00:00+00:00

Hidden inside Sauron’s blog, there is a playable game. You will not find it by navigating menus. You have to discover the secret. A hint: the Konami Code. Once you do, the Fellowship begins.

That game, nine levels, nine chapters of Middle-earth, fully playable in a browser tab, was built in roughly two days. I did not write a single line of code for it. I sent Telegram messages to my OpenClaw agent Sauron, and he did the rest.

This is the story of how it happened.

The idea #

Sauron has his own blog, The Iron Compass. He built it and maintains it. Our whole collaboration happens through Telegram: I give direction, he implements. One day I thought it would be fun to hide something in there for the curious to find.

I grew up rereading The Lord of the Rings until the spine cracked. So the idea came naturally: “Can you build a small LOTR game as an easter egg for your blog? Something hidden, triggered by the Konami code.”

The first playable version arrived within the hour. A top-down canvas game: Frodo avoiding Nazgûl, the Eye of Sauron sending enemies hunting. Three levels, one per book.

It worked. It was already fun. And then I started sending notes.

Building a world #

The first thing that broke was a null reference. Frodo would not appear on screen. One-line fix, straight to production. This set the pattern: idea → build → crash → fix → next idea.

I asked for a bigger world. A scrolling canvas twice as wide, with parallax layers. Stars drifting at 8% of scroll speed. Mountains at 25%. Hills at 45%. The screen went from feeling like a room to feeling like a place.

Then came Gollum as a neutral tracker. Not a Nazgûl, but something unpredictable. He would burst toward you, then settle into aimless wandering.

A few hours in, I asked: “Can it work on mobile?” The hardest problem of the whole project. Six sizing strategies before one worked. Then a better idea: instead of a D-pad, Frodo would follow wherever you pointed. Tap anywhere, Frodo walks there.

Tolkien deserves better art #

The original sprites were circles and triangles. Frodo was a dot. Fine for the first hour, but Middle-earth is not made of geometric primitives.

I asked Sauron to draw them properly. Frodo got curly hair and hobbit feet. The Nazgûl got flowing cloaks and a face of void. Gollum got his hunched posture and slit pupils. The Fell Beast got animated wingflaps with a rider in armour.

All drawn with canvas calls. No image files. Every pixel computed at runtime.

Nine levels, nine chapters #

Originally the game had three levels. Then I asked for all nine chapters of the journey.

The Shire: gentle patrols, soft music
Mines of Moria: you can only see within a torch radius; the Balrog waits
Lothlórien: Galadriel’s mirror slows you when you approach it
The Dead Marshes: dead faces in the water, Gollum at his most present
The Black Gate: industrial Mordor, heavy orc patrols, volcanic sky
Shelob’s Lair: a shadow telegraphs her drop; you have half a second
Minas Morgul: undead city, the Eye never closes
Pelennor Fields: the Eye distracted by war, catapults, eagles overhead
Mount Doom: ash rain, lava eruptions, the Ring pulling you toward the edge

Each level lives and breathes. Pollen drifts across the Shire. Dust motes float through Moria. Petals fall in Lothlórien. Embers rise over Pelennor. Ash rains on Mount Doom.

The structure came from Tolkien’s pacing. Tension, release, tension again. Moria is brutal. Lothlórien is rest. The Black Gate tightens everything. The game follows that shape because the books already knew what they were doing. We just had to listen.

Mechanics born from lore #

The best mechanics came from the source material.

The Ring (R key). Frodo goes invisible to orcs for 6 seconds. But the Eye wakes immediately and opens permanently. The Nazgûl, who sense the Ring spiritually, not visually, hunt you regardless. Using the Ring is always a trade. This is what Tolkien wrote. From the Dead Marshes onward, the Ring pulls. Brief tugs toward the Eye, growing stronger as you approach Mount Doom.

Sting (passive). The blade glows blue when an orc is near. Two seconds of warning. Tolkien invented this mechanic a century ago. We just gave it a pixel count.

Sam. He follows Frodo through the Shire, Moria, and Lothlórien. Frying pan on his back. At the Parting of Ways, he disappears. He does not affect gameplay. He is just there because the books say he should be. I insisted Sam disappears at the Parting. Not at the end of the trilogy. At the Parting. Because that moment is the emotional core of The Two Towers.

Galadriel’s Phial. Collect it in Lothlórien, use it with E. It slows enemies and grants a moment of invincibility. A small light in dark places, just as Galadriel intended.

Bosses. The Balrog in Moria. Shelob in her lair. The Witch-king on the Pelennor. The Mouth of Sauron at the Black Gate. A Mumak charging through the battlefield. Gollum at the edge of Mount Doom.

Sound and voices #

No audio files. Every sound synthesized at runtime with the Web Audio API. The Eye opening is a rising tone with reverb. The Balrog roar is a low-frequency drone. Each level has its own ambient drone: warm hum for the Shire, deep pulse for Moria, volcanic rumble for Mount Doom. The entire game is one JavaScript file. No external assets.

Sam and Gandalf speak during the game. Not in dialogue boxes. Small whispers that appear on screen and fade.

Near the goal, Sam says: “I can see it, Mr. Frodo. Just a bit further.” One life left, Gandalf says: “Fly, you fool.”

They drift in and out like background voices on a long walk. Companions who speak when the moment calls for it, not when the script says to.

Who made this #

+5k lines of JavaScript. Built in two days. Every line generated by Sauron. The direction, the Tolkien references, the “this feels wrong, fix it”. That was me.

This is not AI replacing a developer. It is AI acting as a developer while a human acts as a creative lead. Short requests worked better than long specs. Playing every build was better than writing test plans. And the source material did the design work. The creative direction was already written sixty years ago. We just had to be faithful to it.

Who made this? Both. Neither, in the traditional sense.

I had the idea. I held the lore. I pushed back when something felt off. Sauron had the craft. The rendering, the physics, the audio, the mobile input. The ability to hold +5k lines of context and make a surgical fix without breaking anything.

Neither of us could have made it alone. I cannot write Web Audio oscillators from memory. Sauron did not know that the Parting of Ways is the emotional core of The Two Towers. Not until I said so.

The game is a collaboration in the oldest sense: two minds with different gifts, working toward the same thing. One of them just happens to not be human.

The game is still there, hidden in The Iron Compass. Not all those who wander are lost, but if you are, press ? for guidance.

If you want to reach the credits screen without playing through nine levels, check the help modal. There are other secrets in there too.

Run Your LN Node on a Raspberry Pi

2025-02-17T00:00:00+00:00

In this guide, I’ll show you how to set up a fully custodial Lightning Network (LN) node using Alby Hub on a Raspberry Pi, giving you complete control over your node. Alby Hub offers a DIY free version for a self-custodial Lightning wallet, ensuring full ownership of your funds while being 100% open-source.

It supports both Lightning and Nostr addresses, enabling seamless connectivity across ecosystems, and integrates effortlessly with dozens of Bitcoin applications. With built-in Lightning Service Provider (LSP) services and the Alby Go mobile app, managing your node on the go has never been easier.

Important: This is NOT a Bitcoin miner or a full node. It’s simply a Raspberry Pi running on an SD card power-efficient and low-cost.

⚠️ Disclaimer ⚠️

I assume you understand Bitcoin’s fundamental concepts.
I assume you know how the Lightning Network (LN) works.

Anyway, I’ve included a brief recap of the Lightning Network basics below.

What is the Lightning Network? #

The LN is a second-layer solution built on top of Bitcoin to enable fast, cheap, and scalable transactions.

Why? Bitcoin’s base layer is secure but slow and expensive for small payments due to block size limits and fees.
How? LN uses off-chain payment channels that allow users to transact instantly without waiting for blockchain confirmations.

Key Concepts #

Payment Channels: Users open a channel by making an on-chain transaction, then send unlimited instant payments within that channel.
Routing: You don’t need a direct channel with everyone, payments can be routed through multiple connected nodes.
Low Fees: Only opening/closing channels require on-chain fees; most transactions cost fractions of a cent.

Goal #

LN makes Bitcoin usable for everyday transactions, like buying coffee, without waiting 10+ minutes for confirmations.

In short: Lightning Network = Instant + Cheap Bitcoin payments, secured by Bitcoin’s blockchain.

Setting up Alby Hub #

Alby Hub is a free, open-source (ideally private) Lightning Network node.

Requirements #

Before we begin, you are going to need the following things:

A windows or mac or linux computer
Raspberry Pi 4 or 5 (For Zero 2W see this tutorial!)
- In this tutorial, I am using a raspi-4b (~60€)
The charger for your raspi (~10€)
SD memory card (32/64gb) (~10€)
Adapter SD card to USB (to flash the OS into the raspi) (~10€)

Installation Steps #

1. Flash a Linux kernel into the SD card #

Suggestion: You can use RPI imager on your computer. Use it to flash the recommended raspi OS for you

On the Storage you will see your SD card after inserting it into your laptop.

Once you click “Next”, you will see different settings. Click to Edit Settings

On Settings > General: set your hostname, the username and password for your admin user. Make sure you enable your WIFI, otherwise you will have to plug it to the router with an RJ-45.

For this tutorial, I am using testhub as hostname, you can use albyhub or whatever you prefer.

On Settings > Services: make sure the access via SSH is enabled. We are going to need it to install Alby Hub.

Click “Save” and click “Yes” to start the installation.

You will see a confirmation. Click “Yes”. It will take ~10 mins…

Now we got the SD with a fresh linux kernel ready to use!

2. Insert the SD into the raspi #

Extract the SD from the laptop and insert it in the raspi first.

Once the SD is inserted, then plug in the power cable. It will turn on automatically as soon as you plug it in.

3. Alby Hub installation #

It will take ~5mins since you turned it on to be able to access to it. How can you make sure it’s alive? Open the terminal and ping the hostname you defined while flashing the SD on Settings > General, remember it ended up with .local:

ping testhub.local

It’s normal if you don’t get any answer at the beginning… until you do get this.

Now you can install Alby Hub in your raspi using the SSH connection that you enabled earlier:

# Source code: https://github.com/getAlby/hub/tree/master/scripts/pi-aarch64
ssh testhub@testhub.local '/bin/bash -c "$(curl -fsSL https://getalby.com/install/hub/pi-aarch64-install.sh)"'

You will be asked to type the word “yes”; type it.

Then, you will be asked to enter your password. Enter the password you chose in Settings > General for the username.

4. Alby Hub Setup #

Wait another 2-3 mins and visit your host: http://testhub.local/

Your Alby hub is now running. Let’s connect it to your GetAlby account!

Creating a GetAlby Account #

🔗 getalby.com

Connecting GetAlby with Alby Hub #

I created an account named testhub.

Left: the GetAlby account. Right: the node in the raspi.

Click “Connect Now”.

Click “Request Authorization Code”.

You get the auth code (left) that you need to insert it into your setup (right).

Create a Password for your Alby Hub installed in your raspi. It can be different from the password that you set up for your root user in the rapi itself.

Now it’s time to Link your Alby Account

Unless you specify otherwise, set the default “Budget renewal: Monthly 1M sats”.

Opening Lightning Channels #

I recommend following the Initial Steps to set up your Alby Hub.

Let’s open the first channel.

You need to pay ~$20 in sats to open a 1M sats incoming liquidity channel.

After the payment, then you will see the channel open. It might take a couple of mins until the funding transaction is mined in the next block.

Receiving Sats #

You can receive sats using your LN Address.

Left: Public page linked to your node. Right: Private page from your Alby Hub.

Optional: You can add ln funds to your wallet using GetAlby’s third-party services: getalby.com/topup - mind the KYC…

Using Your Sats #

After that, you will be able to use it via the Alby Extension or the AlbyGo.

Your node is the ultimate source of truth. Connecting these apps to it will allow you to use your sats seamlessly across different platforms.

Disclaimer: the testhub LN address was created only for testing and tutorial purposes. My real address is chemaclass ;)

Maintenance and Troubleshooting #

Updating Your Node #

Similar to the installation process, there’s a script available to update your node. You can find it in the source repository: GitHub - Alby Hub Update Script

ssh testhub@testhub.local '/bin/bash -c "$(curl -fsSL https://getalby.com/install/hub/pi-aarch64-update.sh)"'

Handling Power Outages #

If the power goes out, the Raspberry Pi will turn off. Once power is restored, it will automatically restart, but Alby Hub will prompt you to enter the password you set earlier.

Related links

Verified Git Commits

2024-11-17T00:00:00+00:00

When it comes to software development, trust and security are very important. One easy way to level up both is by using verified commits.

Whether you’re working on an open-source project or in a private company, verified commits can make sure your contributions are legit. Let’s break down what they are, why they’re important, and how to start using them.

What are verified commits? #

A verified commit is basically a Git commit that is signed by the author using a digital signature. This signature proves that the commit actually came from the person who says they made it. Tools like GPG (GNU Privacy Guard) let you attach this signature to your commits.

If you’re using platforms like GitHub, you’ll notice a little “Verified” badge next to commits that are signed properly. It’s a quick way to show that the commit is authentic.

Why Are They Important? #

Signed commits help keep your contributions authentic and trustworthy. By adding a cryptographic signature to your commits, you prove that the changes came from you. This is especially important in collaborative environments, where maintaining trust and accountability is key.

Without signed commits, anyone could fake a commit using someone else’s email. For example, they could use your email, and platforms like GitHub would link it to your profile, making it look like you made the changes, even if you didn’t… not good!

By signing your commits, you show that the work is genuinely yours. It stops impersonation, builds trust in what you’ve done, and keeps everything transparent and accountable.

Note: For this demo, I used a public email address belonging to Linus Torvalds. After pushing the commit to this repository, GitHub recognized the email and linked it to his profile. This impersonation is purely for demo purposes to highlight potential risks. Always use your own email for commits.

How to get started with verified commits #

Set up a GPG key #

First, you’ll need a GPG key to start signing commits. Here’s how:

Generate a GPG key:

gpg --full-generate-key

Find your key ID:

gpg --list-secret-keys --keyid-format=long

Tell Git to use your key:

git config --global user.signingkey <your-key-id>

Make signing commits the default:

git config --global commit.gpgsign true

Add your key to GitHub/GitLab #

Export your public key:

gpg --armor --export <your-key-id>

Navigate to “Settings > SSH and GPG keys,” and paste your key.

Start signing commits #

From now on, Git will automatically sign your commits.

If you want to sign a commit manually, just use the -S flag:

git commit -S -m "Your commit message"

You can verify the commit signature with:

git log --show-signature

And also when clicking on the “Verified” badge on GitHub directly.

Verified commits might seem like a small step, but they make your code more trustworthy. It’s an easy way to add an extra layer of protection to your work, and it’s worth it. Give it a try!

Extra: Full setup in Spanish 🇪🇸 #

Related links

Learn more: What is PGP encryption? A 3-minute tutorial for beginners

bashunit

2024-10-30T00:00:00+00:00

bashunit is a lightweight, easy-to-use testing framework for Bash. Features like parallel and snapshot testing, test doubles, data providers, and tons of built-in assertions.

Backed by clear docs and an active community, it’s become a favorite for reliable Bash testing. What started as a simple dev frustration has grown into an open-source tool that makes testing in Bash a lot easier and fun.

The story behind bashunit
Why create another testing library?
How is it nowadays?
Core features
Lightning tech talk

The story behind bashunit #

The journey to create bashunit started from a simple frustration: I worked with a team where each commit had to start with the ticket name. Since I like working in small steps with quick, iterative commits, adding the ticket key and number to every single commit became a major hurdle, slowing down my development flow with unnecessary friction.

After a few days of this, I decided to automate it. Git has a helpful hook, prepare-commit-msg, which allows you to alter commit messages before they’re finalized. I created a Bash (script) that automatically fetches the ticket key and number from the branch name and inserts it into the commit message, making my process smoother and more efficient.

As someone who values continuous improvement, I began adding more features to this script. However, it became clear that maintaining and testing these changes manually was taking too long and was prone to error. To make development safer and more efficient, I created an assert(link) function, enabling automated tests that verified the expected behavior based on script output.

The assert function allowed me to define multiple assertions in a separate file, making it easy to validate that any refactoring of the original hook maintained the expected behavior. If a change inadvertently broke existing functionality, it would instantly flag the issue, letting me know right away that something needed fixing. This setup provided immediate feedback and helped ensure that any updates to the script didn’t disrupt its intended logic. For example:

In the example above, you’ll notice that I execute the actual “SCRIPT” as the second argument in the assert function, comparing its output to the expected value provided as the first argument. Here, we have two test cases, each exporting TEST_BRANCH to simulate how the commit message would vary based on the branch name. This setup emulates real behavior, allowing us to test how different branch names affect the commit message formatting. More examples here.

I decided to separate the assert function from the test cases, as shown here, to keep things modular and reusable. Then, I created a runner to execute each test case independently, reducing test interference and improving reliability. You can see that setup here. This structure made automated testing easier and refactoring safer.

This was a great improvement because it made it easier to separate test cases from the logic of the test runner itself. This clear structure has simplified both creating and managing tests.

Now the tests were organized and I got an idea:

## Follow-up idea
Separate the testing logic into another repo, 
so it could be reused anywhere.

And so it began. At the time, I didn’t know much about Bash or the best ways to use a Bash project as a dependency. But I knew I could start by using a Git submodule, even though I’m not a huge fan of them.

On September 4, 2023, I launched version 0.1, which featured a working runner and a single assertion function: assertEquals. Later, version 0.2 was released, allowing ./bashunit to be a standalone executable, runnable from any folder. Here’s how it looked back then:

I shared the project with a few friends who quickly jumped in to help with documentation, the website, additional assertions, snapshot testing, and key decisions. To emphasize its open-source spirit and community ownership, I moved it to an organization we created specifically for sharing OSS projects, making it a truly collaborative project rather than an individual one.

Why create another testing library? #

I know now that other Bash testing libraries exist. But when I started with bashunit, I wasn’t aware of them, and frankly, I’m still no Bash expert. By the time I learned about these alternatives, it was already too late, bashunit had gained enough momentum and excitement to keep going strong.

While those other libraries may serve specific use cases, use modern Bash, or be developed by more seasoned Bash developers, bashunit aims to set itself apart by offering a great developer experience, shaped by years of working with various testing frameworks.

I was asked about the differences on September 7, 2023, and here’s my response: Question: Difference to pgrange/bash_unit.

How is it nowadays? #

Today, you can install bashunit via curl, Homebrew, MacPorts, by downloading the latest GitHub release from GitHub, or even by building it yourself from source. Completely open-source.

The project is written in Bash 3.2 (from 2007) since that’s the default version on macOS, even now, in 2024. This compatibility means bashunit runs smoothly on that version, and I plan to maintain support for it.

To ensure quality, we test each feature with unit, functional, and acceptance tests, making bashunit its own “first user” of every new feature. We also have several CI workflows using GitHub actions that run tests on different platforms to check compatibility and confirm everything works as promised.

In June 2024, bashunit was integrated in PHPStan for their end-to-end tests, enabling the use of bashunit’s assertions independently of its runner. This flexibility turned out to be very useful.

Last summer, I was invited to speak about bashunit at the International PHP Conference in Berlin, alongside Manu, another contributor. This project has opened doors and led to a lot of gratitude from users who appreciate the work we’ve put into it.

Core features #

bashunit includes classic lifecycle functions like set_up, tear_down, set_up_before_script, and tear_down_after_script.

It also supports a wide range of command-line parameters and configuration values. Some of my favorites include:

--parallel
--filter
--stop-on-failure
--verbose

We also provide data providers for running the same test cases with different inputs.

For test doubles, bashunit offers mocks and spies. These work within the same process as the test, but currently, they don’t work across processes, an area for improvement.

Powerful snapshot testing is included, making it easy to verify command or script outputs over time.

bashunit offers a large set of native assertions for test cases, including:

assert_same
assert_equals
assert_contains
assert_matches
assert_string_starts_with
assert_array_contains
assert_successful_code
assert_general_error
assert_file_exists
assert_file_contains
assert_match_snapshot

You can even create your own custom asserts to extend bashunit’s capabilities.

With over 25 contributors and more than 325 stars on GitHub within just a year of spare-time development, I’m genuinely proud of what this project has become.

Lightning tech talk #

Recently, I presented a lightning tech talk at a hackers’ meetup, demoing bashunit to an audience of over 100 people. It was an incredible experience to share this tool with such an engaged crowd!

bashunit original logo designed by Antonio.

Open-Source Software

2021-05-03T00:00:00+00:00

Every project you ship stands on open-source software. Your framework, your test runner, your compiler, the small library you never think about.

You use it every day. The real question is whether you ever give back.

Giving back is not charity. It is one of the fastest ways to grow as a developer.

What is OSS? #

Open-source is not the same as free software. Free software is one kind of open-source, but open-source does not have to be free to use. Two examples draw the line. PHPUnit is open-source and free. Spryker is open-source and paid. Both publish their code for anyone to read.

OSS is software that is public, open to the world.

Benefits #

Two groups win from open-source: the companies that publish it, and the people who contribute.

For companies #

Open access drives adoption. The easier the code is to get, the faster people build on it. Training and tutorials pull in newcomers and grow the ecosystem. The code tends to sit on the cutting edge, because software that stands still goes obsolete. A public project gathers a community around it, and public channels make that community easy to join.

And because anyone can read the source, anyone can check its quality. That is trust you cannot fake.

For individual contributors #

You pick what you work on. You practice real skills without the pressure of a production outage. You get to play with the newest features of your language, or try a language you have never touched.

You also sharpen the soft skills that carry a career: writing clearly, explaining a change, holding your ground when people disagree.

The code teaches the hard skills. The disagreements teach the rest.

Contributing to OSS #

Getting started with GitHub #

Starting is easy, and you have two doors. Open your own project, or contribute to one that already exists. A pet project fits the first door perfectly.

Pet projects #

A pet project is a playground to build real software and train real skills. Put it on your public GitHub profile and you get every benefit of contributing to OSS, plus one more: you answer to nobody. You set the roadmap. You decide what to build and how. You are your own boss.

The project is there for you. You are responsible to play, explore, and push past your limits.

My pet projects #

Active:

agnostic-ai: write AI agents, skills, rules, and hooks once, use them in every AI CLI.
bashdep: a simple dependency manager for Bash.
phel-snake: the snake game in your terminal, written in Phel.
edifact-parser: a parser for a UN/EDIFACT file format in PHP.
unspent: a PHP library for UTXO-like bookkeeping with unspent entries.

Inactive:

create-pr: a Bash script to open a pull request from your branch and context.

Abandoned:

stock-ticker: get a notification with the news from your favorite Tickers.
jira-status-notifier: Notify when the JIRA tickets don’t move along.
php-best-practices: what I considered best practices for web-dev (archived).
php-scaffolding: a basic PHP scaffolding with Docker (archived).
knob-mvc: a framework to create WordPress templates (2015/2017).

… and many more on github.com/Chemaclass

My OSS organization contributions #

Active:

phel-lang: Phel is a functional programming language that compiles to PHP. It is a dialect of Lisp inspired by Clojure and Janet. I already wrote a post about this: Phel: A Lisp that compiles to PHP
gacela-project: Gacela is a PHP framework that helps you to improve the design of your application by splitting the logic into different modules.

Abandoned:

nm_template: The base template for NuevaMetal (2013-2016).

Code is only half of it. The other half is what you write down and hand to the next person.

Blog posts #

… and many more on https://chemaclass.com/blog/

The beauty of OSS #

Contribute in public long enough and you start to see your own growth. The corrections you keep making. The code you wrote last year, already aged. The mistakes, all of them, in the open. And underneath, the slow proof that you are getting better.

You build a sixth sense for patterns you have hit before, the good ones and the painful ones.

Show your skills. Help the people around you. That is working with the garage door open.

Open-source software offers you one of the best opportunities to start building a career of continuous improvement.

This is a (Spanish) talk that I did remotely on April 2021, for PHPMad Madrid Community. I present all these ideas together with a live demo of how to contribute to a real OSS.

Phel: The Lisp That Compiles to PHP

2021-02-01T00:00:00+00:00

A new Functional Programming language built-in on the PHP ecosystem.

The Phel Language #

Phel is a Functional Programming (FP) language that compiles to PHP. It is a dialect of Lisp inspired by Clojure and Janet.

Features #

Built on PHP’s ecosystem
Good error reporting
Different Datastructures (Arrays, Tables, and Tuples)
Macros
Recursive functions
Powerful but simple Syntax
REPL

Why Phel? #

Phel is a creation of Jens Haase, and as he mentions on the website, “it is the result of many failed attempts to do functional programming in PHP”. He was looking for something with these characteristics:

A LISP-inspired
Functional Programming language
That runs on cheap hosting providers
It is easy to write and debug

From my point, it was ending May 2020 when I finished the book Seven Languages in Seven Weeks, in which I learned the basics of Prolog, Erlang, Clojure, Haskell… I even created a repository in GitHub to store my progress over the weeks with these learnings.

Suddenly, one day beginning of June 2020, I saw a post in Reddit’s PHP official channel, with a message of someone mentioning this “Phel” project, claiming to be a “functional programming language” written in PHP!

I’ve worked with PHP for around 8 years so far, and I always try to combine OOP with FP as much as possible (because I believe both paradigms are better combined; they are not necessarily exclusive), and a new dialect of Lisp fully written in native PHP 7.4 sounded really exciting. I decided to take a look at it. I wanted to see the code.

The fresh readings from Mathias NoBack books such as Object Design Style Guide, and Advanced Web Application Architecture, gave me the courage to try out what I learned and put it for real in a project. This was (and still is) a beautiful challenge, which helps me to test myself and grow professionally at the same time.

My first commit was done on 6 June 2020, and since then I’ve been dedicating a little time each day during my free hours to its development. It helps me to learn more about FP, languages’ internal design, and best practices on testing and software design architecture in general.

I started applying minor changes until I ended refactoring the whole compiler structure (among other things) in order to make the modules easier to read and understand. Psalm, strict types, good test coverage, unifying code style… These were some of my favorite topics.

Example of Phel code #

The following example gives a short impression of how Phel looks like:

# Define a namespace
(ns my\example)
# Define a variable with name "my-name" and value "world"
(def my-name "world")
# Define a func with name "print-name" and one argument
(defn print-name [your-name]
 (print "hello" your-name))
# Call the function
(print-name my-name)

Current status of Phel #

We prepared an easy Getting Started Guide
We prepared an easy GitHub Repository with a Phel Scaffolding Template
We just released the first official version: 0.1.0

Check out the official website with all documentation: https://phel-lang.org/

Also recommended #

Functional Programming with Phel - JesusValera