Concerns on moving towards Python-style keywords

[Merc6]

As far as I’ve seen, Otter was never meant to be a Rust-flavored replacement for Python, but rather a whitespace-sensitive, statically typed, compiled language with seamless Rust interoperability. Python already exists - and will continue to - so aliasing its keywords doesn’t make the language more approachable; it dilutes its identity and introduces unnecessary baggage. A language doesn’t need to be every language at once. Keeping the Rust-like syntax feels more consistent with Otter’s original goals and avoids creating expectations around Python features that Otter doesn’t (and likely shouldn’t) support.

[jonathanmagambo]

which keywords are you specifically referencing?

[Merc6]

The problem isn't that I'm worried the option will up-and-vanish - it's that there are options in the first place. For example, if a C++ dev comes in, they're going to expect class and struct to be two entirely different things; when you have multiple keywords that essentially mean the same thing, the language loses its sense of identity. Even if it feels like you're appealing to a broader audience, you're actually doing the opposite: you're introducing cognitive load. Users reading someone else's library - or even an outdated standard library - will have to mentally translate between fn/def or struct/class. It makes the language seem incoherent, like it doesn't know what it wants to be.
Also, println and print shouldn't do the same thing. By the very nature of println existing, you'd expect print to omit the newline - that's the established convention across languages.

[jonathanmagambo]

I decided as of now to remove fn completely keep def, println (prints new line; pretty sure it always has I could be wrong), print (prints), dropped class completely for structural, if you want any other changes let me know

[Merc6]

I decided as of now to remove fn completely keep def, println (prints new line; pretty sure it always has I could be wrong), print (prints), dropped class completely for structural, if you want any other changes let me know

Works for me, personally I never learned python, I could still write code in it but I just never really bothered to actually learn the language, so I was advocating for keeping Fn as the function keyword; I'm just happy though that there's no more aliasing of keywords.

Also, just to give you a bit of info on print and println, I believe print actually added a leading newline (I never really got far enough in my refactors to actually do a whole lot of testing with running the language). Anyways, basically print allows you to keep writing to the same line in the terminal, while println explicitly adds a newline character at the end.

Also, don't just ask me for changes, nor should you accept changes all willy-nilly, otherwise you're gonna be drowned in people asking you to make changes to fit their preference; focus on your vision for the language.

As for other than that, since you already approved the move towards a more crate-based design, I'd really appreciate if you could help out with that one too, I've been especially having difficulties with removing interdependencies with runtime and codegen, I was planning on adding a symbols crate, and moving some of that related stuff their, then I think you've got some redundant functions in some ffi_something module you could get rid of. It's a lot of work and even just one of those changes involves a few branches, so I just haven't gotten to it and have just been working on my own build of the language.

(Also I'm like 80% sure this is vibe-coded, which I'd love to see a move away from if I'm right; I can understand if it was just to get the idea on paper to see if it catches on, but long-term I don't wanna see that decision kill the project, because I am very genuinely interested in it)

[VivIsBee]

I personally am okay with def although I like fn much better personally. As @Merc6 said you shouldn't immediately accept any proposal, and that includes mine! I just feel like def is very vague and doesn't give much clarity about what is being defined compared to fn.

[jonathanmagambo]

I decided as of now to remove fn completely keep def, println (prints new line; pretty sure it always has I could be wrong), print (prints), dropped class completely for structural, if you want any other changes let me know

Works for me, personally I never learned python, I could still write code in it but I just never really bothered to actually learn the language, so I was advocating for keeping Fn as the function keyword; I'm just happy though that there's no more aliasing of keywords.

Also, just to give you a bit of info on print and println, I believe print actually added a leading newline (I never really got far enough in my refactors to actually do a whole lot of testing with running the language). Anyways, basically print allows you to keep writing to the same line in the terminal, while println explicitly adds a newline character at the end.

Also, don't just ask me for changes, nor should you accept changes all willy-nilly, otherwise you're gonna be drowned in people asking you to make changes to fit their preference; focus on your vision for the language.

As for other than that, since you already approved the move towards a more crate-based design, I'd really appreciate if you could help out with that one too, I've been especially having difficulties with removing interdependencies with runtime and codegen, I was planning on adding a symbols crate, and moving some of that related stuff their, then I think you've got some redundant functions in some ffi_something module you could get rid of. It's a lot of work and even just one of those changes involves a few branches, so I just haven't gotten to it and have just been working on my own build of the language.

(Also I'm like 80% sure this is vibe-coded, which I'd love to see a move away from if I'm right; I can understand if it was just to get the idea on paper to see if it catches on, but long-term I don't wanna see that decision kill the project, because I am very genuinely interested in it)

Yes, some portions of the code are vibe coded in which I've had to do or else this project would have taken a significantly longer portion of time. I'll be working through each file though and rewriting it to be proper in the long run. It's just in order to try to reach the level I'm trying to reach, I've been forced to design certain functions and use AI-assisted tools to build them in order to keep up with time crunch.

I'll be rewriting and rebuilding significant portions of the code, but for now It's required.