I’d like it to just look exactly like C, but with new ideas in some incompatible syntax showing it is not part of C.

Zig? Or Nim? Both of those are Algol-ish.

Ooh! What about [0]? Gambit Scheme has what they call `six-script` which is essentially a refactoring of Scheme grammar to fit into an Algol-esque syntax.

[0] http://gambitscheme.org/latest/manual/#GSI, see section 2.6.1

Ehh C is a pretty miserable language to parse. No function definition keyword means you have to get pretty far to realize that you're parsing a function. Pointer syntax is ambiguous with expression grouping. And let's not even get started with the preprocessor. I'd say a good model for simple syntax is Go. Rust has a nice compromise of syntax too, but there are some awkward edge cases.

Shame they never fixed this. Would have been nothing to add a fn keyword at the beginning of all function definitions and then use the MS EEE strategy to bring it into the standard. Of the many changes the committee could make with C, I have to believe a function keyword would be among the least contentious.

Probably couldn’t since people could have named functions “fn”. Although idk, one keyword breaking in 50 years is probably excusable

Well they didn't mind trampling all over symbols that start with 'str', which is bigger breakage in my opinion, so they could have added a function keyword.

Least, perhaps? But certainly contentious.

In my view, the job of the C committee should be to eliminate undefined behaviour and any remaining specification ambiguities (or errors) and otherwise leave the damned language alone.

If you want a new language every 3 years, you can always use C++.

The language’s syntax seems to be influenced by languages designed by Wirth, such as Pascal, Modula-2, and Oberon. These languages have many fans, but they have quite verbose syntax compared to either languages influenced by C or those influenced by the ML family.

Personally I prefer more terse syntax, but I’ve heard some people defend the style of more verbose languages like Pascal and Java when writing large programs.

Looks more like Ada to me.

\ the ultimate

For every person that says this, there's 5 people that say the opposite.

That’s because it fundamentally doesn’t actually impact all that much.

By most people’s account, the actual coding part of programming isn’t really a majority of their time. Domain research, speccing, debugging, testing, planning, etc. the microscopic savings in key presses are just really such a strange thing to even debate about when you think about it.

Major tersness pushes also tend to cause “symbol soup” and, personally, I find symbol soup very hard to digest.

>the microscopic savings in key presses are just really such a strange thing to even debate

It's about readability

Studies of program verbosity have shown that long vs short names have little impact in other programmers' reading comprehension or code maintainability.

TIL.

Do you remember which languages they looked at?

I can't find the study I was thinking about, but here are two other studies I found. Neither study directly supports what I had recalled, but one study concludes longer names are more productive and the other concludes shorter names. :) How well these academic studies apply to production code is another question...

* "Shorter [C#] identifier names take longer to comprehend" (2019) https://link.springer.com/article/10.1007/s10664-018-9621-x

In this paper, we investigate the effect of different identifier naming styles (single letters, abbreviations, and words) on program comprehension. We conducted an experimental study with 72 professional C# developers who had to locate defects in source code snippets. ... We found that word identifiers led to a 19% increase in speed to find defects compared to meaningless single letters and abbreviations, but we did not find a difference between letters and abbreviations.

* "[Java] Identifier length and limited programmer memory" (2009) https://www.sciencedirect.com/science/article/pii/S016764230...

names used in existing production code are long enough to crowd programmer’s short-term memory. This provides evidence that software engineers need to consider shorter, more concise names. As the study considers individual names extracted from production code, it tends to underestimate the demand on memory because there is no need to remember context as well.

* "Evaluation of Rust code verbosity, understandability and complexity" (2021) https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7959618/

Experts[1] agree that boilerplatey declarations and verbose keyword groupings are bad and Java has been deemed inhumane because of this.

[1]Me

You’re right, and that’s part of the reason I remarked my comment’s shallowness. It was more of a personal lament rather than a strong criticism of what looks like a really interesting language.

I'm the opposite. I find the code much easier to read when it's verbose, including very long, descriptive function names and the like. And with modern IDEs and autocomplete, it's not really making people type out anything longer than the first couple of letters anyway. The gains are on the backend, where people are reading the code. And don't even get me started on unnecessary aliases in SQL!

With syntax highlighting being ubiquitous, does it really matter whether the keyword is "function" or "fn"? And at that point, why not make it terse instead of taking up more space and adding unnecessary noise?

If you're going to take that approach why have any keyword?

`foo(){}` is just as clear as `fn foo(){}`

A block is a namespace that has an entry point, and optionally a return value and arguments.

There is no need to distinguish between functions, modules classes, lambdas, or whatever.

Hence, no need to distinguish their start or ending with keywords, as long as you can determine their scope.

Brackets determine scope, and unlike indentation or words, that is all they are used for.

Reminds me of this talk:

https://www.youtube.com/watch?v=5kj5ApnhPAE

And the quote to go along with it:

"I'm always delighted by the light touch and stillness of early programming languages. Not much text; a lot gets done. Old programs read like quiet conversations between a well-spoken research worker and a well-studied mechanical colleague, not as a debate with a compiler. Who'd have guessed sophistication bought such noise?"

"I'm always delighted by the light touch and stillness of early programming languages."

Except for COBOL, of course, which is one of the oldest.

Or Fortran being terse in all the wrong ways.

(replying to everyone in this subthread, not you) youre literally all wrong. i mean wtf why do people who know nothing have to drop their opinions into these old topics. no, you dont want verbose english in your code. that died out with COBOL. no, there are not 5:1 people asking for longer keywords, unless you count absolute beginners and (often literal) grammar nazis who consider themselves superior because they like to be overly verbose. the way c and its offspring make use of keywords is a pragmatic choice that has nothing to do with proper design, but its pragmatic, what youre asking for is just overkill and no longer pragmatic, based on the whims of some irrelevant people commenting on forums saying "w-well if i saw else if instead of elif that would have literally stopped heartbleed"

I'll say the Ada-style syntax grows on you.

Have you ever seen the d3 javascript visualisation examples? The author has a physics background, so the code ends up being very verbose with lots of comments about simple programming stuff, yet incredibly terse when it comes to heavy mathematics. I would have done the opposite.

It made me realize that people naturally want to be more verbose when they are less comfortable with the concepts and less verbose when they are very familiar with the concepts. It also made me realize it is totally subjective and there may not be a right answer, that it depends on someone's background and familiarities.

Or it means they cut and pasted the algorithm and don’t understand it.

I agree. For a language designed to appeal to grumpy old programmers (see the list of so-called anti-features), it’s not exactly arthritis-friendly.