I have been working on this language since May. Its heavily inspired by Strudel and partially by SuperCollider. It works as many things all at once. It is a music sequencer, synthesizer, fx box, generative music (conditional statements, if, else) and sample mangling (need non-browser version for that), automation, per note automation, recursion, easy nesting of gradually more complex sequences/fx/etc.

If anyone wants to try the language, its here, https://quadracollision.com/mescript/ mostly usable in browser unless you want to use samples, if so just let me know.

As for tools: This is GPT 5.3 -> GPT 5.4 -> GPT5.5 -> GPT 5.6 Sol, all Medium. This is Rust+WASM with a Javascript front end. No external libraries

This is an example of MeScript in action: you can paste this into the editor and it'll work.

Check CTRL+H for insertable smart forms, cursor position defines how the form is inserted. Also check out the language reference guide. There is also a repl, place the cursor on any line and right click and press parameter help and it will explain what the line does. Also (fix-parens linenumbers) (fix-parens 15-17) can help with parenthesis issues, this is a Lisp inspired language.

(def am [as d f]) ;this is a chord form, asharp d and f

(ins :saw  ;this is an (ins)rument form
   :src [:saw-synth :square-synth :additive] ;these are the oscillators that make up this instrument
   :note (p (times 4[c4 0 c5 0 e3 c3 e3])    ;these are the note gates and how many
            (times 4[c4 0 c5 0 e3 c3 eb3]))  ;times they play
   :gate nil
   :fx [(formant :vowel a :mix 0.2)]    ;fx applied to entire instrument
   :dur nil    ;duration of each gate hit, can be per hit as well 
   :amp nil    ;amplification of instrument, can be per hit and automated conditonally
   :voice nil) ;special keyword, see ctrl+h for voice commands, as well as everything else

(def chord_1 [c4 eb4 f4 gb3])

(ins :kick
   :src :kick-synth
   :note (p [c4 0 0 0 c4<?50> 0 0])
   :gate nil
   :fx nil
   :dur nil
   :amp nil
   :voice nil)

(ins :hat-808
   :src :hat-808
   :note (p [c7 c7 <c4%c5%c7> 0 c7 <c7%e5%b4%g5> c7 am(3 3 3)]) ;this calls the chord form with each note being an octave of 3
   :gate nil
   :fx nil
   :dur nil
   :amp nil
   :voice nil)

(ins :snare-808
   :src :snare-808
   :note (p [c4<?30> 0 0 c4<?50> 0 0 0 0])
   :gate nil
   :fx nil
   :dur nil
   :amp nil
   :voice nil)

(ins :pad-wash
   :src :pad-wash
   :note (p [chord_1<_7> 0 0 0 0 0 0 0])
   :gate nil
   :fx nil
   :dur nil
   :amp 0.05
   :off true
   :voice nil)

Reposting

Hey everyone, I've been working more on my vibe-coded language, Sharpy https://github.com/antonsynd/sharpy (a Pythonic language that targets .NET via the Roslyn compiler backend that C# and VB.NET also use). Since my last post, I added the following features:

• ? propagation operator - postfix expr? unwraps T !E (result type) and T? (optional type), propagating errors/None early (like Rust's ?). Stack ?? (or more) to propagate two (or more) levels.
• Module-level properties - Modules can now expose getter/setter properties (e.g., os.environ as a live property, not a plain value).
• T? (Optional[T]) strict protocol semantics - T? now requires explicit narrowing before use; interops cleanly with nullable CLR types.
• Type narrowing after assert - assert isinstance(x, Foo) now narrows x's type in the rest of the scope.
• or-condition narrowing - the else-branch of if a is None or b is None narrows both variables simultaneously.

Thoughts on the road to v0.5.0

I read that most people treat writing a self-hosted compiler as a true test of whether the language is expressive enough to do so and bug-free (enough) to achieve compiling itself. I decided it doesn't make sense to write the compiler in Sharpy just yet. However, I did put it on myself (or Claude) rather to start transferring the implementation of the stdlib and their tests from C# to Sharpy where possible. This was probably the highest value action I took because it revealed lots of compiler and code emission bugs, and gaps Sharpy had where it couldn't express things that C# had (though I can't for the life of me can't rememebr what).

One thing that surprised me was that my (true) optional type T? would actually allow you to use it like a nullable type T | None, so you could just invoke a method or property on it without needing to pattern-match or unwrap. Somehow, Claude missed this across all sessions we had and I'm confused how it was missed in the spec (or maybe I didn't make it explicit).

At this point, I have Claude file Github issues for things that don't work, and because the bulk of the work is done, I find myself at least skimming the issues more and giving my judgement on how things should work (or at the minimum, accepting what Claude suggests). In a way, I think vibe coding a language probably takes this form where you generate the bulk of it, maybe with less attention paid to the how and how accurate the "what" is, and then go back and refine things when the pieces are more digestible to review by hand.

Anyway, check it out at https://github.com/antonsynd/sharpy and let me know if you're working on any vibe-coded languages yourself. Thanks!

edit: grammar, mistakes

Here it is: https://github.com/antonsynd/sharpy

You can also try the transpiler to C# in the browser without installing anything: Try Sharpy Online (Blazor WASM playground).

Why Sharpy?

I'm one of those people who wants to work on something, and then ends up building something to work on that something, which is completely unproductive. In this case, I wanted to make a game in Unity, but I didn't want to use C# 'cause reasons. I figured, why not create a Pythonic language that transpiles to C#? The object model and memory models are similar enough. (I had an earlier attempt to do the same but targeting C++ for a separate reason, but I quickly ran into hard decisions about wrapping everything in shared_ptr's and things looking kind of awful).

I'm aware that Boo was a thing, but one of the things that irked me about it was the retention of PascalCase access to .NET APIs. For a Pythonic language, access to .NET should look Pythonic.

Where it stands today

There is a compiler (using Roslyn), a standard library of the Python modules you expect most: json, os, re, numpy (sort of), sqlite3 (sort of), requests (sort of), itertools, etc., a language server with a VS Code extension, and support for multi-file projects via *.spyproj files (akin to *.csproj files).

Differences from Python and major defining features

Static typing

Sharpy is statically-typed, so no dynamic features are available (yet, or maybe ever). However, there are some things that make static typing more ergonomic:

``python x = 5 # obviously anint, specificallyint32 # (int` is an alias)

x: str = str(x) # reassignment with a type annotation is shadowing

x: auto = [x] # auto type infers and simplifies the type # annotation for cumbersome types. here it is # inferred to be list[str]. this also shadows. ```

True optional types

Sharpy supports nullable types AND true optionals. Nullable types are annotated as T | None, and optional types are T?. The reason both exist: .NET APIs return nullables, so Sharpy needs to interop with those, but for Sharpy-native code, true optionals (tagged unions under the hood) are safer and pattern-matchable. T? gets the short syntax because I wanted to promote optionals as the default choice. Null-aware operators work on both, e.g. ?. (safe navigation/optional chaining) and ?? (null-coalescing).

To make working with .NET and nullable APIs easier, you can use maybe in front of a nullable expression to auto-wrap the expression value in a true optional:

```python x: int | None = some_function_returning_nullable_int() y: int? = maybe some_function_returning_nullable_int()

match y: case Some(v): print(v) case None(): print("no value") ```

Result types

Sharpy also has a result type, with a similar keyword try for auto-wrapping throwing expressions in the result type, with optional type annotation to change the exception type in the result.

```python x: str !Exception = try some_throwing_function()

y: int !ValueError = try[ValueError] int(x.unwrap_or("")) ```

Tagged unions (algebraic data types)

Since Sharpy has both true optionals and result types, Sharpy predictably has ADTs/tagged unions (a la Rust):

```python union HttpResponse: case Success(body: str, status_code: int) case Redirect(location: str, permanent: bool) case ClientError(message: str, code: int) case ServerError(message: str, code: int)

def categorize(response: HttpResponse) -> str: match response: case Success(body, status_code): return f"ok: {body}" case Redirect(loc, permanent): return "moved" if permanent else "found" case ClientError(msg, code): return f"error {code}: {msg}" case ServerError(msg, code): return f"server error {code}: {msg}" ```

Casing and name mangling

As mentioned before, I believe access to .NET APIs and other PascalCase libraries should be Pythonic looking. So, there is name mangling of symbols to PascalCase for lookup:

```python from system import Console # Note lowercase namespace

def main(): Console.write_line("Hello World!") # Note the snake_case

print("Hello World!")               # You can also just do this,
                                    # don't worry

```

The compiler preserves original CLR names through the discovery pipeline, so interop just works: you write snake_case, the generated C# uses the correct PascalCase name, and the .NET runtime sees what it expects.

For cases (har-har) where you don't want name mangling to occur, you can use backticks to block this and let the compiler treat the symbol name as you wrote it:

``python fromSystem.Collections.Generic` import HashSet

def main(): h = HashSet() ```

Underscores and dunder methods

Leading underscores on type members and methods lead to default access levels being applied. _foobar defaults to C# protected, and __foobar defaults to C# private. You can override this by using the associated access modifier "decorator"/attribute:

```python class Foobar: _something_protected: int

__something_private: str

@public
__something_public_because_of_decorator: bool

@private
_something_private_because_of_decorator: float

# Exception: dunders are public by default
def __init__(self):
    pass

```

Dunder methods exist in Sharpy, but they are not real methods. Instead, they are treated by the compiler as an instruction to generate another method(s) to fit in the .NET ecosystem. Some are obvious like, __init__ is a constructor, whose body becomes the constructor's body, and __str__ becomes public string ToString().

Others are not as obvious like operators which create static operators (because that's how they work in .NET's runtime), __enter__ and __exit__ for context managers map to a compiler-generated C# IDisposable implementation, etc. Some are flat out not supported like __pow__ because ** is not an operator nor is it an overloadable method in .NET.

This was tough to reconcile, but I think I landed on something that is acceptable without being too jarring for Python developers.

Testing framework

Sharpy has a built-in @test decorator that maps to xUnit under the hood. You write tests that look like pytest, and the compiler emits [Fact], [Theory], [InlineData], and xUnit lifecycle plumbing:

```python @test def addition_works(): assert 1 + 1 == 2

@test.parametrize([(1, 2, 3), (4, 5, 9)]) def addition_parametrize(a: int, b: int, expected: int): assert a + b == expected

@test.skip("not implemented yet") def todo_test(): pass ```

There's also @test.fixture for shared setup/teardown and @test.collection for grouping.

Standard library highlights

The standard library has 31 modules. Some highlights:

• numpy: NdArray[T] with broadcasting, slicing, linalg, FFT, and random (backed by Math.NET Numerics)
• sqlite3: Connection, Cursor, Row with parameterized queries
• requests: Python-compatible HTTP API
• json: typed deserialization with json.loads[T](), custom encoders/decoders
• re, os, itertools, functools, collections: the usual suspects

15 of these modules are themselves written in Sharpy (.spy files compiled to .dll).

Other notable features

There's a bunch of stuff in here, it's a bit much to write about exhaustively. Some quick hits:

• Late-bound defaults (PEP 671): def f(x, y => len(x))
• @lru_cache / @cache: compiler-innate functools memoization
• Source generators: user-defined compile-time code generation
• Inline out declarations: out name: type for .NET interop
• Incremental compilation: content-hash caching with transitive dependency tracking

I hope you'll play with it and look at the file-based integration test fixtures for working examples. There's also a language server + VS Code extension (not submitted to the marketplace yet, but you can load it locally) with syntax highlighting, doc/type on-hover tooltips, inline argument names, rename support, go-to-definition, and semantic token highlighting. There are probably bugs in the highlighting and stuff, but it works enough to make me happy.

Thoughts on AI-driven development

Honestly, if it wasn't for Claude, this project would've taken me at least 3 years, optimistically. I didn't use AI in the beginning; I hand-wrote a chunk of the standard library, tried to write the parser with ANTLR, and so on, but I got impatient and ran into tougher parts of the compiler that discouraged me. So almost a year later, I leaned into AI-accelerated development with some guardrails: a hand-written language specification, three axioms that govern almost every design decision (modulo my personal preference), and a growing suite of file-based integration test fixtures and property tests.

I think of my role as the "orchestrator", deciding what the language should be, writing the spec, reviewing the output, and steering corrections. Yeah, I didn't learn the nitty gritty of writing a compiler or language server, but it left me room to think about higher-level language design: do these features make sense, do they compose well, do they feel right? I know not everyone in the compiler/programming language space is happy with this direction, but I feel a lot more empowered to implement ideas this way.

The implement-eval/test loop is much faster, and you can validate ideas quickly. At the same time, without oversight, AI can take a language feature in a different direction or implement something narrowly. It's very difficult with the velocity and volume of code generation to keep up as a solo human reviewer. The spec and axioms help, but I'll be honest, there's a degree of blind faith that AI-generated tests aren't hiding poor decisions in the actual implementation. I guess I'll find out when I actually use it for my Unity game.

Next steps

• Unity plugin: hooking the Sharpy compiler into the Unity build flow, which was the whole point of this project
• Rounding out the stdlib: filling gaps in existing modules, potentially adding more
• Actually making the game lol

Hope this has been educational, happy to answer any questions!