ret2pop

A sibling post: https://blog.kleisli.io/post/dependent-types-in-pure-nix

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.

To be more specific, it makes whatever you read ahead tokenized already. If you read the full article it becomes more clear.

To be fair, I am inexperienced. I haven't done much programming in stack based languages and I don't often like to pull the age card but in my defense I have not lived as long as some other people on here as I just turned 18 and have not been programming for that long. Still, it's really cool that some people like my language, and it doesn't really bother me that some people think it's worse -- I just wrote it because I thought it was interesting.

factor seems to be doing pretty well, and so is of course forth.

Hey thanks! I didn't think people would actually care about this lol

yes, i have actually thought about this solution independently, but i still find it a little bit ugly to have to tell the parser that everything past a certain point is runtime, if I am understanding this correctly.

Intepreted... right now. There isn't a vm currently, but I'm planning to do native compilation pretty soon, as I already have an idea of how I would go about doing it.

I was not aware of this, thanks for giving me an explanation. I don't have any experience writing in forth, my friend described this type of language to me and I implemented it.

I am not generally knowledgeable about Forth and languages like it because the only experience I have writing in anything close to forth is in my own language. Thanks for explaining.

I've updated the blog to include a short explanation of it.

Writing that part right now

correct me if I am wrong, but from my knowledge concatenative programming often assumes a different syntax for defining words. Usually it looks something like : add a b + ; if I am not mistaken.

Yes, you are correct. My friend made this post so I didn't have control over the exact wording. That being said, in concatenative programming, the stack is public and, in my case, is virtual.

I'm kind of just using words. You can call it whatever you want, I just used words that my friends also used to describe what I wrote. Really, loading custom libraries from C is really easy but I decided to advertise that part of the project anyway.

Yes. I have realized this. I added a meta tag to the website recently, I don't know if that solves the problem. I don't know much about css really.

Edit: temporary fix of simply hiding the sidebar. lol.

I decided to undertake the project after my friend Matthew Hinton introduced me to stack based programming -- he claimed that they were elegant because they allowed for both easy metaprogramming and side effects, to which I agreed after writing a little bit of my own language. It was really easy to implement, too -- most of it took only one day, and getting the basic functionality working took only 2-3 days.

Goals -- I eventually want to write an emacs-like text editor in stem by writing a C library that does bindings for ncurses. I think it would be fun, for one, and I think it would not be that hard of an end product to make. I also had plans of writing a stem compiler, and I already pretty much know how to do that, but there are a couple of difficulties in doing that. Namely, right now, there is no way of telling the difference between compile-time and runtime operations, which will slow the language down considerably. My solution to this currently is basically "interpret once, run binary forever", but the details are still need to be worked out.

Problems it solves -- to be honest, you can really do anything in any programming language, but this langauge aims to be a higher level rendition of stack based programming languages, mostly for scripting and creating abstract representations of things.

Note that I am still trying to write in a couple things, namely, an actual include statement as a builtin that reads from some predetermined standard include directory, and an OOP implementation using metaprogramming in the standard library.

Not to mention the fact that I have been really interested in writing programming languages since I was in high school. One interesting thing about stack based languages is that the AST need not be generated at all. I taught myself a lot of linguistics, specifically generative grammar, as a result of attempting writing various programming languages in the past, and so these types of projects are just interesting to me.

If you ARE looking for one unique thing about this language, though, it is that `def`, the method by which you define functions, is itself a word. I don't think a lot of stack based languages do this (because it is much harder to compile languages like this as mentioned above), but it offers much more internal consistency within the language as a result.

really cool project! (I am definitely not the person who made this)