Those are really good thoughts! Here are a few answers and thoughts.
* No, it won't stay AGPL. It will be just my license once a lawyer approves that license. And I have actually four licenses; it will start on the most restrictive, but I will move it to the most permissive over time as this repo becomes established and recognized. In essence, I will explicitly follow the process in [1] that tends to happen over time.
* Yay!
* Double yay! Thank you!
* Yes. This is necessary to implement DSL's in it. (My build system will use a DSL.) Also, it will have better error messages.
* Great! This is one thing that Rust is right on: mutation should not be default.
* I'm not the biggest fan of it either; that syntax will change to something better. Maybe just `push <expr>: <stack>`. I don't know. Any suggestions?
* Technically, they are not built-in; they are a part of the standard library, but point taken: there needs to be a better namespace for those standard library ones. (By the way, this means that yes, your own libraries can add context stacks for client code.)
* Function suffixes are weird, yes. I don't know what to do about that. I've waffled a bit between them and having implicit name mangling (as in C++), but that leads to ABI and interoperability issues. But I acknowledge the issue. What can I say? Language design is hard!
And to answer, your claim that you're not a language guy, you are. As a user, you are more right than me as to what is good; actual users matter more than the language designer. If you are a user, you know what's good for you, and it is my job to hit that.
Someone somewhere said that new projects can only spend a few points on "novel" things; maybe I'll have to spend one on function suffixes, or maybe it would be better to spend them somewhere else.
> But I don't think I'd want to use anything "Indie" in production anywhere, and AGPL might scare off people so it never becomes a mainstream corporate backed thing, right?
Well, I am running a business behind it, an actual real business, so it may not be corporate-backed, but it's as close as I can make it. Because I don't want a corporation controlling it.
> Seems like you'd have to really carefully make sure it fits the audience who enjoys using indie stuff if you don't plan to get corporate backing. AI free seems like a good thing for that!
Thank you! That is actually part of my plan (though I do hate LLM's).
Here's my plan: you have people at companies that write shell scripts for small tasks, right? Over time a few of those scripts get passed around, tweaked, and turned into pseudo-blessed company-wide tools.
Well, maybe one of those programmers writes Yao scripts because Yao is just better than shell. If one or more of those scripts becomes a pseudo-blessed tool, then the company now depends on Yao, and they would be wise to pay me a few grand a year for support.
IOW, you nailed my plan: target the indie audience and use it to snare the corporate one. :) You figured all of that out from the language design! You're sharp!
* No, it won't stay AGPL. It will be just my license once a lawyer approves that license. And I have actually four licenses; it will start on the most restrictive, but I will move it to the most permissive over time as this repo becomes established and recognized. In essence, I will explicitly follow the process in [1] that tends to happen over time.
* Yay!
* Double yay! Thank you!
* Yes. This is necessary to implement DSL's in it. (My build system will use a DSL.) Also, it will have better error messages.
* Great! This is one thing that Rust is right on: mutation should not be default.
* I'm not the biggest fan of it either; that syntax will change to something better. Maybe just `push <expr>: <stack>`. I don't know. Any suggestions?
* Technically, they are not built-in; they are a part of the standard library, but point taken: there needs to be a better namespace for those standard library ones. (By the way, this means that yes, your own libraries can add context stacks for client code.)
* Function suffixes are weird, yes. I don't know what to do about that. I've waffled a bit between them and having implicit name mangling (as in C++), but that leads to ABI and interoperability issues. But I acknowledge the issue. What can I say? Language design is hard!
And to answer, your claim that you're not a language guy, you are. As a user, you are more right than me as to what is good; actual users matter more than the language designer. If you are a user, you know what's good for you, and it is my job to hit that.
Someone somewhere said that new projects can only spend a few points on "novel" things; maybe I'll have to spend one on function suffixes, or maybe it would be better to spend them somewhere else.
> But I don't think I'd want to use anything "Indie" in production anywhere, and AGPL might scare off people so it never becomes a mainstream corporate backed thing, right?
Well, I am running a business behind it, an actual real business, so it may not be corporate-backed, but it's as close as I can make it. Because I don't want a corporation controlling it.
> Seems like you'd have to really carefully make sure it fits the audience who enjoys using indie stuff if you don't plan to get corporate backing. AI free seems like a good thing for that!
Thank you! That is actually part of my plan (though I do hate LLM's).
Here's my plan: you have people at companies that write shell scripts for small tasks, right? Over time a few of those scripts get passed around, tweaked, and turned into pseudo-blessed company-wide tools.
Well, maybe one of those programmers writes Yao scripts because Yao is just better than shell. If one or more of those scripts becomes a pseudo-blessed tool, then the company now depends on Yao, and they would be wise to pay me a few grand a year for support.
IOW, you nailed my plan: target the indie audience and use it to snare the corporate one. :) You figured all of that out from the language design! You're sharp!
Thank you for the comments!
[1]: https://writing.kemitchell.com/2020/03/07/No-Posse.html