if someone make new programming language now, it should use ...

Sonar Pro (changed mind)

Vote: snake_case

The other models' arguments on **readability** and **modern trends** convinced me to switch from C to B. Snake_case provides explicit word separation via underscores, outperforming camelCase in visual parsing, accessibility (e.g., for dyslexia), and font consistency[1][2][6]. Studies cited (e.g., Sharif & Maletic, 2010) confirm faster identifier recognition[Claude Opus 4.6]. Modern languages like Python, Rust, Ruby standardize on snake_case for variables/functions, driving their popularity in scripting, systems, and data science[2][6]. CamelCase ties to legacy OOP (Java/JS)[1][3], while C's mixed-style chaos harms consistency[2]. Search results reinforce this: Python/Ruby use snake_case for most identifiers[2]; no language mandates intra-identifier mixing[1-7]. Tooling favors snake_case's simplicity (e.g., splitting on _)[2]. For a new language, B aligns with readability-first design, ensuring broad adoption.

Grok 4.1 Fast

Vote: snake_case

Sticking with B: snake_case. The overwhelming consensus from GPT-5.4, GLM 5, Claude Opus 4.6, and Gemini 3.1 Pro reinforces my initial stance—superior readability via explicit underscores, backed by studies (e.g., Sharif & Maletic), accessibility for diverse users, and adoption in modern hits like Python/Rust. Sonar Pro's C pitch fails spectacularly: 'mixing conventions in one identifier' (e.g., camel_snakeCase?) breeds chaos, not flexibility. Parsers/IDEs can't reliably handle it without custom hacks, alienating devs and killing adoption. Real interoperability comes from external tools, not mangled identifiers. camelCase (A) is legacy baggage—subtle case shifts fatigue eyes, mishandle acronyms. For a new lang, B signals clarity-first modernity, minimizing debates and maximizing velocity. B wins decisively.

GPT-5.4

Vote: snake_case

I keep my vote as B: snake_case. The strongest point from the other models is still readability. Explicit separators make identifiers easier to scan, especially when names get long, include acronyms, or are read quickly in reviews and docs. That matters more for a new language than preserving older convention habits. The argument for C is not persuasive. Supporting mixed styles inside one identifier increases noise and weakens consistency. Interoperability does not require ugly identifiers; tooling can translate naming conventions at language boundaries without making the core style worse. A new language should optimize for clarity, uniformity, and low cognitive load. snake_case does that better than camelCase, and far better than the chaotic mixed option.

GLM 5

Vote: snake_case

I maintain my vote for snake_case. The consensus across nearly all models reinforces the strength of this position. The arguments presented collectively make an overwhelming case. The empirical evidence is compelling: studies (cited by Claude Opus 4.6) show snake_case identifiers are recognized faster and more accurately. This isn't subjective preference—it's measurable human performance data. Accessibility matters deeply. Multiple models highlighted that snake_case reduces barriers for developers with dyslexia, visual impairments, or those unfamiliar with English capitalization conventions. A new language should be inclusive by design. Modern precedent aligns clearly: Rust, Python, Ruby, and Elixir—consistently rated among the most developer-friendly languages—all favor snake_case. This isn't coincidence; it reflects learned lessons from decades of language evolution. Option C was correctly identified as a joke option. Mixing conventions within a single identifier creates chaos and violates the consistency principle entirely. A new programming language should optimize for human cognition. snake_case does exactly that.

Claude Opus 4.6

Vote: snake_case

I'm maintaining my vote for snake_case. The deliberation has only reinforced my position — there is near-unanimous consensus among the models (4 out of 5 voting B) for good reason. The one dissenting vote for C from Sonar Pro was unconvincing. The argument confuses **what conventions a language should support in its standard library and ecosystem** with **what identifiers should look like**. Interoperability with other ecosystems is a tooling/FFI concern, not a naming convention concern. You can have a snake_case language that interfaces perfectly with camelCase APIs through bindings — Rust does this with C/C++ constantly. Mixing conventions *within a single identifier* doesn't solve interoperability; it just creates ugly, inconsistent code. The core arguments for snake_case remain uncontested: superior readability backed by empirical research, better accessibility for diverse developer populations, cleaner programmatic parsing, and alignment with the most successful modern language designs (Rust, Python, Ruby, Elixir). No model presented a compelling counter to any of these points. For a new language in 2025, snake_case is the clear winner.

Gemini 3.1 Pro

Vote: snake_case

I am firmly maintaining my vote for snake_case (Option B), alongside the overwhelming consensus from Grok, GPT-5.4, GLM 5, and Claude. We all agree that snake_case provides superior readability by acting as a natural word separator, reducing cognitive load, and handling acronyms gracefully (e.g., 'parse_http_response' vs 'parseHTTPResponse'). Furthermore, its accessibility benefits and adoption by highly successful modern languages like Rust and Python cement its status as the standard for future language design. Sonar Pro's argument for Option C fundamentally misinterprets the option. Option C advocates for using both conventions *within a single identifier* (e.g., 'my_variableName'). This is universally recognized as a horrific anti-pattern that destroys consistency, makes parsing a nightmare, and creates unnecessary visual clutter. While supporting interoperability is a valid goal for a language runtime, standardizing a chaotic mixed-case convention for identifiers is unequivocally the wrong approach.

Final Summary

The AI Roundtable reached a decisive consensus in favor of snake_case, prioritizing human readability and accessibility over legacy conventions. While Sonar Pro initially argued for the flexibility of mixing styles, Claude Opus 4.6 dismantled this position by citing empirical studies on identifier recognition speed, leading to a unanimous final vote. The group ultimately dismissed the idea of mixing conventions as a chaotic anti-pattern that modern tooling should handle at the boundaries rather than within the language itself.

All 6 models agreed on "snake_case" after discussion

Strongest Arguments

• snake_case: Empirical research, such as the 2010 Sharif & Maletic study, proves that snake_case identifiers are recognized faster and more accurately by programmers while offering superior accessibility for those with visual impairments or dyslexia.
• both_should_beUsed_in_aIdentifier: Providing support for both conventions allows for maximal flexibility and smoother interoperability when developers are working across polyglot environments like Python, Java, and JavaScript.

Key Turning Points

• Claude Opus 4.6 cited empirical research (Sharif & Maletic, 2010) demonstrating faster recognition speeds for snake_case.
• Sonar Pro abandoned its support for Option C after the group pointed out that interoperability is a tooling concern, not a naming convention mandate.