In my prompting framework I have a workflow that the agent would scan all the artifacts in my closed/ folder and create a yyyymmdd-archive artifact which records all artifact name and their summaries, then just delete them. Since the framework is deeply integrated with git, the artifact can be digged up from git history via the recorded names.
No. Not yet, anyways. I maintain autonomy over source control at the moment. Headless activity is verified in a separate unity editor instance before I push any commits. I might look into source control tools once I get through perspective and orthographic screenshot tools. Giving the agent a way to see the final composed scene seems much more valuable than SCM automation right now.
This is a bit concerning. Did you skip everything besides "yogurt delivery", or you don't agree someone talking to you regularly is counter-loneliness?
I'm not sure what this question was meant to convey.
There are many countries (or cities) in the world where you can easily get by in English beacuse almost everyone you need to / want to interact with can speak English. Amsterdam, Paris, Berlin, Stockholm are 4 the come to mind even though their native languages are Dutch, French, German, Swedish.
Japan is not one of those countries. Yes, you can survive without speaking Japanese with a lot of effort and asking friends to translate.
So it's not an unreasonable question to ask if they speak English. It's effectively asking, are they liked the 4 cities mentioned above.
I was once at a bar in Tokyo and where I met a young French woman who was thrilled to be going back to France after 6 months in Japan. She had wrongly assumed the her English would get her by like it had in many other countries who's first language was not English.
The question labeling a whole ethnic can't understand English rubbed me the wrong way, that's about it. This is a much better comment for understanding your rationale.
In the past 2 months I've been using all the SOTA models to help me design a new DSL for narrative scripting (such as game story telling) and a c# runtime implementation o the script player engine.
The language spec and design is about 95% authored by me up to this point; I have the LLMs work on the 2nd layer: the implementation specs/guidelines and the 3rd layer: concrete c# implementation.
Since it's a new language, I consider it's somewhat new/novel tasks for LLMs (at least, not like boilerplate stuff like HTTP API or CRUD service). I'd say, these LLMs have been very helpful - you can tell they sometimes get confused and have trouble to comply to the foreign language spec and design - but they are mostly smart enough to carry out the objectives, and they get better and better after the project got on track and has plenty of files/resources to read and reference.
And I'd also say "prompt better" is a important factor, just much more nuanced/complicated. I started with 0 experience with LLM agents and have learned a lot about how to tame them, and developed a protocol to collaborate with agents, these all comes from countless trial and errors, but in the end get boiled down to "prompt better".
I wonder if my intuition here is correct; I would posit that “PL implementation” is a far more popular and well-explored field than it seems. How many toy/small/labor-of-love langs make it to Show HN? How many more simply don’t?
I’ve never personally caught the language implementation bug. I appreciate your perspective here.
I totally agree, and I was fully aware of how common people make language for fun when I replied.
But I feel like the rationale would still stands: Considering LLMs' natures, common boilerplate tasks are easy because they can kind of just "decompress" from training data. But for a new language design, unless the language is almost identical to some other captured by the model, "decompression" would just fail.
As someone who has implemented a fair few DSLs, lexical and syntactic analysis is pretty much the same anywhere, and the structure of the lexer/parser does not really depend on the grammar of the language.
And even semantic analysis is at least very similar in most PLs. Even DSLs. Assuming you're using concepts like variables and functions.
When it comes to codegen / interpreter runtimes, things start to diverge. But this also depends on the use case. More often than not a DSL is a one-to-one map to an existing language, with syntactic sugar on top.
The points you brought up all are valid. Lexer, parser and general concepts are not language-specific, yes, and I wasn't talking about how the implementation is different.
When I said "you can tell they sometimes get confused and have trouble to comply to the foreign language spec and design", I was thinking about the many times they just fail to write in my language even when provided will full language specs. LLMs don't "think" and boilerplate is easy for LLMs because highly similar syntax structure even identical code exist in their training data, they are kind of just copying stuff. But that doesn't work that well when they are tasked to write in a original language that is... too creative.
I am prompting better. It doesn't help the LLM be more productive than me on a regular tuesday.
Sure, I can get the task done by delegating everything to an agentic workflow, but it just adds a bunch of useless overhead to my work.
I still need to know what the code does at the end of the day, so I can document it and reason about it. If I write the code myself, it's easy. If an LLM does it, it's a chore.
And even without those concerns, the LLM is still slower than me. Unless it's trivial boilerplate, in which case other tools serve me better and cheaper.
I'll note that a compiler is one of the most well understood and implemented software projects, much of it open source, which means the LLM has a lot of prior art that it can copy.
reply