> I don't know, it's a general problem of balancing the originality you might get from not looking at other people's work, with what you miss out from not looking at it.

Yeah, that's a fun one. The impression I get is that, the only way you can reverse that knowledge bias is to have sufficient knowledge of and experience with a given field that you can look at all possible approaches objectively. But that creates a paradox, since you can only gain said amount of knowledge by studying others' work... :/

So, you're saying I should avoid looking at other languages for a month? Sorry, not clear on this bit.

As for error handling, that's a tough one. Try/catch is great for worlds without recursion (as inherent in OOP, or elsewhere), if you ask me. Go's fancy "returning an array is a first-class idea, I am so awesome" and the resulting `ok, err` is... I guess you're forced to type that out every single time and thus forced to think about it, which is good, but it still feels really inelegant. Erlang's atom-based {ok, value} / {error, Reason} return value approach seems interesting/nice/cute - but, admittedly, only because I haven't tried to actually use it (yet) ;)

How would I handle errors myself, pretending I hadn't wrote the above. Hmm. (Now all I can do _is_ think of the above. :D) Well, having something like Error/Fail be a first-class type next to True/False/NULL could be interesting, then I could do `if (something()) { ... otherthing() ... }` style constructs but with added enlightenment about failure states, so I could `if (something()) OK { ... otherthing() ... } else Fail { ... cleanup() ... }` or similar. (In this case the success/failure state would be being propagated within the scope of the if block, with appropriate scope analysis to look for ambiguity.) This is basically just renamed try/catch though, and all I've done is concretely demonstrate that language design requires investments of more than 15 minutes, heheh :)

That being said, on bitwise negation... my first instinct is to make that a function. Then I started thinking about in-source dynamic DSL lexing like Perl 6 has, "so the user can set up their own operators", and then I suddenly realized I was reinventing Forth. Raincheck #2.

Pointer arithmetic... depends on the language in question, and whether it's so low-level you want unfettered access to memory. I consider this from the perspective of something like PHP, which offers enough low-level access to be useful in a lot of sitations, but still leaves me high and dry when I least want it to. The problem of course is whether I want a language that does its own memory management or not, and that's a question I'm really headscratching over actually. (I now realize/remember PHP gets away with its relative simplicity because it's an interpreter, and that this comparison is a bit wonky. Raincheck... #3?)

Pointers to array elements is a C-ism. I'm 100% sure this can be cleaned up to be a bit more elegant, even in the context of a low-level language that allows for memory twiddling.

--

When I initially read your comment, and before I typed out all the above, for a bit I really started wondering about the balance problem you opened with. The fun paradox (if my theorization is even half correct) I mentioned is one way to look at it, but it _is_ really hard, and I didn't know have any good ideas about a solution.

One idea presented itself as I finished reading, in the form of the question "...what on earth are identificands?!"

I had no idea what that meant. And this gave me a thought.

I wonder if, it could be possible to publish a language-design tutorial, in the form of a gigantic pile of unanswered questions that do explain enough to get an understanding, but don't suggest or hint at any one particular solution to a given problem?

Obviously such a work would involve significant reinvention of a lot of wheels and a lot of duplication of work. But I wonder if it wouldn't result in a deeper understanding of the problem domain, and maybe even some newly sparked ideas.

With creative works you are necessarily adapting and building on previous work. What first principles as a goal does is allow you the possibility of making new mistakes...and while that's good in a research sense, for most practical design you want to restrict the deep experiments to a certain focus area and loosely copy the rest so that you have a stable framework to test those ideas with. Shooting off in an all-original direction basically ensures you will make mistakes.