11 ms·

If you look closely at it, there's not much there - it's actually easy to understand - defines a variant struct and an bunch of accessors to the different types

If you look closely at it, there's not much there - it's actually easy to understand - defines a variant struct and an bunch of accessors to the different types within the embedded union. He prefers short names, and finally years later, java recommends short variable names for lambdas too!

rcxdude 12y ago
Short names make sense if they are easily understandable locally: This means either something extremely common throughout the codebase (I think the most common example being localisation wrappers for string literals. They should ideally be linked to a more clear explanation easily, e.g. from renaming import statements), or defined (clearly) and used only within a very small area of code. This API is neither of those.
- silentbicycle 12y ago
  Short names also make sense if the same conventions appear over and over throughout the code base. While they can be quite opaque at first, they're very consistent, and people with experience in other APLs will recognize many of them.
ryanobjc 12y ago
So, I guess I need to look closer than the pixels then: typedef struct k0{signed char m,a,t;C u;I r;union{G g;H h;I i;J j;E e;F f;S s;struct k0k;struct{J n;G G0[1];};};}K; Sorry I guess I'm just not seeing the "not much there and actually easy to understand" Whatever a 'H' is
- igorii 12y ago
  It definitely is strange to look at, but it's quite easy to understand if you know k/q. H is a short in k/q, so H refers to a short here as well. This naming scheme is true for all of the above letters.
- tiredandgrumpy 12y ago
  This convention is used within the type system throughout kdb+. i for 32bit integer, j for 64bit int, h for 16bit int, e for real, f for float etc. Anyone who knows q will automatically recognize these types in the the c-api. They'll also recognize the ref count r, the type t and experienced c programmers will recognize the trailing array idiom.
- beagle3 12y ago
  Well, it is kind of pointless to look at the K<->C interface without knowing K. If you read the Python.h it would be about as understandable (assume you don't know what a "class" is when studying the Python.h file - because K does a lot of things in ways different enough from most languages). To elaborate: K uses one letter mnemonic codes for all of it's basic storage types: G = General = 8-bit unsigned int H = sHort = 16-bit signed int I = Integer = 32-bit signed int J = bigger integer = 64-bit signed int (Note how G,H,I,J follow each other?) E = 32-bit floating point "rEal" F = 64-bit Floating point (Again, they are near each other) S = Symbol K = "general list type", the central K language type And that's mostly it; the last unnamed union (with fields "n" and "G0") is for vectors, n being the length and G0 being the data. The only other field you are ever going to need is "t" for type (saying whether which union member is actually in use). The rest are internal implementation details, but are also easy to remember: r=reference count; u=flags; m and a have something to do with memory mapping and allocation). There are a few more basic types: b=boolean, t=time,d=date,p=datetime,u=month - but they are merely different interpretations of the EFGHIJSK members above; to access data from C, all you need is the list given above.
  - ryanobjc 12y ago
    interesting. My thoughts on this area have changed a bunch, I think when I was young I was a lot more about cleverness and conciseness. Now that I'm older and I've worked on a large variety of software systems, I am starting to believe that readability of code is one of the most important values. After all, you read the code a lot more than you write it. I can say definitively that: - i have often regretted using single letter variables (outside of loop 'i') - I have very regretted using non-descriptive names - I have never regretted using longer variable/method names Now a days in an IDE environment, longer names doesn't even convey a typing penalty. Yeah yeah I know Java, but it's a safe language, and in a world where I want to deliver working, correct, bug free code, safety is more important than single letter expressiveness. After all, I don't think people hold up APL as good code.
    - deleted 12y ago
      [deleted]
juziozd 12y ago
This is my favourite: // remove more clutter #define O printf #define R return #define Z static ... Removes clutter indeed... :)

rcxdude 12y ago

Short names make sense if they are easily understandable locally: This means either something extremely common throughout the codebase (I think the most common example being localisation wrappers for string literals. They should ideally be linked to a more clear explanation easily, e.g. from renaming import statements), or defined (clearly) and used only within a very small area of code. This API is neither of those.

silentbicycle 12y ago
Short names also make sense if the same conventions appear over and over throughout the code base. While they can be quite opaque at first, they're very consistent, and people with experience in other APLs will recognize many of them.

ryanobjc 12y ago

So, I guess I need to look closer than the pixels then: typedef struct k0{signed char m,a,t;C u;I r;union{G g;H h;I i;J j;E e;F f;S s;struct k0k;struct{J n;G G0[1];};};}K; Sorry I guess I'm just not seeing the "not much there and actually easy to understand" Whatever a 'H' is

igorii 12y ago
It definitely is strange to look at, but it's quite easy to understand if you know k/q. H is a short in k/q, so H refers to a short here as well. This naming scheme is true for all of the above letters.
tiredandgrumpy 12y ago
This convention is used within the type system throughout kdb+. i for 32bit integer, j for 64bit int, h for 16bit int, e for real, f for float etc. Anyone who knows q will automatically recognize these types in the the c-api. They'll also recognize the ref count r, the type t and experienced c programmers will recognize the trailing array idiom.
beagle3 12y ago
Well, it is kind of pointless to look at the K<->C interface without knowing K. If you read the Python.h it would be about as understandable (assume you don't know what a "class" is when studying the Python.h file - because K does a lot of things in ways different enough from most languages). To elaborate: K uses one letter mnemonic codes for all of it's basic storage types: G = General = 8-bit unsigned int H = sHort = 16-bit signed int I = Integer = 32-bit signed int J = bigger integer = 64-bit signed int (Note how G,H,I,J follow each other?) E = 32-bit floating point "rEal" F = 64-bit Floating point (Again, they are near each other) S = Symbol K = "general list type", the central K language type And that's mostly it; the last unnamed union (with fields "n" and "G0") is for vectors, n being the length and G0 being the data. The only other field you are ever going to need is "t" for type (saying whether which union member is actually in use). The rest are internal implementation details, but are also easy to remember: r=reference count; u=flags; m and a have something to do with memory mapping and allocation). There are a few more basic types: b=boolean, t=time,d=date,p=datetime,u=month - but they are merely different interpretations of the EFGHIJSK members above; to access data from C, all you need is the list given above.
- ryanobjc 12y ago
  interesting. My thoughts on this area have changed a bunch, I think when I was young I was a lot more about cleverness and conciseness. Now that I'm older and I've worked on a large variety of software systems, I am starting to believe that readability of code is one of the most important values. After all, you read the code a lot more than you write it. I can say definitively that: - i have often regretted using single letter variables (outside of loop 'i') - I have very regretted using non-descriptive names - I have never regretted using longer variable/method names Now a days in an IDE environment, longer names doesn't even convey a typing penalty. Yeah yeah I know Java, but it's a safe language, and in a world where I want to deliver working, correct, bug free code, safety is more important than single letter expressiveness. After all, I don't think people hold up APL as good code.
  - deleted 12y ago
    [deleted]

juziozd 12y ago

This is my favourite: // remove more clutter #define O printf #define R return #define Z static ... Removes clutter indeed... :)