[president_zippy]

Interesting project and all, but why does everybody out to make their own compiled language want to get away from the basic syntax of C so badly? Rust and Golang are the poster children of this, but it seems like every other language implementer feels the same way on matters which are of 99% personal taste and 1% functionality.

This is just one microcosm of the general pattern I'm picking on here, but what's up with this obsession with scoping via indentation like Python? It's true that it looks a little more like a todo list someone would write on a sticky note, but I don't think C syntax is the hard part of systems programming or video game programming, which is what the creator of the Tomo language does.

It just seems like these kind of design choices needlessly add a barrier to entry for people who want to climb aboard.

Then again one must of necessity, have a ferocious "Not Invented Here" streak to go through all the trouble of inventing a new programming language in 2025.

[brucifer]

OP here, I just went with indentation-based syntax because I prefer indentation over curly braces aesthetically. I've got no problem with people who prefer curly braces and I find C very enjoyable to work with. However, when I started the language, I wasn't starting with a C parser and modifying from there, I was writing the parser from scratch, so I opted to go with the syntax I enjoy most. I'd like to think that Tomo's syntax is easy enough to pick up, especially for anyone who has used Python before.

I actually agree with you that syntax is not one of the things that makes C hard. C's syntax is mostly very easy to work with (apart from a small number of edge cases). The actually challenging parts of working in C are things like manual memory management, doing good error handling, the lack of proper namespaces or modules, a sometimes-footgunny standard library, and so on. I wanted Tomo to improve on the usability and safety of those areas, while keeping the parts of C that I really love: a simple type system, pointers as a language concept, fast parallel compilation (one source file -> one object file), and a programming model that feels closer to what the silicon is doing than most languages.

[president_zippy]

Thanks for dealing in good faith and picking a reasonable interpretation of my comment instead of going "debate mode" and making a straw man.

Just to clarify, I definitely wasn't saying "everything should be written in C" or even merely asking the question "why not just use C for game programming?". I don't even think requiring core utilities shipped with an OS, like sed and awk interpreters to be written in C is necessary, and I'm sure I'll be excommunicated for that elsewhere.

I was just making a more general comment about making a language look familiar in terms of basic grammar to minimize the time spent in the initial phase of the learning curve.

I completely understand wanting to go with some code that "looks like" python. More people know how to use Python than C, which is really only for embedded programmers and systems programmers.

Really, this is a nice game scripting language you have here. All the good languages were made by their author for their author.

[tines]

I think it's to make a clean break. The true full synax of C is horrendous and has 1000 edge cases that nobody is aware of until you have to write a C compiler. If you're making a new language, you're not going to support all that. But which subset do you support? Whichever subset you choose, you'll violate someone's expectations, because they thought it was like C.

By breaking with C syntax completely, you can start without expectations.

[president_zippy]

I'm just talking about the basic grammar of C. Scoping with curly braces, statements delimited using semicolons, the basic syntax for defining a function or a struct.

I'm just talking the same level of C familiarity that Java or Javascript went with.

[KolmogorovComp]

> It just seems like these kind of design choices needlessly add a barrier to entry for people who want to climb aboard.

Any experienced programmer knows syntax is a detail, and would not be deterred by that.

[president_zippy]

By that logic, there was no value added in updating the syntax from ANSI C to C99: no reason to add double-slash comments, no reason to allow function-local variables to be declared and initialized where you use them instead of the top of the function, and no reason to omit a return statement for the main() function.

From your reasoning, it also follows that using infix notation instead of Polish notation for arithmetic does absolutely nothing to lower the learning curve.