51–60 of 91 posts
I looked at the brainrotty name[1] and instantly assumed AI slop, but I'm glad the website was upfront about that. [1] https://www.merriam-webster.com/slang/mog
I like the looks of this, and the idea behind it, but TypeScriot via Deno is an audited language with a good security model, a good type system, and sandboxing in an extremely well-hardened runtime. It's also a language that LLMs are exceptionally well-trained on. What does Mog offer that's meaningfully superior in an agent context? I see that Deno requires a subprocess which introduces some overhead, and I might be…
It's a legitimate question to ask about any new language post AI - given there is no training dataset, any other language would work better with AI. The bigger problem is maintainability over the long term, Deno is built by Node.js creator and is maintained for half a decade now, that's hard to compete with. In a way it's much more about social trust rather than particular syntax.
It's expensive of course, but if a new language is genuinely better for LLMs to write and understand, that would not be an issue.
I’m still waiting for someone to build a good lisp harness. Stick an agent in a lisp repl and they can change literally anything they want easily.
> String Slicing > You can extract a substring using bracket syntax with a range: s[start:end]. Both start and end are byte offsets. The slice includes start and excludes end.
Given that all strings are UTF-8, I note that there's not a great way to iterate over strings by _code point_. Using byte offsets is certainly more performant, but I could see this being a common request if you're expecting a lot of string manipulation to happen in these programs.
Other than that, this looks pretty cool. Unlike other commenters, I kinda like the lack of operator precedence. I wouldn't be surprised if it turns out to be not a huge problem, since LLMs generating code with this language would be pattern-matching on existing code, which will always have explicit parentheses.
I like the looks of this, and the idea behind it, but TypeScriot via Deno is an audited language with a good security model, a good type system, and sandboxing in an extremely well-hardened runtime. It's also a language that LLMs are exceptionally well-trained on. What does Mog offer that's meaningfully superior in an agent context? I see that Deno requires a subprocess which introduces some overhead, and I might be…
I cannot comment on the new language, but Typescript is a huge spec. Yes, it has guardrails, but there is a lot of complexity to handle. Something purpose built to enable embedding allows it to be used in more contexts. Maybe I want a Mog plugin for my latest video game. Embedding JS is possible, but no fun.
I didn't mean to suggest there's no need for Mog either. I love to see developments like this. Deno is a practical solution for me today, but I see why it isn't a perfect forever-solution too.
Earlier quoted context omitted.
Or, when you have a Django project and started out on SQLite, but then begrudgingly introduce M-to-N relationships, but then suddenly notice, that many things you might want to do or implement with those M-to-N relationships are not supported by SQLite. Then you suddenly wish you had started with Postgres right away.
There are definitely some caveats / tradeoffs with SQLite, but I can't think of any that are specifically related to many to many relationships. Which features did you find missing? Lateral joins maybe?
The project is here: https://codeberg.org/ZelphirKaltstahl/web-app-vocabulary-tra... But I left it unfinished and a quick grep does not yield comments or something that explains why at some place I do something to circumvent the SQLite problems. I remember though, that I basically swore to myself, that I would not ever use SQLite in production with Django ORM. And if I am not using it in production, then testing also better should not be using it, because one should test with the same RDBMS as runs in production, or risk unexpected issues suddenly only happening in production. So SQLite is out for anything serious in Django projects for me.
> it's intended to minimize foot-guns to lower the error rate when generating Mog code. This is why Mog has no operator precedence: non-associative operations have to use parentheses, e.g. (a + b) * c. Almost all the code LLMs have been trained on uses operator precedence, so no operator precedence seems like a massive foot-gun.
Doesn't need to be its own language.
I feel like a small language designed specifically for LLM's should/will exist someday. Certainly I've found I really like simpler compiled languages with more complete memory models, I would imagine a language designed for LLM's and agents could improve workflows someday.
Earlier quoted context omitted.
Mog is AOT-compiled, not JIT'd. JIT means the code is interpreted until some condition kicks in to trigger compilation. This is obviously common and provides a number of advantages, but it has downsides too: 1) Code might run slowly at first. 2) It can be difficult to predict performance -- when will the JIT kick in? How well will it compile the code? With Mog, you do have to pay the up-front cost of compiling the pr…
Hum, IIRC, using your definition of an AOT compiler, then V8 is an AOT compiler. V8 never interprets code. It immediately compiles it to machine code. It improves it later, but it's never slow.