Author Topic: Readability of keywords "uint32", "float64" etc  (Read 310 times)

acbaile

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Readability of keywords "uint32", "float64" etc
« on: September 22, 2018, 01:30:18 AM »

    Names uint8 ... uint64, float32, float64 are more readable than u8 ... u64, f32, f64.

    I see, in first presentation - several years ago - you used full names. Funny, in my С code I use the same names :) - it is very good when you see exactly how long integer type is. This maldefinition was bad feature of C. Main quality of program is full determination. There is no errors when it is.

    Names uint8 ... uint64 are more C-styled. It is easier to understand program code when you read these longer names.

    In common, i think when good idea appears, some people (that don't like this idea, but look like your friends) try to make it worse - :) by "good" advises. It is strange that you changed well readable names for short ones. Why did you do it?

    You removed header files - maybe, the worst feature of C - it breaks incapsulation very well.

    Objects have to be static, not public by default - it's cool.

    I wish you luck. I hope - after removing bad traits of C - C2 will replace it.

    P.S. Please, don't be disappointed if in following I say critics only :) . I see a lot of excellent improvements that you did already, and I smile when I see it. But attention is on problem places.
« Last Edit: November 18, 2018, 05:25:55 AM by acbaile »

bas

  • Full Member
  • ***
  • Posts: 209
    • View Profile
Re: Readability of keywords "uint32", "float64" etc
« Reply #1 on: September 24, 2018, 12:15:51 PM »
C2 started out with the short versions (u8, etc), then returned to versions. After a while, this didn't feel right, so it was changed back to the short
versions. In the end, it takes a bit of getting used to, but it is easier on the eyes. This is the same as Rust btw.

Encapsulation at compile time level does not exist anymore at all, since the C2 compiler has a different unit of compilation. Having no
headers avoids a lot of issues and increasing the unit of compilation also allows some pretty nice features.

acbaile

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: Readability of keywords "uint32", "float64" etc
« Reply #2 on: September 25, 2018, 01:35:15 AM »
In the end, it takes a bit of getting used to, but it is easier on the eyes. This is the same as Rust btw.

I included these short names in my C code for testing feelings. Will report.

acbaile

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: Readability of keywords "uint32", "float64" etc
« Reply #3 on: September 29, 2018, 09:33:44 AM »
    It seems, i stay with longer names. When i read code, it is easier to understand what it is and what it does. Longer names are more-speaking to me. Maybe, it is human-dependent.

    Yes, sometimes, names of my functions are too long ) . But when i read its name i know what exactly it does. It is simplier to understand what code does after time.

    If to tell about spirit of C, your short names are outside of it. Other keywords are longer. I think, the goal of longer names is to bring into the programmer's mind mental image with reading keyword. When you read only u this idea does not appear.

    I love creators of C very much. They knew what they do. Symbolism is very cool. This language describes not computer programming only, but life too. For example, * - asterisk - is like lips in kissing. Or { - is like hands embracing. When somebody "kisses" you, that means "go there, it's pointer for you, i can not say directly, i can only "kiss", metaphorically, by eyes) :) .

    C has sound like [See!] :) .

    int has good sound. [inned] - something internal. So, i cry when i see that you eliminated int32, int64 etc

    P.S. while(true){ - is my favorite cycle  ;)
« Last Edit: November 18, 2018, 03:47:20 AM by acbaile »

acbaile

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: Readability of keywords "uint32", "float64" etc
« Reply #4 on: September 30, 2018, 09:44:26 AM »
Another example - С code is easier to understand then assembler mnemonics. Names are too short - this is step in direction of assembler. When you are geak (i am) these names tell everything to you. But most of programmers will not like it. I remind, your language will be used widely.

P.S. These ultra-short keywords are similar to assembler mnemonics...
« Last Edit: October 08, 2018, 08:20:43 PM by acbaile »

lerno

  • Full Member
  • ***
  • Posts: 218
    • View Profile
Re: Readability of keywords "uint32", "float64" etc
« Reply #5 on: October 17, 2018, 11:06:20 PM »
I prefer the shorter 'u8' 'i8' 'f32' etc. However, I would actually like to see a plain "int" which is "native data size" for the platform just to keep things simple, readable and efficient.

acbaile

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: Readability of keywords "uint32", "float64" etc
« Reply #6 on: October 18, 2018, 05:36:49 PM »
However, I would actually like to see a plain "int" which is "native data size" for the platform just to keep things simple, readable and efficient.

    Bas will not agree with you :) . Main quality of program is full determination. When type has different sizes on different platforms errors and difficulties appear. Even more, this determination makes thinking simplier.


I prefer the shorter 'u8' 'i8' 'f32' etc.

    I prefer assembler mnemonics instead of opcode/ModRM numbers. One of the goals of high level programming language is to make programming more ergonomical. Longer names bring into programmer's consciousness brighter ideas.
« Last Edit: November 18, 2018, 03:30:20 AM by acbaile »

lerno

  • Full Member
  • ***
  • Posts: 218
    • View Profile
Re: Readability of keywords "uint32", "float64" etc
« Reply #7 on: October 19, 2018, 10:09:31 AM »
I’ve written quite a bit of code with the i32/i64/f32 format - as well as using uint/int etc. Two issues:

  • i32/i64 has poor readability in a loop syntax wise
  • You sometimes want ”fastest int” - c2 has no concept of that right now. It’s important to be able to use different code in different architectures.
  • For a loop i32/i64 is overspecification. You only want the most efficient thing to keep in a register and inc/dec

I *like* i32 etc, but we need to make fast loops easy. And we need to be able to determine register size in an easy way.

Introducing int = ”fastest that is at least 32 bit” would hit a sweet spot.

acbaile

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: Readability of keywords "uint32", "float64" etc
« Reply #8 on: October 19, 2018, 11:38:24 PM »
You sometimes want ”fastest int”
You only want the most efficient thing to keep in a register and inc/dec
... we need to make fast loops easy.
Introducing int = ”fastest that is at least 32 bit” would hit a sweet spot.

You can use simply "uint32" for this purpose. Without introducing to language element of uncertainty.

If you are designing code that will work on platforms with 32-bit registers too, range of "uint32" is enough for your algorithm. It looks like inventing of nonexistent tasks.

Certainty is more important. I suffer when i think: "Why this type has this size here, and another there?" How can i write reliable code with this uncertainty? This is spring of errors and difficulties. This uncertainty was bad trait of C, and it is very good, that it is removed.

It is better to have NOT this uncertain type to avoid uncertain usage of it in libraries, examples, study and practice.

And we need to be able to determine register size in an easy way.

This idea is good.
« Last Edit: October 19, 2018, 11:42:51 PM by acbaile »

lerno

  • Full Member
  • ***
  • Posts: 218
    • View Profile
Re: Readability of keywords "uint32", "float64" etc
« Reply #9 on: October 20, 2018, 01:41:03 AM »
Hmm maybe. It sort of depends on how the macro system looks later on.

bas

  • Full Member
  • ***
  • Posts: 209
    • View Profile
Re: Readability of keywords "uint32", "float64" etc
« Reply #10 on: October 22, 2018, 11:44:12 AM »
Currently in C if you want to write portable code, you often avoid the use of int, since since changes
the behaviour between platforms. Other recent languages (like Rust) do still have a general integere type
(isize/usize in Rust). I'm not sure if there is a real performance penalty (and how big) of using a 32bit
integer on a 64bit system. If there is a big one, we should introduce a generic 'int' like type.

lerno

  • Full Member
  • ***
  • Posts: 218
    • View Profile
Re: Readability of keywords "uint32", "float64" etc
« Reply #11 on: October 22, 2018, 05:04:33 PM »
I would use it exclusively for loops BTW, for any data structure I'd use explicit sizes.

I did a little research and seems like the question is a bit deeper than I first thought. int/i32/i64 will affect register allocation, so performance depends a bit on the processor.

Something "good to have" out of the box is getting information form the compiler directly into the macro system to know things like data width, # and types of registers available, endianness and so on.

acbaile

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: Readability of keywords "uint32", "float64" etc
« Reply #12 on: October 29, 2018, 06:10:04 AM »
Currently in C if you want to write portable code, you often avoid the use of int, since since changes
the behaviour between platforms.

It's true!

I'm not sure if there is a real performance penalty (and how big) of using a 32bit
integer on a 64bit system.

It seems, lerno means using 64-bit integers on 32-bit systems.

If 32-bit integer on 64-bit system - performance is the same. On Intel exactly.

If lerno makes code for 32-bit system too, range of uint32 is enough for his algorithm.

If there is a big one, we should introduce a generic 'int' like type.

It's very rare case. If programmer needs it, he can introduce it with preprocessor and typedef.

Unambiguity of language is more important.
« Last Edit: October 29, 2018, 06:12:02 AM by acbaile »

acbaile

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: Readability of keywords "uint32", "float64" etc
« Reply #13 on: November 03, 2018, 10:14:52 AM »
lerno can use type "size_t" to have fast integer. It is better to define this type by preprocessor. Core of C2 must stay unambiguous.

bas

  • Full Member
  • ***
  • Posts: 209
    • View Profile
Re: Readability of keywords "uint32", "float64" etc
« Reply #14 on: November 08, 2018, 11:09:19 AM »
It's common to store pointers in numbers. Code like that often keeps track of the meaning of the value. It could be a real number or a pointer.
For code like this, having a usize/isize is a real requirement.