I haven’t worked on Sharpee in a few weeks because I’ve been learning other things, namely React and TypeScript.
One of my goals with Sharpee was to see how much I could get done using GenAI and that has had diminishing returns, though I’m getting better at extracting more and more.
After building a few web things using GenAI (Claude Sonnet 3.5) I’m starting to believe it may be “better” at TypeScript than C#. Maybe because the amount of public TypeScript code is larger than C#?
So now I’m wondering if I should switch gears and build Sharpee in TypeScript. The one major benefit would it being browser or CLI based and very easily cross-platform.
Typescript or C#?
a) Can Typescript run on .NET Core?
b) C# seems a more general language. What could be the benefit of Typescript? (Maybe runnning in browsers?)
I’m too pragmatic to dismiss the usefulness of GenAI. I would never have it paint a portrait or write poetry, but as a code-generation assistant it is transformational. If you’re in the coding world as a worker, you would be foolish to dismiss it. I had Claude build https://david.cornelson.net/ in like an hour. No way I’m doing that on my own.
TypeScript will run in any browser or through NodeJS (CLI). Theoretically you could share a small package with game players that included an index.html file and a compressed JavaScript file (compiled from TypeScript) and compressed CSS file and it would work anywhere.
The capabilities I had outlined for Sharpee are still things I can construct and leverage in TypeScript. There is a linqts library that mimics what C# Linq offers. The in-memory graph might be challenging.
I’m a hobby programmer so I don’t know about pushing out large amounts of code under time limit. Can’t confirm or deny the usefulness of this tool, and I admit it’s a tool.
I think TypeScript has a lot going for it from an ecosystem standpoint. It can run on many platforms, both in or out of a browser, and GlkOte already exists so you won’t have to roll your own frontend. I considered doing Bedquilt this way and didn’t reject it for any compelling reason; it was just that my Rust->WASM->Glulx has similar advantages and I like Rust more than I like TypeScript. So I’d be pleased for someone else to travel the road I didn’t and report on where it leads.
A design note. I am not targeting the glk/glulx arena. Any resulting story will either be a C# executable or if I do switch to TypeScript, both web delivery and NodeJS download and it will be “all in one”. I will be developing the template(s) for emitting world model state changes every turn.
I just had a session with Claude talking through the pros and cons of switching to TypeScript and sharing most of my C# code and design assumptions.
Claude showed that TypeScript would be significantly better, and it showed what some of the new code would look like.
It also killed my design assumption of needing an underlying graph data store, saying it was overkill (thanks Claude).
I dug into the world model, grammar, parser, localization, text templates, fluent code, and how the author could use two LLMs (general model and a Sharpee specific model) working together to design their story in text and have the TypeScript code emitted for the design.
There are some pretty nifty things that would make TypeScript a very interesting design change. The one thing I do believe is true is that Claude specifically seems to understand how to write TypeScript far better than C#. I wonder why.
(addendum)
I asked Claude and it ranked python and js/ts as it’s two primary programming language skills. C# is in the middle, so my intuition was spot on.
I understand you’re not targeting Glulx — and there’s no need to, because JS already has a portable VM — but it seems like you’re committing yourself to more work than necessary if you don’t plan to take advantage of GlkOte.
If you want to support save/restore/undo, you’ll need a structured data store of some sort, and to get the event stream working correctly you’re going to need an especially principled approach to it. None of this requires that it be a graph store, but what do you intend to do instead?
I’m partial to C# myself, but largely because I’m not too thrilled with what has happened to native desktop software. The modern slogan which gets thrown at anyone who is even remotely interested in writing a Desktop app has been “just do it in Javascript, the whole world runs on Javascript now”, and that’s how we get electron apps that gobble up RAM like Pacman eats ghosts. Now, I will say I don’t have an issue with JavaScript or Typescript itself, or even Node, but to dismiss everything else just to try and shove everything into the JS ecosystem is insane, and frankly, makes desktop and even mobile software worse IMHO. Also, I don’t trust AI, so there’s that.
Regardless, I hope the development of Sharpee goes well, no matter what language you use to build it. Also, I’d recommend either Tolk or Universal Speech, if you go the C# route, which would be an easy way to make the interpreters accessible to screen reader users.
There are clear React patterns and libraries for screen reader support and I would 100% implement that.
One of my goals is to do this using GenAI as much as possible, so if Claude has a measurably stronger code generation ability with TypeScript, then it bears investigation. I did some of that investigation last night and I think Claude has me convinced that my over-arching goals are more approachable in TypeScript than C#.
The one thing I’m waffling on is inline-debugging, something C# in Visual Studio is obviously brilliant. You can inline debug Typescript, but it’s not quite as accessible as C#. It’s a nitpicky preference, so I probably won’t let it sway my plans to change.
GlkOte is really meant to mimic the glk library in a browser. After having worked on fyrevm-web for a few years, I believe working with a react app as a front-end to Sharpee will work just fine.
I have no answer (yet) for what replaces the graph data store. Claude seemed to think using Map(), Reduce(), and other built-in functions can easily replace the graph. But this definitely requires R&D and the requirement that “state” is easily saved somewhere.
I don’t think Claude is considering the whole scope of the problem. I’m a lot more enthusiastic about generative AI than most on this forum but I would never go to an LLM for this sort of architectural advice. They’re great tools if you think of them as junior coders that you’re closely supervising, but you shouldn’t let their judgement override your own. In this case I think you were already on the right track with the graph store.
I would normally agree with this assessment, but when you narrow the research to “how would this work using this pattern,” you actually get excellent responses. You can then stack similar questions to determine a good approach.
(Just my opinion)
