Live data from Hacker News

Show HN: The Mog Programming Language

moglang.org

61–70 of 91 posts

Re: Show HN: The Mog Programming Language

#63

I 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.

If you think this is bad, visit Lobsters.

Re: Show HN: The Mog Programming Language

#65
I think the AI labs need to be the ones to build AI-specific languages so they can include a huge corpus in the model training data-set, and then do RL on it producing useful and correct programs in that language.

If 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

#66
Coding agents gain a lot of power from being able to download specialized utility programs off the Internet, using apt-get or whatever. So it seems like running in a VM is going to be more popular?

A 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

#67

Earlier 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…

To me it seems like a pretty strong given because context windows are an important thing.

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

#68

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.

But typescript is already trained in every model, and needs no additional work.

Re: Show HN: The Mog Programming Language

#69
I wonder if lack of code as a training/example dataset for LLMs could be a problem to produce well enough Mog code reliably.

It 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
post #32

> 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.

> 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.

Post reply on HN