Show HN: The Mog Programming Language
61–70 of 91 posts
Re: Show HN: The Mog Programming Language
#62Re: Show HN: The Mog Programming Language
#63I am disappointed at the amount of negativity here. HN generally loves an experimental domain-specific language, no matter how janky. To be clear, I don't know if this is janky, but the knee-jerk anti-AI sentiment is not intellectually stimulating.
Re: Show HN: The Mog Programming Language
#64This language could mog the ASU frat leader into a career ending cortisol spike. Clav finally has some clapback after getting trolled by an foids all day.
Re: Show HN: The Mog Programming Language
#65If anthropic makes "claude-script", it'll outmog this language with massive RL-maxing. I hope your cortisol is ready for that.
If you want to try and mog claude with moglang, I think you need to make a corpus of several terrabytes of valid useful "mog" programs, and wait for that to get included in the training dataset.
Re: Show HN: The Mog Programming Language
#66A limited plugin API is interesting in some ways, but it has "rewrite it in Rust" energy. Maybe it's easier to flesh out a new library ecosystem using a coding agent, though?
Re: Show HN: The Mog Programming Language
#67Earlier quoted context omitted.
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.
> given there is no training dataset, any other language would work better with AI. I guess it depends on what "would work better" really means, but I don't think it's always a given. I've made my own languages, there is no available training set on exactly those, but AI with a prompt can figure out how to effectively use them as much as any other language, it seems to me. I guess it helps that most languages are mor…
I can tell an llm "write hello world in C", and it will produce a valid program with just that context, without needing the C language spec nor stdlib definition in the context window because they're baked into the model weights.
As such, I can use the context window to for example provide information about my own function signatures, libraries, and objectives.
For a language not well-represented in the training data-set, a chunk of my context has to be permanently devoted to the stdlib and syntax, and while coding it will have to lookup stdlib function signatures and such using up additional context.
Perhaps you're trying to argue that the amount of tokens needed to describe the language, the stdlib, the basic tooling to look up function signatures, commands to compile, etc is not enough tokens to have a meaningful impact on the context window overall?
Re: Show HN: The Mog Programming Language
#68I 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.
Re: Show HN: The Mog Programming Language
#69It feels like a custom defined DSL (domain specific language) problem.
Models are good at generating code that already have a large corpus of examples, documentation, and training data behind them. A brand new language may be good for LLM to speak on, but it is hard for LLMs to produce it reliably until it becomes widely used. And it is hard for it to become widely used until models can already produce it well.
Re: Show HN: The Mog Programming Language
#70> 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.
how do you mean? given that spec, ambiguous code just won't compile. that could potentially be inefficient, but not a foot gun.