Naming schema

[mamiksik]

Why does carbon choses to use PascalCase for function and methods names as well instead of camelCase or snake_case?

• Why to deliberately omit the semantic difference between data structure and data operations?
• Why to choose naming schema which is different(afaik) from CPP STD or Google's own CPP style guide?

[jonmeow]

On documents, we put in "alternatives considered" sections that describe what we thought about. In this case, please see https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/naming_conventions.md#alternatives-considered

[TimMensch]

The standard in many C-family languages has become PascalCase for types and camelCase for member or global functions or variables. Many libraries I used (and wrote) in C++ followed that standard as well, considering that snake_case takes more effort (and is less ergonomic) to type.

It would be much lower cognitive load for the largest number of users to follow that standard (which matches the standard in Java, Kotlin, JavaScript, and TypeScript, at the very least). PascalCase is even being used for class member functions (?!). It appears you've created a new criteria of "not known until compile time" vs "known at compile time" for naming? This is a fundamental change that breaks assumptions and doesn't (IMO) actually provide value.

Worse, that distinction is actively harmful. Sometimes a named value that starts its life as a compile-time constant can become configurable or even changeable at runtime, and needing to rename that constant where it's used feels like an unneeded cost/spurious technical debt. I question whether distinguishing values by their naming makes sense at all; types, on the other hand, are fundamentally different than values or functions, even if you consider types to be first-class values. They are first-class values in TypeScript (and Java and Kotlin), after all, but it still feels right to treat them differently than constants or methods, even when the type can be called as a method (which is true with some types in JavaScript).

You can tell the difference between a function and a value by simply looking at how its used; if you're looking at an auto-complete, every good IDE will have a symbol next to each member telling you whether it's a function or a value (read-only or otherwise) as well. Naming functions with PascalCase breaks the C++ standard library convention of snake_case for members and the common style of camelCase for members. Seems like a lose/lose to me. 👎

A lot of the decisions in Carbon feel jarring, and as such would make me hesitant to adopt the language. Switching from operators like && to keywords; using [] instead of <> for generics; using let to mean const when other languages use let to define a variable; all of this adds unnecessary cognitive load for language switching, and today and into the future we're clearly going to need to use multiple languages within the same project. Minimizing the arbitrary differences between languages should be a value held by language designers, but I'm not really seeing that in the Carbon design. One thing Ruby got right was to follow the "Principle of Least Surprise." Carbon seems to ignore that for what feels like whims of the designers.

Yes, Carbon looks like it would be nicer in some ways than C++. But as a C++ expert who also uses TypeScript (and C# and Java), I look at these seemingly arbitrary choices that will make my life harder for no good reason and I wonder whether it would be worth it to save some of the cognitive load of using C++ only to add new and different cognitive load when switching between languages.

New language adoption always has a very high barrier to entry, and Carbon seems to be shooting itself in the foot with regards to many of its design decisions. It would be 100x better to use C++ conventions for everything that isn't necessary to gain an actual improvement, and if you do want to make it feel more like a modern Kotlin/TypeScript take on C++, then any change you do make should be to transition to something that operates more like one of those languages, for instance adopting their common naming conventions, and not something that's unnecessarily confusing like let where other languages use const, or var (which is deprecated in JavaScript/TypeScript) where other languages use let.

Just my opinion, for sure, but I don't think my opinion will be unique in this regard.

[ncioj10]

I usually write Java, but I also like writing (modern) C++ occasionally, when I want small and fast. While agreeing that Carbon should not imitate C++, I still think it would be very beneficial to keep some of the above mentioned conventions, as there is little reason not to do so.

I see very similarly:

1. For probably all C++ and Java devs (which combined are a very large portion of all the devs) <> for generics would be much more intuitive. I've seen an argument here about the difficulty of parsing <> and I'm pretty sure it's possible since most languages do it too.
2. PascalCase as method and function style guide is horrible. It's the main reason I don't like writing Go. It is incredibly counter intuitive and unnecessary. I opt for camelCase as an easy to type modern approach, that is being used in many other languages. Even snake_case would be better.

For me many of the changes mentioned by @TimMensch seem to be changes, because Carbon should look different. Instead I would much more appreciate a language that does not have weird syntax quirks and instead focus to reduce the possible ways of blowing up in ones face, especially for beginners. I think that's still the main USP of Rust: It's fast and doesn't explode.

[TimMensch]

@jonmeow I checked the comment you linked, and it seems to be referring only to class naming.

I'm not objecting to PascalCase for class names. I'm objecting to PascalCase for class members. The comment cites Qt as a rationale for the choice, dice Qt classes are PascalCase, but Qt uses camelCase for member functions, which is exactly what I'm advocating. It's not an uncommon convention in C++, and it's the full standard in Java, Kotlin, and TypeScript.

As @ncioj10 says above, it feels like difference for difference's sake.

And honestly? No, it's not hard to draw the line. Make changes that actually, materially, improve the language. Leave things the same that are purely aesthetic. There is arguably a gray area in the middle, but nothing I'm describing is in that gray area. Presumably you're not using a convention like Go where capitalized members are exported, right? So choosing to capitalize members is simply the team deciding they like the look of it rather than anything more compelling. And the more changes like that you make, the higher the resistance to adoption will be.

There are hundreds of ways you can simplify and improve on C++ without increasing the pain of adopting the language. If you stick to these arbitrary changes, I fully expect this project to be a dead end. If you make it look a lot more like C++, but with improvements, then I think it might have a future.

And that's why I'm commenting here. It has potential, but I feel like you're making a classic blunder in trying to change the design to fit a niche aesthetic.

Look at TypeScript. Aside from types it has barely any syntax changes from JavaScript, and its adoption is tremendous. Kotlin... Is popular on Android, and that's about it, and that because of a lot of support from Google.

The principal of least surprise will make or break this project. Or at least mean the difference between being an also-ran like Dart and a massive success like TypeScript.

[emlai]

New language designers usually make the mistake of shoving too many changes into a language. The large number of immaterial syntactic changes in Carbon could lead to death by a thousand cuts. Also relevant: language strangeness budget by one of Rust's authors.

Carbon should put some design principles in place to prevent this from happening.

[geoffromer]

@TimMensch I've edited your comment to remove some insulting language. We don't use insults here -- even when directed at ideas, they indirectly attack the people who hold those ideas.

[jonmeow]

@ncioj10 Regarding <>, see #1691.

Also (and for @TimMensch to) To be clear, I think we're in agreement that choices will cost users. However, this is unavoidable: some developers want something really similar to C++ with a few small improvements because C++ is already a pretty great language, others want something significantly different and wouldn't learn a new language if it feels too much like incremental improvements. This is why it's really subjective about what the best choice is. If you're already not interested in Carbon, that's unfortunate -- the best I can say is is that maybe it'll be worth looking again after things have firmed up more, even if you're not interested now.

@emlai: There's been similar discussion (I've heard "innovation budget"). Right now there's this:

Familiarity for experienced C++ developers with a gentle learning curve. We need a feasible plan for retraining a C++ workforce to become proficient in Carbon. If long and significant study is required to be minimally proficient, meaning able to read, superficially understand, and do limited debugging or modifications, then the inertia of C++ will inevitably win. Further, we need a gentle and easily traversed learning curve to basic productivity in order for the transition to not become a chore or otherwise unsustainable for teams and individuals.

Again though, what a "gentle and easily traversed learning curve" means can differ between people.

[cdmaczane]

Personally I don't think any particular convention should be enforced/preferred. I happen to prefer snake_case as I find it easier to read. It is a subjective topic.

I would recommend that keywords and basic types stick to lowercase (as they seem to currently). That is a common convention in many programming languages. If complex library types follow camelCase etc then fair enough, as long as I am not forced to use them. I would probably write my own anyway as I do with C++ today. If strings or slice became a builtin type i would strongly encourage string and slice over String and Slice for example. Main() is an interesting one. The name of one function won't bother me but it feels like it should be lowercase as it is a special function and kind of like a keyword. Even better would be making it easy to define the entry function ourselves. This could be useful with conditional compilation. I might have one main for sample A and another for sample B.

[jonmeow]

Personally I don't think any particular convention should be enforced/preferred.

I think there's a good reason to provide some style guidance at the language level, such as PEP8 for Python, but I don't think enforcement is going to happen. (Mainly, it increases the chances that libraries from different authors will have a more consistent feel)

If strings or slice became a builtin type

Technically I think we'll try to only have bool be builtin, and mainly because of its significance for while, if, the and keyword, etc. i32 is envisioned as having alias-like behaviors for Int(32), a library type. There may be magic behind that.

Making strings or slices builtins is more unlikely. There may be some extra magic behind them for performance, but as much as possible the goal is to push for library types because it means features are exposed for other (developer authored) types.

Even better would be making it easy to define the entry function ourselves.

I'm aware of this with Python as an example, and might argue towards it, but I don't think we've even really decided on Main (#1869).