5 ms·

I have a criticism regarding how basic data types are named: https://github.com/nickmqb/muon/blob/master/docs/muon_by_example.md#core-types https://github.com/n

by tagrun 8y ago

I have a criticism regarding how basic data types are named: https://github.com/nickmqb/muon/blob/master/docs/muon_by_example.md#core-types https://github.com/nickmqb/muon/blob/master/docs/muon_by_exa... Type names like long, short, char (and the oh-so-dear long long) are ancient cruft which shouldn't be used in a new programming language. They are confusing (as in, the answer to question: how many bits are there in your int, long, short depends on both arch and compiler) and since 70s we discovered it the hard way that they're non-extensible (multiple times, actually!). Similar for the fate of char in the post-ASCII world. C still keeps them for backward compatibility, but types like uint32_t defined in stdint.h is becoming common practice for new code. The choices are also not compatible with C or Go, adding further to the confusion (Muon's int is 32-bit and long is 64-bit on all archs!), so even for C/C++ and Go programmers, the nostalgia turns into a pitfall. Having no familiarity with C# (not much of a Windows user since late-90s, and C# virtually doesn't exist for Linux/macOS people which Muon claims to be targeting), I looked it up, and it seems it's based on C#'s distorted and incompatible adoption of C89's data types. Go applies the same custom to float/double as float32/float64 which makes it uniform. Go also defines int to be the size of the native integer register size on the target arch (which I like because this is what int supposed to mean originally, this was the common understanding when porting between C and assembly, although some may disagree after ~50 years of weird adaptations of it) which unifies uint and size_t, rendering size_t obsolete. Ironically, Muon makes use of explicit number-of-bits suffix for one data type: bool32 (and there's no bool16 or bool64). I don't even know why one might have it as a basic language type. I really hope he adopts a naming convention that is similar to C99's stdint.h or Go (which the author claims to be inspired by), or their shorter cousins u8, u16, ... used in Linux source code.

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 ago
  Related, 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 ago
    I'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 ago
    I'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 ago
      I 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.
apta 8y ago
> Go also defines int to be the size of the native integer register size on the target arch Which is quite redundant, not to mention causes issues when porting between different architectures. Rust does the right thing by using `isize` and `usize` to make it explicit.
- nickmqb 8y ago
  I agree that Rust takes the right approach. Muon follows it, the corresponding types are ssize and usize.
  - andrewchambers 8y ago
    Umm, I don't think you understood his comment... The rust way would be i64, not literally 'ssize'.
    - nickmqb 8y ago
      I'm not sure that I follow you, just to clarify: Muon.ssize == Rust.isize == Go.int ('usually', according to https://tour.golang.org/basics/11 https://tour.golang.org/basics/11) Muon.usize == Rust.usize == Go.uint Muon.long == Rust.i64 == Go.int64 This is a list of all core types in Muon: https://github.com/nickmqb/muon/blob/master/docs/muon_by_example.md#core-types https://github.com/nickmqb/muon/blob/master/docs/muon_by_exa...
- tagrun 8y ago
  It isn't redundant because that's the only type in Go which does that. There is no issue because int is explicitly defined to mean the CPU word. As I already mentioned above, due to how its meaning mutated and got distorted over time, it may be better to use a different word. usize/isize is also fine IMO.
ngcc_hk 8y ago
Why not call it register size or something like that and then define it .h. Integer means something else for “normal” people, even though after 40 years I get used to it.
- tagrun 8y ago
  I know what you mean, but one can say "which register", though. Intel CPUs have registers ranging from 8 to 512 bits these days.
int_19h 8y ago
> They are confusing (as in, the answer to question: how many bits are there in your int, long, short depends on both arch and compiler) and since 70s we discovered it the hard way that they're non-extensible (multiple times, actually!). Did we though? The original design, as it was in ALGOL 68, was very much extensible - it specifically said that SHORT and LONG are 1) prefixes, not types, and 2) any amount of them is valid, but the implementation only has to provide SHORT INT, INT and LONG INT, and then the rest are there for shorter and longer implementation-defined types. What broke it in C mainly that instead of the obvious sequence of short-int-long being 16/32/64 from the get go, they have reused int to mean "most common type". So the original 16-bit architectures had short and int being basically the same, making short redundant. Then on 32-bit, int was changed, but again in a broken way where it was now mapped to long, making that redundant (but still heavily used!). Which set up the 64-bit disaster, where Windows wouldn't make long 64-bit because too much code was out there assuming that it was 32-bit. If we kept short/int/long separate all along, and didn't try to redefine them afterwards, we wouldn't even need long long today.
- tagrun 8y ago
  I'd rather say having such ambiguous adjectives for types was a bad idea to begin with. And it falls apart when something longer than the original long comes out. I'm not blaming them for not being explicit about the # of bits back then, though, because back then memory addressing unit (byte) wasn't universally 8-bits and word size wasn't a multiple of 8 either (and some archs weren't even binary): https://en.wikipedia.org/wiki/Word_(computer_architecture)#Table_of_word_sizes https://en.wikipedia.org/wiki/Word_(computer_architecture)#T... It seems a naming convention in units of bytes could've been possible though (with the exception of a few archs).
  - int_19h 8y ago
    The original design doesn't fall apart, because it allowed multiple prefixes - LONG INT, LONG LONG INT etc - from the get go, specifically so that the list of types could be extended arbitrarily. It's not the most concise or descriptive way to name them, but that's an issue distinct from extensibility. Personally, I think that rather than focusing on number of bits for numeric types, type systems should focus on the valid range of values, more along the lines of Pascal and Ada.
darklajid 8y ago
> C# virtually doesn't exist for Linux/macOS people which Muon claims to be targeting I understand what you're saying, but there exist C# desktop applications for Linux/MacOS for quite a long time - say, Banshee, Tomboy come to mind - and dotnet core should be a decent platform for backend services on these platforms by now.
- tagrun 8y ago
  I'm not saying there are zero C# programs in GNU/Linux distro repos. I'm saying compared to its status in Windows world, it's a niche language with very low penetration. C# never got popular in Linux or BSD environments (partially because how Microsoft was hostile against the entire FOSS when it came out) and I personally don't believe it ever will, given the more recent renaissance of languages which brought us Go, Rust, etc which are safe, compiled and truly cross-platform alternatives to C/C++. There are a few (GNOME) programs, which can be attributed to Miguel de Icaza. They tried pushing for Mono despite all the FUD surrounding C#, but I can't say they got much far. I know it's tiny sample but neither I, nor many GNU/Linux users around me know C# or ever needed to use it.
  - dragonwriter 8y ago
    I agree that it hasn't, but I'd be surprised if .NET Core doesn't shift the needle on that a bit over time. Previously, Linux was definitely not first tier in C# support (at least in terms of supporting ecosystem, which is as important as the language itself), but that is changing.
    - intertextuality 8y ago
      To give anecdata, for my job I have been working on a C# web api codebase since last September, on OSX. With .NET Core and Rider. If I developed a game I would 100% use mono + xna now on OSX.
  - backpropaganda 8y ago
    FWIW, Unity and Monogame are two popular game engines which deploy C# code to Mac and Linux using Mono. If a modern game runs on Mac/Linux, there's a high chance it's using C#/Mono. So to me, "niche" doesn't seem like an accurate description.

by tagrun 8y ago

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 ago
Related, 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 ago
  I'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 ago
  I'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 ago
    I 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.

apta 8y ago

> Go also defines int to be the size of the native integer register size on the target arch Which is quite redundant, not to mention causes issues when porting between different architectures. Rust does the right thing by using `isize` and `usize` to make it explicit.

nickmqb 8y ago
I agree that Rust takes the right approach. Muon follows it, the corresponding types are ssize and usize.
- andrewchambers 8y ago
  Umm, I don't think you understood his comment... The rust way would be i64, not literally 'ssize'.
  - nickmqb 8y ago
    I'm not sure that I follow you, just to clarify: Muon.ssize == Rust.isize == Go.int ('usually', according to https://tour.golang.org/basics/11 https://tour.golang.org/basics/11) Muon.usize == Rust.usize == Go.uint Muon.long == Rust.i64 == Go.int64 This is a list of all core types in Muon: https://github.com/nickmqb/muon/blob/master/docs/muon_by_example.md#core-types https://github.com/nickmqb/muon/blob/master/docs/muon_by_exa...
tagrun 8y ago
It isn't redundant because that's the only type in Go which does that. There is no issue because int is explicitly defined to mean the CPU word. As I already mentioned above, due to how its meaning mutated and got distorted over time, it may be better to use a different word. usize/isize is also fine IMO.

ngcc_hk 8y ago

Why not call it register size or something like that and then define it .h. Integer means something else for “normal” people, even though after 40 years I get used to it.

tagrun 8y ago
I know what you mean, but one can say "which register", though. Intel CPUs have registers ranging from 8 to 512 bits these days.

int_19h 8y ago

> They are confusing (as in, the answer to question: how many bits are there in your int, long, short depends on both arch and compiler) and since 70s we discovered it the hard way that they're non-extensible (multiple times, actually!). Did we though? The original design, as it was in ALGOL 68, was very much extensible - it specifically said that SHORT and LONG are 1) prefixes, not types, and 2) any amount of them is valid, but the implementation only has to provide SHORT INT, INT and LONG INT, and then the rest are there for shorter and longer implementation-defined types. What broke it in C mainly that instead of the obvious sequence of short-int-long being 16/32/64 from the get go, they have reused int to mean "most common type". So the original 16-bit architectures had short and int being basically the same, making short redundant. Then on 32-bit, int was changed, but again in a broken way where it was now mapped to long, making that redundant (but still heavily used!). Which set up the 64-bit disaster, where Windows wouldn't make long 64-bit because too much code was out there assuming that it was 32-bit. If we kept short/int/long separate all along, and didn't try to redefine them afterwards, we wouldn't even need long long today.

tagrun 8y ago
I'd rather say having such ambiguous adjectives for types was a bad idea to begin with. And it falls apart when something longer than the original long comes out. I'm not blaming them for not being explicit about the # of bits back then, though, because back then memory addressing unit (byte) wasn't universally 8-bits and word size wasn't a multiple of 8 either (and some archs weren't even binary): https://en.wikipedia.org/wiki/Word_(computer_architecture)#Table_of_word_sizes https://en.wikipedia.org/wiki/Word_(computer_architecture)#T... It seems a naming convention in units of bytes could've been possible though (with the exception of a few archs).
- int_19h 8y ago
  The original design doesn't fall apart, because it allowed multiple prefixes - LONG INT, LONG LONG INT etc - from the get go, specifically so that the list of types could be extended arbitrarily. It's not the most concise or descriptive way to name them, but that's an issue distinct from extensibility. Personally, I think that rather than focusing on number of bits for numeric types, type systems should focus on the valid range of values, more along the lines of Pascal and Ada.

darklajid 8y ago

> C# virtually doesn't exist for Linux/macOS people which Muon claims to be targeting I understand what you're saying, but there exist C# desktop applications for Linux/MacOS for quite a long time - say, Banshee, Tomboy come to mind - and dotnet core should be a decent platform for backend services on these platforms by now.

tagrun 8y ago
I'm not saying there are zero C# programs in GNU/Linux distro repos. I'm saying compared to its status in Windows world, it's a niche language with very low penetration. C# never got popular in Linux or BSD environments (partially because how Microsoft was hostile against the entire FOSS when it came out) and I personally don't believe it ever will, given the more recent renaissance of languages which brought us Go, Rust, etc which are safe, compiled and truly cross-platform alternatives to C/C++. There are a few (GNOME) programs, which can be attributed to Miguel de Icaza. They tried pushing for Mono despite all the FUD surrounding C#, but I can't say they got much far. I know it's tiny sample but neither I, nor many GNU/Linux users around me know C# or ever needed to use it.
- dragonwriter 8y ago
  I agree that it hasn't, but I'd be surprised if .NET Core doesn't shift the needle on that a bit over time. Previously, Linux was definitely not first tier in C# support (at least in terms of supporting ecosystem, which is as important as the language itself), but that is changing.
  - intertextuality 8y ago
    To give anecdata, for my job I have been working on a C# web api codebase since last September, on OSX. With .NET Core and Rider. If I developed a game I would 100% use mono + xna now on OSX.
- backpropaganda 8y ago
  FWIW, Unity and Monogame are two popular game engines which deploy C# code to Mac and Linux using Mono. If a modern game runs on Mac/Linux, there's a high chance it's using C#/Mono. So to me, "niche" doesn't seem like an accurate description.