ret2pop

oh yeah, Urbit; I'm quite aware of the project and can recognize that to some I might just be explaining it in an intentionally confusing manner, perhaps. I do think the original intent of Urbit was to naturally select nerds, basically (I mean Curtis Yarvin talking about the old UseNet made it really seem like it), and no, that was not the intent here. It literally is just hard to figure out how to communicate the core concepts of Cognition and why we wanted it to be that way.

Writer of this article here.

It was never meant to be a pot-shot, and I have nothing against lisp. I can tell why it reads that way, and we added that in because we wanted to illustrate why people should care.

As to your claim about us being wrong: I don't have an issue with being wrong, and maybe at the same time we are. At the same time, I think it is possible that there are misunderstandings that cause people to believe we aren't doing something new. Again, maybe we're not.

We're two 18 year olds, fresh out of high school. It's a research project, but we're not graduate students.

A lot of these comments are claiming it's not new because reader macros exist. From my understanding, our tokenization system is unique because it can all be done at runtime without backtracking or executing anything instantly, which is possible because cognition always makes use of the text read in, and never makes use of anything not yet read in, which means you don't have to backtrack. I mean, you could backtrack but it would be less elegant.

If I'm wrong about this then that's fine but then we still made something cool without even knowing it existed beforehand.

ding! I think the bootstrapping code might've bitten us. Of course there's no practical reason why we _needed_ to not have the delim flag flipped and a couple of delimiters defined, but there's a conceptual symmetry in it being the way it is. Still, I agree in large part with your point.

It seems as though you've read the entire article and understood a decent portion of it. I'm impressed because I think I explained this suboptimally.

Self explanatory grammars: there's the stem-like syntax that I showcase and you could write a lisp like syntax in it pretty easily. I'd imagine you don't want to use this in production yet. As for self explanatory bootstrap code: the bootstrap code is the way it is because cognition doesn't want to assume some complex syntax from the start.

There's a lot to explain, and it has occurred to me that I have explained it in a suboptimal manner. Writer of this post, by the way. The problem is that there is just so much to communicate (the design for this language with Matthew took 3 weeks of back and forth communication over several hours a day). A lot to fill in for people that don't know me in real life.

Yes, although then at that point you'd be writing your own parser and interpreter basically, which Cognition automates to some extent

Oof. I'll fix that in some time.

Thanks for your feedback! I'm not accusing you of not reading the full article, but you should if you haven't already. Also, we don't know the extent to which we made anything new; if you think you can do what we're doing in lisp in some way, you're free to prove us wrong.

Writer of this article: Thank you! I don't mind the snakry comments. In fact, I welcome them as I think they are pretty funny themselves. We'll most certainly be working on more dark magic in the future.

Indeed. I am the writer of this blog post and Matthew and I never intended for this to be a joke. In fact, we thought we had programmed something unique that nobody had done before, and the bootstrapping code syntax is minimal by design (you don't want to assume a default complicated syntax).

Hi, I'm the one that wrote this blog post! A lot of comments treat this project as a joke or some form of satire, but we've spent 3 months writing this after initially coming up with the idea because we thought nobody had created such a general programming language before. It's good to get some feedback and maybe we've been in our own heads for a little too long, but it's good that someone gets it.

recursive descent parsers generally work by doing something in the future based on the current token read, whereas Cognition works by getting a single token and then evaluating it or putting it on the stack based on the crank. If you think of syntax structure as if it is the AST itself then I can understand your confusion, but this is not the main point of the article anyways, and what I meant by this is simply that programming in some rigid way by which you read ahead based on the current token means you have something that's unchangeable in the interpreter design.

That said, I don't know if Cognition is unique. If you know of something that can do the same thing as this, be free to send that project our way.