Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Om Programming Language

om-language.com

Post reply on HN
Print view View original

111–119 of 119 posts

Re: The Om Programming Language

#111

Post by dev_l1x_be »

ryanmcl wrote: post #86
fcatalan wrote: post #71

Earlier quoted context omitted.

A few days ago I asked Claude what kind of language it would like to program in, and it said something like Forth but with static typing, contracts, and constraint solving, implemented on the Erlang BEAM. So I have been prodding Claude Code for a few sessions to actually do it. It's a silly experiment, but fun to watch. Right now it's implementing a JSON parser in the generated language as a kind of milestone example…

[dead]

If you want to go really meta ask Claude Code to re-implement itself in the new language. You could keep going doing this.

Re: The Om Programming Language

#112

Post by fcatalan »

dev_l1x_be wrote: post #111
ryanmcl wrote: post #86

Earlier quoted context omitted.

[dead]

If you want to go really meta ask Claude Code to re-implement itself in the new language. You could keep going doing this.

It kind of feels like it wants to go there or thereabouts, but to be honest, I just half understand half of the roadmap it has written for itself:

  - **v0.0.1** (complete): Interpreter, PRE/POST contracts, REPL, TIMES/WHILE, FILTER/MAP/REDUCE, strings, I/O
  - **v0.1.0** (complete): Static type checker, VERIFY (property-based contract testing), maps, Safe Bank milestone
  - **v0.2.0** (complete): PROVE — compile-time contract verification via Z3 SMT solver
  - **v0.3.0** (complete): Algebraic data types (TYPE/MATCH) — Option, Result, and user-defined sum types with exhaustiveness checking
  - **v0.4.0** (complete): JSON parser/encoder milestone — wildcard MATCH, string primitives, ROT4, PAIRS, NUM_STR, VERIFY for sum types
  - **v0.4.1** (current): PROVE for IF/ELSE branches (via SMT-LIB `ite`), ABS/MIN/MAX, function call inlining
  - **v0.5.0** (next): Practical language features — LET bindings, IMPORT/modules, error handling, standard library
  - **v0.6.0**: PROVE for MATCH/algebraic types, refinement-style reasoning
  - **v0.7.0**: Typed BEAM concurrency (typed message passing, stateful actors)
  - **v0.8.0**: BEAM bytecode compilation
  - **Future**: Declarative constraint solving, tensor/distribution primitives, multi-agent collaboration
I'd say the sky is the limit, but in fact the limit is the stingy token budget of the 20€ Claude sub...

Re: The Om Programming Language

#113

Post by phailhaus »

dmit wrote: post #110
phailhaus wrote: post #108

Earlier quoted context omitted.

Those are both formatting examples though? You're suggesting totally different syntaxes , which means you can't even point to the same line in a codebase when talking about a PR. This throws up massive hurdles around communication when you could just agree on one standard and move on.

class Bean { private boolean sprouted; public void sprout() { this.sprouted = true; // ... } } or data Bean = Dormant | Sprouted sprout :: Bean -> Bean sprout Dormant = Sprouted sprout Sprouted = -- aw, beans, we could have modeled -- this state as impossible to construct, -- but you chose runtime checks, so -- here we are. As for pointing to the source line, I think JavaScript people solved that one for us with sour…

Oh lord, yeah this convinces me even more that this is a bad idea. I can't even tell at a glance if those do the same thing. Just pick one and move on, you're requiring everyone to pass around sourcemaps literally everywhere they go, one for every single pair of syntaxes. You can't even talk about the code with the same language with each other. Is Bean a "class" or a "datatype"? If I'm using one syntax, how do I tell you to fix a bug in your syntax?

Re: The Om Programming Language

#114

Post by dmit »

phailhaus wrote: post #113
dmit wrote: post #110

Earlier quoted context omitted.

class Bean { private boolean sprouted; public void sprout() { this.sprouted = true; // ... } } or data Bean = Dormant | Sprouted sprout :: Bean -> Bean sprout Dormant = Sprouted sprout Sprouted = -- aw, beans, we could have modeled -- this state as impossible to construct, -- but you chose runtime checks, so -- here we are. As for pointing to the source line, I think JavaScript people solved that one for us with sour…

Oh lord, yeah this convinces me even more that this is a bad idea. I can't even tell at a glance if those do the same thing. Just pick one and move on, you're requiring everyone to pass around sourcemaps literally everywhere they go, one for every single pair of syntaxes. You can't even talk about the code with the same language with each other. Is Bean a "class" or a "datatype"? If I'm using one syntax, how do I tel…

> If I'm using one syntax, how do I tell you to fix a bug in your syntax?

How about "Hey, your Bean ain't sprouting"? :)

I'm sorry, I feel like I'm not communicating this properly. Um, have you ever discussed with someone a book or a TV show that was translated into your language? Did you have problems referring to the exact parts you liked or disliked? :)

Re: The Om Programming Language

#116

Post by fuzztester »

fuzztester wrote: post #94
itishappy wrote: post #87

Earlier quoted context omitted.

Love this take! Unison is exactly this, and it's awesome! Here's a quote from one of the creators: > But here's the super cool thing about our language! Since we don't store your code in a text/source code representation, and instead as a typechecked AST, we have the freedom to change the surface syntax of the language very easily, which is something we've done several times in the past. We have this unique possibili…

Can Raku do something like this? I was lightly exploring it recently, and I thought I saw that something like this may be possible with it.

thanks, all.

Re: The Om Programming Language

#117

Post by pgt »

jhoechtl wrote: post #89
pgt wrote: post #25

Would recommend placing example language syntax above the fold. Was tough to have to scroll halfway down the entire site to see any syntax. Nobody cares about the EBNF syntax until they have a feel for the language.

Last commit is from 2 years

Ah, thought it was new.

Re: The Om Programming Language

#119

Post by pooploop64 »

pgt wrote: post #25

Would recommend placing example language syntax above the fold. Was tough to have to scroll halfway down the entire site to see any syntax. Nobody cares about the EBNF syntax until they have a feel for the language.

Almost every site for a new language that gets posted here does this. Every time someone points out how they don't care about anything until they've seen what code actually looks like. I'm surprised this still happens.
Post reply on HN