> Edit: 5. Avoid looking at Zig, Myrddin, etcetera, if you can. There are obviously paths that any C-like language tends to go down in the 21st century, and the world would probably be better if you rethought the problems from a blanket slate.
I read the points above this one and cannot comment/disagree with them. However, I am very curious about (5).
- What would you classify as "etcetera" here? (ie what other languages would you list)
- What are the paths in question?
- With said blanket slate, what other mindset may be useful to keep in mind?
Blanker slate, damn iPhone. More of a blank slate.
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.
"Etcetera" includes other low-level languages people've made. Like, I guess Go might even count. Honestly 5 is kind of stupid. No great reason not to ignore it. It's the sort of thing to do for 1 month, but not forever.
By "paths" I mean different features that different languages have and how they do them. You could just copy how these languages try to improve the ergonomics around error handling, for example, or you could decide how you'd like to do it. Thinking from first principles it's likely you'll end up walking into exactly the same decision other languages make, only with a different choice of operator. But it's possible you'd improve matters.
Other paths are questions like implicit conversions or how do explicit conversions happen. And what do you name the bitwise negation operator? Can you do pointer arithmetic? How do you handle pointers to array elements? Do you have a one-to-one mapping from indentifiers to indentificands?
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.
> 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.
I made up the word identificand. Like, integrand, subtrahend, identificand.
I mean, don’t take me too literally about the month thing. Obviously your mind is already poisoned by other languages. But I’d say, try to avoid just doing what other languages do, and inject some novelty. If only like a chess player going off-book.
I read the points above this one and cannot comment/disagree with them. However, I am very curious about (5).
- What would you classify as "etcetera" here? (ie what other languages would you list)
- What are the paths in question?
- With said blanket slate, what other mindset may be useful to keep in mind?
Thanks!