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.

I'll look up all the jargon that went above my head. I'll learn something—thanks for that.

Now let me reply to everything that I understood and have answers to.

> `a + x` or `x + a`

commutativity is a thing in mathematics too. No one will be stumped by seeing this written in two different ways. It doesn't introduce any confusion. In javascript, there is more than just one way to do async—callback, promises, the new syntax sugar async-await. This is, or at least was for me, a cause of confusion. 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.

> /* block comments / Should it support nested comments?

Good point, I'll think about it. What do you recommend?

> I see that you're trying to pursue similarity to C++ or Java, but I don't see why. Which other type can "hello world" have in your language?

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?

> Sure, more implicit type conversions!

User-defined datatypes will be able to define their print behaviour. Also, I don't wish to interpret printing as a type conversion. Even abstract concepts, say a car, have a possible textual description, maybe their registration number. Am I misinterpreting what you're saying?

> Please tell me that you've read on TCL's regexps

Doing. (So sorry I haven't already).

> Regexps inside of a programming language implementation ARE pain. You essentially enforce your implementation, so it has to be perfect, unicode support and performance-wise.

Point. Will do some research of my own and consider.

> Magical syntax for array is what everyone is waiting in 2018. Why keep it simple?

Not array, but list. I gave how to represent list literal some consideration. I came up with this for the time-being. The right side seems natural and intuitive enough to me. What do you suggest instead? Parentheses and angle brackets are options...

> > int[] anotherArray = new int[15]; > int[] newArray = array[2..4]; In both cases we create some space on heap, and initialize it in some way. It's something like several constructors of the same data type. Why do they have different syntax?

The latter is the splicing syntax—shorthand for running a for loop over elements 2 through 4 (exclusive). Yes, it too does does create some space on the heap and initialize it, but I mentioned in my readme that the language's syntax will be dealing in abstractions, not low-level details. It seems a natural enough thing to do, right? I mean I could do the latter in two steps. First initialize, then splice and store. But then we use string an integer literals all the time. I think the two are similar.

> It's in no way clear why double multiplication is exponentiation.

I made that decision when I was planning to include bitwise operations. I'm not sure if I'm going to keep them (probably not, in which case I'll switch to the caret). If I do, I might stick to the conventions that programmers of other languages are familiar with (for lack of better alternatives).

> Is it right-associative?

The plan is to make it that way because of how the visual representation of repeated exponents in math works. Your thoughts?

> The problem is that unicode characters are absent from your keyboard, and there is no standardized way to write them. So you're essentially putting programmers into a flaming pit.

I agree. Not going to deprecate >= etc any more.

> Now this is actually something good.

Based on feedback from someone else, I was second-guessing this. Is there any reason I should avoid having too many keywords? I can see why they would suggest that, but what are your thoughts on the too-many-keywords issue?

> That's not how a good pascal case works.

My mistake.

> Are you sure you will be able to handle it properly?

I get what you're suggesting. Probably not today at this very moment. I can learn though (oh wait, but I shouldn't do something if I don't know how to. I'll address that in a bit).

> What about parameters having different types?

I was thinking they would use `* ...values`. But then you mention that `` is a bad idea altogether.

> We do not expect random people giving other people drug recipes to become doctors just from their experience of giving drugs.

Those things are hazardous to people's lives. There are regulations in place to prevent that. I guess you want regulations in place to prevent anyone from creating their own programming languages. Unfortunately for you, that isn't going to happen any time soon. In my (admittedly limited) experience, trying something is the best way of learning. I used to have a habit of going through tutorials, trying to learn things. I realised soon that in the long-term, I wasn't learning anything altogether. It was only when I started making things, experimenting, and, of course, making mistakes, did I actually learn. Also, I learnt lots along* the way. This is not the final spec (like I emphasized over and over again). In the process of designing a language, I will learn. To be perfectly honest, my biggest objective in doing this altogether is to learn how to write compilers, parsers etc and how to work on large-scale projects. I agree that I am being too ambitious by thinking that others might find my language useful; yet, it gives me encouragement vs working on just a "toy language". I don't have much to say in terms of "Economic impact of bad languages is way too big. Please, accept this harsh language, feel the offence and just stop." I really don't have much to say. Maybe I'll add a screenshot of this comment in my readme to warn the public. I'm not going to stop. I can only hope and work towards not creating a "bad language". And so can you.

Like I said earlier, stuff I didn't reply to is something I either didn't understand or have no answer to. I assume that since your objective is to discourage me from doing any of this, you would rather not explain the stuff I didn't understand. I'll look it up.

Finally, I would have really appreciated it if you would have given me links/references to resources that would help me learn how to write programming languages. Consider this my request for you to do so (although considering the amount of—admitted—aggression you showed towards me, I'm unsure about whether you would do me this favour).