[dadoum]

I am also working on a programming language with that no hidden behavior philosophy at the forefront (along with a few other things), but radically different on everything else, so I may have a few design choices to question.

I think that your conception of cleverness is too wide basically. It's true that, in my opinion, any new programming language today should stop people from C-style "cleverness". But there are languages where the clever programs are actually the pretty ones. For example, the borrow-checker in Rust encourages good code design (and yet it still can be better). And most importantly, algebraic types constitute a radical improvement over classic C-style code. You may think that they hide what's happening, as they have a hidden tag and could be built from C structs and C unions. But after thinking a lot about it, thinking about the tag is actually not thinking about the program's behavior. There is a difference between the program you want to write, and what needs to happen on the machine to compute it. I could probably write a lot about the solution I found to reconcile both opinions, but my project is a lot newer so I can't redirect you to anything yet. But I think that by wanting a more grounded language, you are maybe dismissing too many ideas that would actually encourage programs to be clear and transparent while still not doing anything automatically with magic (and at the same time, would dismiss incorrect programs, that C can express but that machines cannot execute).

Btw, I understand that I am probably not the target of your language, so I won't expand much further unless you want.

[octalide]

You may not be the target, but that does not invalidate that point. My personal view of the what is and isn't hidden behavior is definitely something that will rub a LOT of people the wrong way. That being said though, this project has grown out of the scope of "fun personal toy" and is intended to be embraced by other developers. If those developers don't want to use the language, then that could be viewed as a fault of the language.

This entire system was designed by ONLY myself up to this point, so I've effectively had blinders on the entire time. I personally like the drastic simplicity of the language, but if it gets in the way of the majority of the users who want to work with the language, then at a very minimum, a conversation should be had about the pain points. Finding that balance between being appropriately hard-headed and willing to adopt features I may not have originally intended to adopt is a difficult line to balance on.