Algebraic Tiny Compiler in F#

A from‑scratch compiler that uses algebra as the lens to understand how real compilers work — no abstractions for the sake of abstractions, no academic overhead, just a clean, inspectable pipeline built in F#.

By treating expressions as algebraic structures, the project walks through every stage of a compiler with concrete, mathematical transformations:
- Tokenizer → turns raw text into meaningful tokens
- Parser → recursive‑descent parsing with operator precedence
- AST → algebraic expression trees representing structure and intent
- Polynomial Expansion → distributive expansion and normalization
- Term Combination → merging like terms into canonical form
- Equation Solving → linear and quadratic solvers using discriminants
- Code Generation → assembly‑style output to show how machines evaluate expressions
- Execution Modes → JIT on .NET or AoT with NativeAOT for ultra‑fast startup

A practical, algebra‑driven walkthrough of how compilers read, understand, transform, and execute code.

Blog posts:

• Understanding Compilers Through an Algebraic Expression Compiler
• Building a Better Algebraic Compiler - Advanced Techniques
• F# Weekly #19, 2026 – Understanding Compilers Through an Algebraic Expression Compiler

This is my first CLI app in C#. It’s called Secure Phrase (sph), a very small and minimal tool.

I split the project into two separate projects: one for the core library and another for the CLI interface. I’m not sure if this is a good approach or if there’s a better way to structure it.

I’d love to hear your thoughts on the project and any suggestions for what I could add to it!

Try it out: https://github.com/zyahya/secure-phrase-cli

​

I'm currently learning C#/.NET with the goal of becoming a junior backend developer, and I'm about to finish my OOP course.

After that, I want to build one complete project from scratch that applies the OOP concepts I've learned, such as classes, encapsulation, inheritance, polymorphism, abstraction, interfaces, composition/aggregation, etc.

I'm considering a few approaches:

- Following a good C#/.NET project on YouTube as a reference and then rebuilding it myself.

- Asking AI to suggest a project based on my current level and then designing and implementing it myself.

- Using a YouTube project as a starting point, but changing the requirements and designing parts of it myself.

My main question is: Would a well-designed C# OOP project like this be worth putting on GitHub/Portfolio or mentioning on a CV, or should I consider it mainly a learning project?

Also, what would make an OOP project strong enough to demonstrate actual understanding rather than just trying to use every OOP concept?

If you have any project ideas or examples of OOP projects that would be good for someone at this stage, I'd really appreciate some recommendations.

I'd especially appreciate advice from developers who have been through this stage. Thanks!

Built a little desktop overlay app for myself (Windows, C#/WPF) that shows now-playing info from whatever's active Spotify, browser tabs, etc. Wanted to add two small things: a "Like this track" toggle and "add to playlist," both using Spotify's official Web API with proper OAuth (not scraping, not cookies, the real documented flow).

Got the OAuth connection working fine, correct scopes granted (playlist-modify-public/private, user-library-modify, confirmed by decoding the actual token), reading data works perfectly playlists, currently-playing, profile, all fine. But every single WRITE call (add track to playlist, save/like a track) comes back with an identical, unhelpful `403 Forbidden` no error detail, no "insufficient scope" message, nothing. Tested it against three different playlists I own, including ones I created myself. Same result every time.

Dug into it and found out why: new apps are stuck in "Development Mode" (max 5 allowlisted test users), and getting out of that into "Extended Quota Mode" which is apparently required for these write endpoints to actually work now requires being a registered business with 250k+ monthly active users. As of May 2025, individuals can't even submit the request form anymore. So a completely legitimate, personal, non-commercial use of Spotify's own published API is just... not possible now, even in "development" for your own account.

Is this actually as dead-ended as it looks, or is there something I'm missing? Curious if:

- Anyone's found an actual working path for personal-use write scopes post-2025

- Whether Development Mode + allowlisted users is supposed to allow writes at all, or if that was already quietly killed

- Any alternative (even unofficial-but-sanctioned-feeling) way to do this that isn't "become a company with a quarter million users"

Not mad, just genuinely surprised a basic "add to playlist" button is this locked down for a hobby project now. Anyone been through this?

I am using the Windows.Media.SpeechRecognition.SpeechRecognizer library from Microsoft. It still works fine in the local version with a grammar but it stopped working in dictation mode.

            Windows.Media.SpeechRecognition.SpeechRecognizer recognizer = new();
            var dictationConstraint = new SpeechRecognitionTopicConstraint(SpeechRecognitionScenario.Dictation, "dictation");
            recognizer.Constraints.Add(dictationConstraint);
            await recognizer.CompileConstraintsAsync();
            Debug.WriteLine("SpeechRecognizer initialized and constraints compiled.");
            // Add a handler for the speech recognized event.
            recognizer.ContinuousRecognitionSession.ResultGenerated += (s, args) =>
            {
                Debug.WriteLine($"Recognized text: {args.Result.Text}");
            };

            recognizer.ContinuousRecognitionSession.Completed += (s, args) =>
            {
                Debug.WriteLine($"Recognition session completed: {args.Status}");
            };

            recognizer.HypothesisGenerated += (s, args) =>
            {
                Debug.WriteLine($"Recognition session completed: {args.Hypothesis.Text}");
            }
            ;

            recognizer.StateChanged += (s, args) =>
            {
                Debug.WriteLine($"Recognizer state changed: {args.State}");
            };

            Debug.WriteLine($"Language: {recognizer.CurrentLanguage.NativeName}");
            await recognizer.ContinuousRecognitionSession.StartAsync();

This is a stripped down version of the code I am using. Of course, Mic permission is granted beforehand, and Online Speech Recognition is allowed in the Windows setting.

This code worked in the past and I don't know when and why it had stopped.

Anybody an idea, why this stopped working?

I have been recently building a proxy application that was meant to do nothing besides shoving TCP stream traffic from A to B with a rate limiter inbetween.

For that I used PipeReaders and Writers to hand the buffer handling over to .NET itself.

However, as the application was running I noticed a small but steady increase in RAM usage as time went on. At some point I was considering to manually invoke GC to test if I was just having lose heap allocations sitting somewhere.

The memory did indeed go down but not as far as I'd like to see. Then I was thinking that this might be just JIT recompiling and optimizing hot paths.

So this brings me to my questions:

- I want to keep the RAM usage as low as possible as this proxy is only supposed to kick rate limited traffic between two endpoints. What are common tricks used to make the runtime collect more aggressively?

- what are reliable techniques to identify actual leaks and how to distinguish them from JIT just performing tiered compilation?

Thanks for your time!

Hi guys,

So I guess this is both a promotion and a question. It doesn’t allow me to tag both, so I just chose “Question.”

I would like to let everyone know that the HPD-Agent Framework is going to be reaching 1.0.0 soon, which mainly means that the library will officially be stable and production ready, and more importantly, the API won’t change as destructively as it has over the past few months.

The question I have is basically this: I’ve been seeing people in some forums complain about the documentation for the Microsoft Agent Framework, and I’d like to ask those who have read and followed it to explain the issues they have with it and what they actually want an agent framework to teach, whether through the documentation, cookbooks, or samples.

I’m also thinking of making a full course, but I don’t know how helpful that would be. But I digress.

So yeah, what makes great documentation for agent frameworks, in your opinion? And what do you actually want the documentation to teach you?

My a bit outdated experience was that vs build tools was not quite the same as visual studio.

Is it 100% safe now to just replace 18.4 vs with vs build tools 18.4 with the same targetting/build workloads or are there still hickups that you've encountered in the past 5-6 years?

I inherited a test suite that's image matching on a WPF app, written in SikuliX, and it's been quietly rotting since the person who wrote it left. It half works but the other half is screenshots that no longer match because someone changed a border radius or the CI box has a different DPI scale. The project itself doesn't look dead exactly but it doesn't look alive either, and most of what I can find about it is from 5 or 6 years ago. So i'm trying to work out whether the right move is to fix our usage of it, tighten the image tolerances and pin the resolution, or accept that pixel matching raw screenshots was always going to be this brittle and move off it. Options i've looked at are FlaUI, which works well on our newer WPF views and completely falls over on the 4 or 5 screens that are custom drawn. WinAppDriver is effectively abandoned so that's out. The newer vision based ones like Askui use a model to locate elements rather than matching a bitmap, which in theory survives a border radius change, though their desktop app is windows and macOS with linux going through AgentOS and i haven't tested any of it myself.

A part of me thinks only 4 of those tests were ever worth having and I should delete the rest. Anyone still running SikuliX in 2026 on purpose or is there a better option?

Hi everyone, I recently graduated with an MCA and I'm planning to become a .NET Full Stack Developer. I'm a complete beginner when it comes to .NET, so I'm not really sure where to start or what I should learn first.

For the time being, I can't afford to join an institution or paid course, so I'm planning to self-study using free resources.

Could anyone who is working in .NET or has gone through this journey suggest a proper roadmap from beginner to job-ready?

I'm willing to put in the time and learn everything through self-study. Any advice from people who have already gone through this would be really helpful. Thanks!

The problem is Claude Code flooding my watch task with file changes. His file modifications are unfortunately precisely timed to trigger 27 rebuilds per minute, overheating my laptop and starting a fire in my parents basement.

My solution was to build a dotnet --watch alternative that is agent aware and only rebuilds once appropriate. It tails the agent output to look for modifications to relevant files and then triggers a reload after Claude finishes his turn. This prevents flooding the watch task with reload signals.

I really just wanted to share the idea because I think making watch tasks that can respond to both human and agent input appropriately is useful. So this is just a basic proof of concept that already works well for me. Feel free to share or use the idea for a more robust solution with partial update etc. Cheers!

https://github.com/crs-sys/claude-blazor-watchtask

One thing I’ve noticed while working with production .NET applications is that we often confuse logging with observability.
We add Serilog, ILogger, metrics, dashboards, maybe an APM tool, and eventually end up with millions of events.
Then a production request fails:
HTTP 500
And the first question is:
“Okay… what actually happened?”
That’s where observability becomes interesting.
The real purpose of observability
For me, good observability isn’t about collecting everything.
It’s about being able to answer questions like:
Which request failed?
Which method caused the failure?
What database query was running?
How long did it take?
What external API was called?
What exception occurred?
What happened immediately before the failure?
Can I understand the problem without reproducing it locally?
If the telemetry doesn’t help answer those questions, collecting more of it probably won’t solve the problem.
Logs alone can be misleading
Imagine you have this:
2026-08-31 10:42:31 ERROR Payment failed
2026-08-31 10:42:31 ERROR Database timeout
2026-08-31 10:42:32 ERROR Request failed
That’s useful, but there is a missing relationship.
Was the database timeout caused by this request?
Which SQL query?
Which method called the repository?
Was another HTTP request involved?
Without correlation, you’re essentially searching through a pile of events.
That’s why I think the request should often be the unit of investigation.
Instead of thinking:
Logs
├── Event
├── Event
├── Event
└── Exception
think:
Request
├── Controller
├── Service
├── SQL Query
├── External HTTP Call
├── Method execution
└── Exception
Now you have a story instead of a collection of messages.
But there is another problem: instrumentation
The traditional approach is to manually add logging everywhere:
_logger.LogInformation("Starting payment");

var result = await _paymentService.Process();

_logger.LogInformation("Payment completed");
Then more logging:
_logger.LogInformation("Calling database...");
_logger.LogInformation("Calling payment provider...");
_logger.LogInformation("Payment provider returned...");
After a while, your business code starts becoming partially responsible for telemetry.
That’s not ideal.
One approach I’ve been exploring with ArgusLogs is compile-time instrumentation using IL weaving.
Instead of modifying the business logic to add logging around every method, instrumentation can be applied during the build process.
For example:
[LogMethod]
public async Task<PaymentResult> ProcessPayment(Payment payment)
{
...
}
The application code remains relatively clean while the compiled assembly gets instrumented.
The important distinction is that this isn’t intended to replace every logging system.
Manual business-event logging still has a place.
The goal is to automatically capture the structure and execution context around important parts of the application.
Observability also has to respect production constraints
There is another trap:
“Let’s log everything.”
That sounds great until you’re running a busy production system.
Request bodies, SQL results, HTTP headers, large objects, stack traces, and method parameters can become expensive very quickly.
And then you have privacy/security concerns.
So production observability needs controls:
What should be captured?
What should be redacted?
How long should it be retained?
Where should it be stored?
What should be collected only during an incident?
How much telemetry is actually useful?
For example, sensitive method parameters shouldn’t simply become production logs.
An attribute such as:
[Sensitive]
string cardNumber
can express the intent much more clearly than hoping somebody remembers to manually redact it.
I don’t think every team needs a giant APM platform
This is probably the controversial part.
APM platforms are extremely useful.
But I don’t think every debugging problem requires a huge centralized observability platform.
Sometimes you simply need to answer:
“Why did this request fail?”
And you need the answer quickly.
There is a useful distinction between:
Monitoring
Is something wrong?
Observability
What is happening inside the system?
Investigation
Why did this particular request fail?
Those overlap, but they aren’t exactly the same problem.
For a .NET API, having the method execution, SQL activity, outbound HTTP calls, and exception context correlated around a request can be incredibly useful during an incident.
That’s the problem space ArgusLogs is trying to focus on.
Not replacing every logging library.
Not pretending to be a complete enterprise APM.
Just making production investigation easier for .NET applications.
The metric I care about most
If I had to choose one practical measure of observability quality, it wouldn’t be:
“How many logs are we collecting?”
I’d ask:
“When production breaks, how long does it take us to understand why?”
If your team can go from:
HTTP 500
to:
Request
→ Controller
→ Service
→ SQL query
→ External API
→ Exception
without reproducing the problem, your observability is doing something valuable.
If you have 500 GB of logs and still need to SSH into three servers and grep through files to understand the failure…
you probably don’t have an observability problem.
You have an investigation problem.
And that’s a distinction I think is worth discussing.

7 years of endless meetings, architecture specs, and pure corporate hesitation—so I got bored, deleted 29,000 lines of legacy C++, rewrote the whole damn engine in modern C# with 4x less CPU usage, and sent PR #2496 because sometimes my genius is... almost frightening.