> No polymorphism, generics
makes it DOA for me. Also the fact that this is a GC language makes it feel like it's aiming at higher level applications than C.
Granted, that also means Tomo probably has better incremental compilation, and would likely be more amiable to creating shared libraries. You can do that with Nim, too, but the external interface (generally) has to be "C" semantics (similar to most other "high level" languages).
Why's that? There's a gc/no-gc barrier to cross, and also being able to use other features in an implementation doesn't make creating a C interface harder.
I don't know if Tomo supports anything like that, but not having generics would make it easier/simpler to implement (e.g. no need to mangle symbol names). Note "easier/simpler", Nim can also "precompile Nim libraries for Nim code", but the resulting libraries are brittle (API-wise), and only really useful for specific use cases like creating binary Nim plugins to import to another Nim program, where you'll want to split out the standard runtime library [0] and share it across multiple images. It's not useful for e.g. precompiling the standard library to save time.
I know Nim has been working on incremental compilation, too, but I don't know what the state of that is. I think it might have been punted to the rewritten compiler/runtime "Nim 3".
It's also smart to facilitate integration with C or other languages that have an abundance of libraries, because it's unlikely that you will create the momentum to rewrite everything in your facorite baby language.
And as a result of the parsing step, you get a fully typed struct
I wish it was an embeddable language like Lua though - there are a gazillion languages that are similar to this that you can use for non-embeddable cases... But there are very very few statically typed embeddable scripting languages. The only ones I know of are Gluon, which leans waaaay too far into the obscure functional stuff for a scripting language... and AngelScript which is just a bit too ancient and Javaesque for me.
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.
By breaking with C syntax completely, you can start without expectations.
I'm just talking the same level of C familiarity that Java or Javascript went with.
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.
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.
Any experienced programmer knows syntax is a detail, and would not be deterred by that.
From your reasoning, it also follows that using infix notation instead of Polish notation for arithmetic does absolutely nothing to lower the learning curve.
1) using 0 as the index of the first element in a list-like object ISA holdover from C (most of the earlier languages used either 1 based or flexible base for indexing);
2) in C, 0 is the index due to the manner of C’s array indexing implementation;
3) if holding onto the C semantics (or syntax in some respects) is not an explicit goal of the language, then flexible indexing should be the default (declared at creation point for the list-like object);
4) in flexible default is not appealing to the language designer, and again, maintaining C semantics is not a goal, then 1 based should be the next reasonable default.
For me, when counting things (and most other native English speakers, if not most people in general), the first item counted is object 1. Therefore, 1 should be the index of the beginning of the list-like objects indexing.
I’m not sure how about 0 being ‘None’, but I might find it intuitive if thinking more about it.
func greeting(name:Text, add_exclamation:Bool -> Text)
az09mugen•1w ago