4 ms·

Hmmm, you assume everyone understands that fn means function and that a void function is the same as a procedure. Everybody and their grandma can read Pascal an

Hmmm, you assume everyone understands that fn means function and that a void function is the same as a procedure. Everybody and their grandma can read Pascal and Ada, but abbreviated keywords and magical symbol require foreknowledge. And the more abbreviated, the more you will have to continuously look up things in the reference manual until they get cemented. > Not if you support variant types and the like. Not sure what you mean here - discriminant unions? classes?

jerf 8y ago
"And the more abbreviated, the more you will have to continuously look up things in the reference manual until they get cemented." But something like "fn" isn't going to be a problem, because you're going to use it a dozen times before you finish the tutorial. Symbols are also OK in proportion to their commonality. Rarely used symbols become more problematic. This can be mitigated if there's a clean way to find documentation for them, though you can't get around the problem that google is unlikely to ever be useful for them.
- Verdex 8y ago
  This is actually a property in information theory. Often used symbols should have short representations and rarely used symbols should have long representations. People have a habit of automatically doing this. It's why pretty much every niche field or industry develops jargon and three letter acronyms. Everyone gets tired of saying the whole thing so it's shortened. Not only does it just make sense that things like "fn" are going to be okay, but there's also some mathematical backing as to why it's okay.
  - longstation 8y ago
    This property reminds me of Huffman code.
    - Verdex 8y ago
      Yup. If you checkout the wikipedia page on huffman coding you'll see that David Huffman got his idea while in an information theory class with Robert Fano. Fano had worked with Shannon (the inventor of information theory) to develop a similar coding, but Huffman was able to develop a provably better system.
  - 0xDEEPFAC 8y ago
    Sure, but my point is that "Okay" things are not as good as "Great" things like spelled out type definitions. For example look at this object declaration in Ada - you may not know Ada and the symbols associated with pointers but you will know exactly what it is: type My_Arr is array (1..10) of Natural; My_Fancy_Obj : not null access My_Arr := new My_Arr'(1..4 => 0, others => 1234);
    - DonaldPShimoda 8y ago
      type My_Arr is array (1..10) of Natural; Speaking as someone who works in PL research (but keeping in mind that I'm still low on the totem pole, i.e., I don't have a PhD)... I don't know what this is supposed to mean. Based on the first word being `type`, I'm guessing this is a type declaration for a new type named `My_Arr`. And `is array` makes me think that this is an array of some kind. But then I get to `(1..10)` and I'm lost. Is this a dependent type? Is it an initialized value? I'm genuinely not sure. The `of Natural` at the end tells me that `My_Arr` is an array of natural numbers, I guess, but I'm lost on the `(1..10)` bit. I figure it could either be: a) `My_Arr` is the type of arrays of natural numbers of length 1..10 (is that inclusive? exclusive? unsure) or b) `My_Arr` is the type of arrays consisting of only the natural numbers 1..10 (again, unsure whether inclusive or exclusive) Or I guess it could be something else, though I'm not sure exactly what that'd be. My_Fancy_Obj : not null access My_Arr := ... I guess this is defining an... object? It can't be a type declaration because there's no `type` keyword (which I had previously assumed to indicate the beginning of a type declaration). But this syntax is strange. I assume `My_Fancy_Obj` is the name of the instance in question, so `x : y := z` must mean "create an object named x of type y and store the result of evaluating z there". (I'm guessing based on what I know of other languages.) `not null access` is weird to me. I mean, "not null" is straightforward enough (`My_Fancy_Obj` can never have a null value), but I'm not sure what "access" means. Is it a reference type? Like a pointer? Or something? I dunno what else it could be. So `My_Fancy_Obj` is really a box (reference/pointer) containing a `My_Arr`, and it can never be null. Now... looking at the initialization... ... new My_Arr'(1..4 => 0, others => 1234); I'm so lost haha. I guess the values 1..4 (inclusive? exclusive? shrug) are initialized to zero. And the "others" are initialized to... the value 1,234? I guess? But how long is this array? The presence of an `others` keyword (I'm assuming it's a keyword, or an initialization argument I suppose) tells me that it must be obvious to the interpreter/compiler exactly how many values there are. So... I guess that means `My_Arr` is actually an array of exactly length 10? Why on earth would they have the `array (1..10)` syntax for that, instead of like `array 10` or `array(10)` or something. That's confusing. So I guess we end up with something like `[0, 0, 0, 0, 1234, 1234, 1234, 1234, 1234, 1234]`? Anyway, this example did not achieve your desired result — at least, not from my perspective.
  - coldtea 8y ago
    >People have a habit of automatically doing this Which is also tied into a discussion a few days ago, how the most common verbs (e.g. be) are much shorter and irregular in most languages -- because they are fetched from a direct, small, cache of readily usable forms, and not supposed to be derived from the general rules (e.g. adding -ed) like common verbs (which is slower).
coldtea 8y ago
>Hmmm, you assume everyone understands that fn means function and that a void function is the same as a procedure. No, I don't assume that. But I think that that's irrelevant. People didn't know "def" means function in Python or Scala either, but they learn it on the first day and don't have a readability problem with it. Very basic keywords like "fn" are not the things that make a language unreadable, nor is calling the keyword "fn" instead of "function". Those are memorized in a day or so and you're done with it. It's other things that make languages unreadable (too many sigils, overloaded operators or keywords in different contexts (C++, Perl), single letter operators (e.g. APL), too low level, too much verbosity, etc. In any case, whether a person that first encounter a language immediately recognizes what a keyword means is not what makes the language readable. It's how readable it is to its programmers, after they know the language and have written code in it that matters. Familiar != readable. >Everybody and their grandma can read Pascal and Ada, but abbreviated keywords and magical symbol require foreknowledge. And almost everybody and their grandma dislike their syntax (especially Ada's), and would prefer something less verbose. >And the more abbreviated, the more you will have to continuously look up things in the reference manual until they get cemented. It's after such basics "get cemented" that readability comes into play, not before. If someone has to look after 2-3 days with the language what "fn" means or how to declare a function (and similarly, "def" in Python/Scala, etc), they have some serious memory issues. (Btw, Rust, Clojure, and others also use "fn"). >Not sure what you mean here - discriminant unions? classes? Yes, aka variant, aka tagged union, aka sum type...
- 0xDEEPFAC 8y ago
  > overloaded operators or keywords in different contexts (C++, Perl) Woa there, ever look at vector math libraries in C - horribly unreadable and ugly. > too much verbosity Verbosity describes a programs behavior without implied knowledge thus a reader of some code will understand exactly what is meant. I disagree that the definition of readability is all about how quickly you can skim source code - and ew too many words. > And almost everybody and their grandma dislike their syntax (especially Ada's), and would prefer something less verbose. Well, they were objectively designed to readability based on studies of other languages (at least Ada). And hey, I like it but I guess I am biased : P

jerf 8y ago

"And the more abbreviated, the more you will have to continuously look up things in the reference manual until they get cemented." But something like "fn" isn't going to be a problem, because you're going to use it a dozen times before you finish the tutorial. Symbols are also OK in proportion to their commonality. Rarely used symbols become more problematic. This can be mitigated if there's a clean way to find documentation for them, though you can't get around the problem that google is unlikely to ever be useful for them.

Verdex 8y ago
This is actually a property in information theory. Often used symbols should have short representations and rarely used symbols should have long representations. People have a habit of automatically doing this. It's why pretty much every niche field or industry develops jargon and three letter acronyms. Everyone gets tired of saying the whole thing so it's shortened. Not only does it just make sense that things like "fn" are going to be okay, but there's also some mathematical backing as to why it's okay.
- longstation 8y ago
  This property reminds me of Huffman code.
  - Verdex 8y ago
    Yup. If you checkout the wikipedia page on huffman coding you'll see that David Huffman got his idea while in an information theory class with Robert Fano. Fano had worked with Shannon (the inventor of information theory) to develop a similar coding, but Huffman was able to develop a provably better system.
- 0xDEEPFAC 8y ago
  Sure, but my point is that "Okay" things are not as good as "Great" things like spelled out type definitions. For example look at this object declaration in Ada - you may not know Ada and the symbols associated with pointers but you will know exactly what it is: type My_Arr is array (1..10) of Natural; My_Fancy_Obj : not null access My_Arr := new My_Arr'(1..4 => 0, others => 1234);
  - DonaldPShimoda 8y ago
    type My_Arr is array (1..10) of Natural; Speaking as someone who works in PL research (but keeping in mind that I'm still low on the totem pole, i.e., I don't have a PhD)... I don't know what this is supposed to mean. Based on the first word being `type`, I'm guessing this is a type declaration for a new type named `My_Arr`. And `is array` makes me think that this is an array of some kind. But then I get to `(1..10)` and I'm lost. Is this a dependent type? Is it an initialized value? I'm genuinely not sure. The `of Natural` at the end tells me that `My_Arr` is an array of natural numbers, I guess, but I'm lost on the `(1..10)` bit. I figure it could either be: a) `My_Arr` is the type of arrays of natural numbers of length 1..10 (is that inclusive? exclusive? unsure) or b) `My_Arr` is the type of arrays consisting of only the natural numbers 1..10 (again, unsure whether inclusive or exclusive) Or I guess it could be something else, though I'm not sure exactly what that'd be. My_Fancy_Obj : not null access My_Arr := ... I guess this is defining an... object? It can't be a type declaration because there's no `type` keyword (which I had previously assumed to indicate the beginning of a type declaration). But this syntax is strange. I assume `My_Fancy_Obj` is the name of the instance in question, so `x : y := z` must mean "create an object named x of type y and store the result of evaluating z there". (I'm guessing based on what I know of other languages.) `not null access` is weird to me. I mean, "not null" is straightforward enough (`My_Fancy_Obj` can never have a null value), but I'm not sure what "access" means. Is it a reference type? Like a pointer? Or something? I dunno what else it could be. So `My_Fancy_Obj` is really a box (reference/pointer) containing a `My_Arr`, and it can never be null. Now... looking at the initialization... ... new My_Arr'(1..4 => 0, others => 1234); I'm so lost haha. I guess the values 1..4 (inclusive? exclusive? shrug) are initialized to zero. And the "others" are initialized to... the value 1,234? I guess? But how long is this array? The presence of an `others` keyword (I'm assuming it's a keyword, or an initialization argument I suppose) tells me that it must be obvious to the interpreter/compiler exactly how many values there are. So... I guess that means `My_Arr` is actually an array of exactly length 10? Why on earth would they have the `array (1..10)` syntax for that, instead of like `array 10` or `array(10)` or something. That's confusing. So I guess we end up with something like `[0, 0, 0, 0, 1234, 1234, 1234, 1234, 1234, 1234]`? Anyway, this example did not achieve your desired result — at least, not from my perspective.
- coldtea 8y ago
  >People have a habit of automatically doing this Which is also tied into a discussion a few days ago, how the most common verbs (e.g. be) are much shorter and irregular in most languages -- because they are fetched from a direct, small, cache of readily usable forms, and not supposed to be derived from the general rules (e.g. adding -ed) like common verbs (which is slower).

coldtea 8y ago

>Hmmm, you assume everyone understands that fn means function and that a void function is the same as a procedure. No, I don't assume that. But I think that that's irrelevant. People didn't know "def" means function in Python or Scala either, but they learn it on the first day and don't have a readability problem with it. Very basic keywords like "fn" are not the things that make a language unreadable, nor is calling the keyword "fn" instead of "function". Those are memorized in a day or so and you're done with it. It's other things that make languages unreadable (too many sigils, overloaded operators or keywords in different contexts (C++, Perl), single letter operators (e.g. APL), too low level, too much verbosity, etc. In any case, whether a person that first encounter a language immediately recognizes what a keyword means is not what makes the language readable. It's how readable it is to its programmers, after they know the language and have written code in it that matters. Familiar != readable. >Everybody and their grandma can read Pascal and Ada, but abbreviated keywords and magical symbol require foreknowledge. And almost everybody and their grandma dislike their syntax (especially Ada's), and would prefer something less verbose. >And the more abbreviated, the more you will have to continuously look up things in the reference manual until they get cemented. It's after such basics "get cemented" that readability comes into play, not before. If someone has to look after 2-3 days with the language what "fn" means or how to declare a function (and similarly, "def" in Python/Scala, etc), they have some serious memory issues. (Btw, Rust, Clojure, and others also use "fn"). >Not sure what you mean here - discriminant unions? classes? Yes, aka variant, aka tagged union, aka sum type...

0xDEEPFAC 8y ago
> overloaded operators or keywords in different contexts (C++, Perl) Woa there, ever look at vector math libraries in C - horribly unreadable and ugly. > too much verbosity Verbosity describes a programs behavior without implied knowledge thus a reader of some code will understand exactly what is meant. I disagree that the definition of readability is all about how quickly you can skim source code - and ew too many words. > And almost everybody and their grandma dislike their syntax (especially Ada's), and would prefer something less verbose. Well, they were objectively designed to readability based on studies of other languages (at least Ada). And hey, I like it but I guess I am biased : P