Clarification needed? Some ideas for improvement

ksaadDE commented 2 years ago

Hi I have a few questions and a few improvement ideas / aspects,

Tbh it looks like RUST, why rebuilding RUST? I see no advantage!

Why using a struct example, instead of a real c++ class example? e.g. https://www.w3schools.com/cpp/cpp_classes.asp

I would like to add (to the design) that writing a underscore (sneak case) is pretty annoying. https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/naming_conventions.md

Why not keeping it simple for the Naming Conventions? Classes: CamelCase + starting char is capitalized Variables: CamelCase + starting char is lowerized Functions: CamelCase + starting char is lowerized

e.g. MyClass myVariable myFunction

Makes more sense right?

Please remove the Brackets for the if clause, it simplifies the syntax like in Python

if isBla:
   doStuff();

If you want so, keep the semicolon, but I don't see a valid argument for them. Except for multiple inline "statements" e.g. doFirst();dosecond();doThird();

Not sure if people want to have this in a production code ;D

If you allow the brackets, without enforcing a good style, people will do this

{fn (abc){} fn(abc){}}

nobody wants to keep that code or maintain it!

Why would I need a "var" for variables in a class? It looks over complicated! Just make e.g. a=1 out of it, if you give it "var" anyways. Not sure if it makes the parsing easier. So basically we would end up like this

class {
    a: 1;
    b: 1;
    fn (stuff) 
    {
           doMoreNerdyStuff ();
    }
}

Not sure if you want to remove the semicolon in that class. Could be replaced by a comma (theoretically).

The match-case (or however it is called in your docs) looks over complex as well. Why would you use this? I would like to see the following code in good quality code:

   match x:
       a:
          doA();
       b:
          doB();
       c:
          doC();

It removes the eye burning stuff around it and makes the code easier to read and therefore brings up a higher quality.

if you would like to add brackets it would be like this:

   match (x) 
   {
       (a)
       {
       }
       (b)
       {
       }
   }

I would even enforce the new lines in the parser, to make it more readable. Not sure if you want a space between (a) and (b).

A good thing of both worlds could like this:

   match (x) 
   {
       (a): 
             doStuffHere();
       (b):
            doGoodMoreStuffHere();
   }

What about "this" or "self" indicator for inclass stuff? Like

class 
{
    fn happyCode()
    {
          doHappyCode2();
    }

    fn doHappyCode2()
    {
          // ...
    }
}

Why not allowing multiple types of comments? Comments should either start with # or // multiline comments could start using /* and so on

// sl comment
# sl comment
/* 
     ml comment
*/

Final word: I don't know if I did fulfill all the requirements for contributions but I think the improvement aspect is much more important than any rule about contributions.

Would love to test the language in the future, if the language is matured a bit. 👍

With love and creativity from Germany

/E: improved readability, added a few little ideas.

jonmeow commented 2 years ago

Hi @ksaadDE, we've already considered a lot of options when we're setting the language design, and so we're really looking for new information or data-based arguments. I'll try to link to where I can for evidence. At the bottom of most documents, you'll find links to proposals and alternatives with more detail.

Why using a struct example, instead of a real c++ class example?

The top-level README.md is a quick overview, not an in-depth examination of the language. Read the main design if you're looking for detail.

Why not keeping it simple for the Naming Conventions?

Read proposals and alternatives in the naming conventions design. This was also recently discussed again on #1435

Please remove the Brackets for the if clause, it simplifies the syntax like in Python

Read proposals and alternatives in the conditionals design.

Why would I need a "var" for variables in a class?

Read proposals and alternatives in the var design.

Note, you'll find introducer keywords like this are a common theme. They reduce syntactic ambiguity in a language.

The match-case (or however it is called in your docs) looks over complex as well. Why would you use this?

The match-case syntax isn't fully decided. Note #1672 makes a similar point as you. But because there is no decision backing up syntax, please treat this as just provisional syntax: we wanted something and this is easy to parse.

What about "this" or "self" indicator for inclass stuff?

Read about classes, including the references.

Why not allowing multiple types of comments?

Read the proposal for comments.

ksaadDE commented 2 years ago

Hi @ksaadDE [...]

@jonmeow Thanks for your comment. I would like to shortly reply to your argumentation and hints.

Keep in mind, the next generation of developers are no classical C++ Developers - they are more likely Python and Javascript (NodeJS) developers. C++ (more the humans who use it, not the language itself) has a lot of indirect flaws, which led to the biggest mistakes and security flaws in the past. Further some developers accidentally created code that is not maintainable. Which led to costs nobody yet can analyze - not even in average statistics.

It shows you can't catch everything with a data-driven approach. For example, the practice shows that most students / beginners will write the code for companies. Means you have to simplify the guide, specification for the language and the language itself, to a point, so it will be easy to read and write. Otherwise Carbon will end up as "C++" and nobody really wants a second C++ disaster.

Your linked the "comments" entry in the documentation, which I read before, it says nothing about the process, how you (if you did) excluded the "#" for comments. Also multi-line comments are not discussed, if I didn't miss it.

syntactic ambiguity

It does not matter, if you have "var" or nothing before a variable inside a class. The var keyword just makes it annoying to read and gives no additional information (unlike if you would add a direct type keyword like int32 or bool(ean) etc). I would just remove it and make the language sexy and fluent. 👍 Further there's only one meaning to it, if there's no keyword (it's var). But I know it theoretically makes it harder to parse it properly.

Like others stated in your linked issues, please make a language that is READABLE for a human. Not for the machine only. :-)

I just wanted to help you to get a nice language, which is on the speed of C++ but a bit better readable and maintainable. Of course, I know you are in the process of finding a path through the big stack of decisions and implementations. 👍

Oh and, the more additional conventions and keywords a language provides, the less I (and maybe others as well) will be able to remember them during daily operations. I think this case can be made up, without providing additional data to it. Just tell me last 20 things you did today and you will know what I mean.

/E: BTW: your first link is a dead link (to the FAQ regarding data-based / new information) /E2: Corrected a bit of the Germish ;)

/E: Add information If you want some additional information (critics of C++, coding styles and preferences and last but not least statistics about the devs themselves):

ksaadDE commented 2 years ago

I read the E-Mail today. In your first reply (before the edits) you wrote this:

[...]I'll try to link to where I can for evidence, but most of what you're mentioning has previously been considered and this issue is pretty sprawling with your preferences on various features. Since this is more about your preferences than providing an argument considering the advantages and disadvantages of any given feature[...]

Your quick statement shows a culture of being closed-minded. I assume you have studied. The first semesters learn in the first years that studies have limits. They are not a nuke to stop fighting about arguments.

People will always end up discussing patterns, quality metrics and personal preferences. Just think about what surveys are made about.... right! Opinions of people. People will write the code, so you have to provide a readable and writable language in the future.

Your argument "is more about your preferences" is a bit like a straw man argument to avoid further discuss, which underlines my initial statement "closed-minded".

But thanks for your reply and the documentation, which lacks of for example a explanation of the comment style - which I guess is about the priority in writing the actual code than the documentation.

I would rather focus on less amount of conventions and improve the quality of the language itself. If you have 200 conventions everyone will suffer. Developers want to be quick in writing code AND being compliant to the conventions. Companies want a simple and easy framework to see if developers fit the requirements, I can tell.

We had those mistakes I have criticized in the past, which lead to suffer. That's why I tried to underline, that you should not loose the focus.

Happy developing! 👍

carbon-language / carbon-lang

Clarification needed? Some ideas for improvement #1938