4 ms·
Yup, the type names for integers (byte, short, int, long, etc.) are borrowed from C#. All primitives in Muon have a well-defined, platform/architecture independ
by nickmqb 8y ago
Yup, the type names for integers (byte, short, int, long, etc.) are borrowed from C#. All primitives in Muon have a well-defined, platform/architecture independent size. Two exceptions: ssize and usize (machine word sized integers), which are mostly used for C interop.
C# programmers should feel right at home, but you're right that there is a very slight learning curve for others.
But, I hear you! I've personally worked a lot with C# which is why I chose the current names, but I realize that there are others that prefer the explicit names (u8, i8, etc.). I'll be adding a type aliasing feature soon, so anyone who wants to define their own alternative type names will be free to do so. At that point it may also make sense to use explicit names as the default.
- zeotroph 8y agoRelated, and very much a personal preference: Given that there will be no classes etc, isn't the use of camel case (and the not-that-different Pascal Case) for both structs and functions giving up a dimension of distinction? The ClassCamel and snake_function_case split of Python and Rust is something I bikeshed about often - sooner or later 'IO', 'TCP' or 'MMbT' needs to be CamelCased and then it all goes downhill. Or C and C++ (the latter is also mentioned as an inspiration), which never used CamelCase. I think Java then used it purely to distinguish itself also by style from these direct and unsafe memory poking languages.
- nickmqb 8y agoI'm not sure if I understood your question correctly, but lowerCamel vs snake_case is not guaranteed to be different right? E.g. if you have an identifier consisting of a single word. I'd recommend using UpperCamel for namespaces/types (including structs), and either lowerCamel or snake_case for everything else. I personally like that approach because it makes it possible to distinguish between a regular function call and an instance call, e.g.: SomeNamespace.foo() vs someLocalVar.bar(). That said, the language doesn't enforce any particular naming scheme, so people are free to do what they want. Once the type aliasing feature lands, they can even create alternate names for existing types.
- cpeterso 8y agoI'm surprised that Ada's Camel_Snake_Case isn't more common. It's no more verbose than snake_case but easier to read the words like a natural language and avoids acronym capitalization ambiguities, e.g. "XML_HTTP_Request" instead of "XMLHttpRequest".
- int_19h 8y agoI think it's uncommon because it is redundant - if you already have underscores to separate words, why capitalize? Personally, though, I find casing to be a better way to split up words in languages which have . as a member access operator, for the simple reason that it makes property or method call chains more readable. When you have both dots and underscores in the mix, they both register up as whitespace first, and then you have to distinguish which is which. When it's just dots, it's clear where the boundaries are.
- akavel 8y agoWould C# programmers have any trouble understanding what uint32 etc. are? Whereas, although having long experience with C++, I still feel I always have to reach out for the particular OS's docs to find out what are the specific lengths, again? (For unsigned long, etc.) In other words, I believe explicit naming like uint32 is just universally trivial and ergonomic (including for C# programmers), while short etc. is kinda probably ergonomic for experienced C# programmers (I suppose beginners don't remember it well yet, and also have to consult the manual), while strictly wasting time and brain cycles for programmers coming from other languages :( Please — like, pretty please!...
- arethuza 8y agoProbably not as in C# things like int, uint, long etc. are actually aliases for types like System.Int32, System.UInt32, System.Int64...
- dev_zero 8y agoThanks, that sounds like a great way forwards.