| > Let me start off by conceding that you're more knowledgable and experienced than me (which you inferred from my post and attempt at designing a language anyway) and I am in no way trying to challenge that. Self-humiliation never helped anyone to get more experience. I am not trying to look knowledgable. I'm scared of yet another determined person making a programming language. > There should (ideally at least) be only one way of doing async functions. I know that I plan to have lambda functions in my language. You might say that I contradict my own example. I am yet to think of a way to counter having two ways of approaching async. Sometimes you subtly change the way the programming language works by introducting several magical words to it. For example, you can add `throw` and `try...catch` to get very similar language, but now jumping from a point of error towards its handler doesn't require you to change all the functions that are between them. Likely there are `async` and `await` that let you pause and resume code execution threads. Such subtle changes are easily implemented through monads, but in current implementations burden of required knowledge is way too big. > I did give this thought but implying the type doesn't make it obvious that the variable cannot store other types. What are your thoughts on this? There is a nice property of programming languages: a language having principal types. This means that every expression in the language can have one and only one most general type. OOP languages don't have this property, so they lose type inference. If you have `class A extends B` and want to do `B x = new A`, you have to write both types anyway. I'd recommend avoiding OOP at all cost, and take a look at O'Caml, row polymorphism and MLsub type system. > Am I misinterpreting what you're saying? What's the type of `println`? Isn't it `println(string): void`? If so, how did it get `int` (or whatever type you assign to integer literals) argument without a type checking error? |