Live data from Hacker News

Show HN: The Mog Programming Language

moglang.org

31–40 of 91 posts

Re: Show HN: The Mog Programming Language

#31

Ran into the same thing. SQLite works until you need cold start recovery or WAL contention with concurrent agents. Built a dedicated memory layer for agent workloads - happy to share: https://github.com/RYJOX-Technologies/Synrix-Memory-Engine

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.

Re: Show HN: The Mog Programming Language

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

Re: Show HN: The Mog Programming Language

#33
Argument 1 ("Syntax Only an AI Could Love") sounds dubious. I am probably not alone in being paranoid enough, to always put those parentheses, even if I am 90% sure, that there is operator precedence. In lispy languages the ambiguity never even arises, and I put many parentheses, and I like it that way, because it enables great structural editing of code. No implicit type coercion has also been part of normal for-human programming languages (see SMLNJ for example).

> There's also less support in Mog for generics, and there's absolutely no support for metaprogramming, macros, or syntactic abstraction.

OK that does immediately make it boring, I give them that much.

Re: Show HN: The Mog Programming Language

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

I agree. But also, do people rely on operator precedence when coding? I just automatically use parentheses in general.

Re: Show HN: The Mog Programming Language

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

I agree. But also, do people rely on operator precedence when coding? I just automatically use parentheses in general.

Also for a * b + c ? I know clang tidy wants me to do this but I think it is overkill.

Re: Show HN: The Mog Programming Language

#37
post #24

Earlier quoted context omitted.

I generally agree. TypeScript is a great language, and JS runtimes have certainly had a lot of money and effort poured into them for a long time. I would add WASM to this category, as probably the closest thing to Mog. Write a program in some language, compile it to WASM, and load it into the host process. This is (probably) nice and safe, and relatively performant. Since it's new, Mog will likely not yet beat existi…

Wasm is definitely designed to be compiled, either ahead of time or JITed. Wasm interpreters are few and far between.

Huh you're right. I had worked with interpreted WASM before, which is why I thought that was more common.

WASM is a great system, but quite complex -- the spec for Mog is roughly 100x smaller.

Re: Show HN: The Mog Programming Language

#38

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 generally agree. TypeScript is a great language, and JS runtimes have certainly had a lot of money and effort poured into them for a long time. I would add WASM to this category, as probably the closest thing to Mog. Write a program in some language, compile it to WASM, and load it into the host process. This is (probably) nice and safe, and relatively performant. Since it's new, Mog will likely not yet beat existi…

Wasm is explicitly not designed for interpretation (https://arxiv.org/abs/2205.01183)

Re: Show HN: The Mog Programming Language

#39
post #36

Earlier quoted context omitted.

I agree. But also, do people rely on operator precedence when coding? I just automatically use parentheses in general.

Also for a * b + c ? I know clang tidy wants me to do this but I think it is overkill.

I would usually. Sometimes if it's like 2 * x + b, I would not, but personally, I hate chasing down bugs like this, so just add it to remove ambiguity. Also, for like b + 2 * a, I will almost always use parentheses.

Re: Show HN: The Mog Programming Language

#40

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.
Post reply on HN