So guys. I have a stupid question to ask: if you were going to design a language what would it be like?
I'm curious to know /prog/'s ideas. We argue language features a lot, and feature interplay a little, but we rarely get down to feature holism. (I'm not asking /prog/ in cooperation to design a language, but that might be hilarious.)
I'm asking because for all my opinions and dissatisfaction with the majority of languages I use I'm still stumped as to what I would like to see, ideally. (Obviously the right-tool-for-the-job maxim applies, but even when I pick a specialization I run into problems making up my mind.)
You are discussing the possibility of creating a new programming language, yet you have made no mention of any possible design philosophy behind it. In all seriousness, you should not be designing a language if you don't have a reason to make it.
You have not even mentioned any concepts related to the design of a programming language beyond the most elementary matters of computer science. You mention garbage collection, yet tell us nothing about how you plan to implement it. You mention "systems languages" without appearing to know anything about the design of such a low-level language. You even seriously mention "performance" as a criteria for your language, without any idea of what the task of making a compiler effecient entails.
We can say that understand concepts like static typing, as far as how to use them. We can say that you understand the effects that static and dynamic typing have on your work. You know how to use a statically typed language, and you know how to use a dynamically typed language. This, however, is only the tip of an icicle on an enormous iceberg.
It is one thing to tell me that "a statically typed language does its type-checking during compilation." It is another thing entirely for you to tell me what the implications of this design are for its effect on every other aspect of the language, for its implimentation, and the very purpose of the language.
I can go on and on, but in any case, you haven't managed to convince anyone here that you know what you're doing.
Let me tell you something that it would do you best to understand before you attempt to discuss a matter of this complexity:
You know nothing about programming.
You know how to learn a programming language and get it to do what you want it to do.
This is not the same as understanding it, understanding its underpinnings, understand its design, its reason, the language itself.
A programming language is nothing but a tool. Does the cook know what was taken into consideration when his blades were designed? Does the construction worker know what his tools are made of? No, they are but tools for accomplishing a job.
The problem here is that we are not talking about performing a job here. We are designing a tool to fit a job. Why is it, then, that you are speaking from the perspective of the worker? Why are you concerning yourself with the outer layers of the problem, when it is only the deepest ones that deserve any attention?
This is not the time for you to entertain the idea of the perfect language. Without a reason, and without an understanding of what a language really is, this discussion becomes pointless. You will gain nothing from discussing this matter with other empty heads. If you still wish to follow this concept to its apex, there is much learning left for you. You cannot attempt to scale the mountain, not yet.