4 ms·

> (overloading functions) ... comes at a high cost in terms of ... runtime reflection in dynamic languages like Perl, Python or JavaScript In Perl 6 function o

by raiph 11y ago

> (overloading functions) ... comes at a high cost in terms of ... runtime reflection in dynamic languages like Perl, Python or JavaScript In Perl 6 function overloading is generally resolved at compile-time. > Explicit is better than implicit or inexplicit. Explicit what? (jk) > What is so important about the scalar/array dichotomy See my earlier reply to another of your comments. > context sensitive punctuation you have to look up in a legend? Sigils are not context sensitive. > The root of the sigil problem is that you quickly run out of unused ASCII punctuation characters to decorate all the concepts you feel the need to distinguish. The distinction corresponds to major distinctions known to be wired in to human brains: single vs plural, and number vs name. If this seems arbitrary to you perhaps you lack self awareness? (jk)

lmm 11y ago
> The distinction corresponds to major distinctions known to be wired in to human brains: single vs plural, and number vs name. I think we get away with those in natural languages because humans are willing to be fuzzy about that. E.g. whether an organization is singular or plural differs based on context and dialect. Whereas the only distinctions it makes sense to use in programming languages are those that we can make precise.
- DonHopkins 11y ago
  Those advices are new informations to me, but they are all waters under the bridge. Peaces out! ;) http://www.learn-english-today.com/lessons/lesson_contents/grammar/nouns_countables-plurals.html http://www.learn-english-today.com/lessons/lesson_contents/g...
- raiph 11y ago
  > I think we get away with [distinguishing singular/plural and number/name] in natural languages because we are willing to be fuzzy about that ... Whereas the only distinctions it makes sense to use in programming languages are those that we can make precise. I see no conflict between a mental process being a fuzzy "natural language" thing in our brains and the code modelling that concept using a precise formulation. Indeed, to the degree I'm wrong we're in trouble. To read and write code we have to use what we've got -- our brains -- and we have to work with them the way they insist on working: "Janet Siegmund and her colleagues observed 17 participants inside an fMRI scanner while they were comprehending short source-code snippets ... The programmers in the study recruited parts of the brain typically associated with language processing and verbal oriented processing (ventral lateral prefrontal cortex) ... Interestingly, even though there was code that involve mathematical operations, conditionals, and loop iteration, for these particular tasks, programming had less in common with mathematics and more in common with language. Mathematical calculations typically take place in the intraparietal sulcus, mathematical reasoning in the right frontal pole, and logical reasoning in the left frontal pole. These areas were not strongly activated in comprehending source code." ~~ http://www.huffingtonpost.com/chris-parnin/scientists-begin-looking-_b_4829981.html http://www.huffingtonpost.com/chris-parnin/scientists-begin-...
  - lmm 11y ago
    If we process code as if it were natural language, then that argues for having our programming languages emulate natural languages. Even in matters of precision such as legal contracts, we don't always conform exactly to the "rules" of grammar - indeed I'd say that legal language violates those rules even more than natural language does. To my mind that suggests an ideal programming language would not "hardwire" rules of grammar, that sigils should be more like flexible hints to the reader than things that have rigid language-level meanings.
    - raiph 11y ago
      > If we process code [in a particular manner] Apologies if I'm harping on about this too much but I would like to object to "If" as being too ambiguous in this context. The most active non-memory/attention brain circuits used in comprehending the code samples in the study I referenced were consistently for natural language processing, not math/logic processing, for all 17 of the 17 participants in the study. It's a small test but a pretty emphatic one nonetheless. For at least some folk (and it's at least plausibly most/all folk) for at least some code (and it's at least plausibly most/all code), it's "WHEN we comprehend code we use natural language circuits and so...", not "IF...". > that argues for having our programming languages emulate natural languages. Well, careful. Natural languages are fuzzy! We want programming languages that do TWO things -- leverage our natural processing capacities to the degree they're relevant AND render their fuzziness relatively harmless at the same time. > Even in matters of precision such as legal contracts, we don't always conform exactly to the "rules" of grammar - indeed I'd say that legal language violates those rules even more than natural language does. Yes. This is a very important point. Think in terms of thousands of DSLs. How does one enable that? How does one cope with that? > To my mind that suggests an ideal programming language would not "hardwire" rules of grammar Right. The Perl 6 project not only addresses this but is a full frontal assault on it. It's one of the various reasons it took 15 years to get to 6.c. There's a standard Perl 6 grammar but Perl 6 Rules can relatively easily specify any grammar. And I mean any grammar, whether Chomsky hierarchy level 1 (regular languages -- where regexes originally came from) or level 2 (context-free -- where parser combinators have traditionally shone) or level 3 (context-sensitive -- various parser combinators extensions have recently started to nibble at this) or the final level 4 (recursively enumerable languages). Aiui Perl 6 can reasonably be viewed as the world's first practical "universal unrestricted grammar" capable of accepting any other language.[1] > sigils should be more like flexible hints to the reader than things that have rigid language-level meanings. Sure. For starters, sigils are just a part of standard Perl 6. You can write any language in Perl 6. So, for example, the ipso language is a sigil free lang (it's a lisp) in Perl 6[2] and Slang::SQL is for embedded SQL.[3] If we stick to standard Perl 6, sigils just mean a few very general things, as follows. First, that the associated term is primarily a "noun". This determines where it does and doesn't fit in the grammar. Then particular sigils -- the main ones are $, @ and % -- establish some other properties of a given noun. $ emphasizes the noun's singular nature rather than any potential plural nature it might also have. @ emphasizes the noun's plural nature and having an integer index (the array `my @bananas[15]` corresponds to a bunch of 15 bananas indexed by 0 thru 14). And finally % emphasizes plural nature and having an associative index (%colors<red> corresponds to the 'red' key'd value in the %colors dictionary). You might argue that those are rigid. I'd counter that they correspond to human's natural processing circuits. But regardless, if you don't like them or want to repurpose them you can just create a slang or another lang that tweaks or entirely changes the grammar to suit your needs... [1] https://en.wikipedia.org/wiki/Unrestricted_grammar https://en.wikipedia.org/wiki/Unrestricted_grammar [2] https://github.com/masak/ipso https://github.com/masak/ipso [3] https://github.com/tony-o/perl6-slang-sql https://github.com/tony-o/perl6-slang-sql

by raiph 11y ago

lmm 11y ago

> The distinction corresponds to major distinctions known to be wired in to human brains: single vs plural, and number vs name. I think we get away with those in natural languages because humans are willing to be fuzzy about that. E.g. whether an organization is singular or plural differs based on context and dialect. Whereas the only distinctions it makes sense to use in programming languages are those that we can make precise.

DonHopkins 11y ago
Those advices are new informations to me, but they are all waters under the bridge. Peaces out! ;) http://www.learn-english-today.com/lessons/lesson_contents/grammar/nouns_countables-plurals.html http://www.learn-english-today.com/lessons/lesson_contents/g...
raiph 11y ago
> I think we get away with [distinguishing singular/plural and number/name] in natural languages because we are willing to be fuzzy about that ... Whereas the only distinctions it makes sense to use in programming languages are those that we can make precise. I see no conflict between a mental process being a fuzzy "natural language" thing in our brains and the code modelling that concept using a precise formulation. Indeed, to the degree I'm wrong we're in trouble. To read and write code we have to use what we've got -- our brains -- and we have to work with them the way they insist on working: "Janet Siegmund and her colleagues observed 17 participants inside an fMRI scanner while they were comprehending short source-code snippets ... The programmers in the study recruited parts of the brain typically associated with language processing and verbal oriented processing (ventral lateral prefrontal cortex) ... Interestingly, even though there was code that involve mathematical operations, conditionals, and loop iteration, for these particular tasks, programming had less in common with mathematics and more in common with language. Mathematical calculations typically take place in the intraparietal sulcus, mathematical reasoning in the right frontal pole, and logical reasoning in the left frontal pole. These areas were not strongly activated in comprehending source code." ~~ http://www.huffingtonpost.com/chris-parnin/scientists-begin-looking-_b_4829981.html http://www.huffingtonpost.com/chris-parnin/scientists-begin-...
- lmm 11y ago
  If we process code as if it were natural language, then that argues for having our programming languages emulate natural languages. Even in matters of precision such as legal contracts, we don't always conform exactly to the "rules" of grammar - indeed I'd say that legal language violates those rules even more than natural language does. To my mind that suggests an ideal programming language would not "hardwire" rules of grammar, that sigils should be more like flexible hints to the reader than things that have rigid language-level meanings.
  - raiph 11y ago
    > If we process code [in a particular manner] Apologies if I'm harping on about this too much but I would like to object to "If" as being too ambiguous in this context. The most active non-memory/attention brain circuits used in comprehending the code samples in the study I referenced were consistently for natural language processing, not math/logic processing, for all 17 of the 17 participants in the study. It's a small test but a pretty emphatic one nonetheless. For at least some folk (and it's at least plausibly most/all folk) for at least some code (and it's at least plausibly most/all code), it's "WHEN we comprehend code we use natural language circuits and so...", not "IF...". > that argues for having our programming languages emulate natural languages. Well, careful. Natural languages are fuzzy! We want programming languages that do TWO things -- leverage our natural processing capacities to the degree they're relevant AND render their fuzziness relatively harmless at the same time. > Even in matters of precision such as legal contracts, we don't always conform exactly to the "rules" of grammar - indeed I'd say that legal language violates those rules even more than natural language does. Yes. This is a very important point. Think in terms of thousands of DSLs. How does one enable that? How does one cope with that? > To my mind that suggests an ideal programming language would not "hardwire" rules of grammar Right. The Perl 6 project not only addresses this but is a full frontal assault on it. It's one of the various reasons it took 15 years to get to 6.c. There's a standard Perl 6 grammar but Perl 6 Rules can relatively easily specify any grammar. And I mean any grammar, whether Chomsky hierarchy level 1 (regular languages -- where regexes originally came from) or level 2 (context-free -- where parser combinators have traditionally shone) or level 3 (context-sensitive -- various parser combinators extensions have recently started to nibble at this) or the final level 4 (recursively enumerable languages). Aiui Perl 6 can reasonably be viewed as the world's first practical "universal unrestricted grammar" capable of accepting any other language.[1] > sigils should be more like flexible hints to the reader than things that have rigid language-level meanings. Sure. For starters, sigils are just a part of standard Perl 6. You can write any language in Perl 6. So, for example, the ipso language is a sigil free lang (it's a lisp) in Perl 6[2] and Slang::SQL is for embedded SQL.[3] If we stick to standard Perl 6, sigils just mean a few very general things, as follows. First, that the associated term is primarily a "noun". This determines where it does and doesn't fit in the grammar. Then particular sigils -- the main ones are $, @ and % -- establish some other properties of a given noun. $ emphasizes the noun's singular nature rather than any potential plural nature it might also have. @ emphasizes the noun's plural nature and having an integer index (the array `my @bananas[15]` corresponds to a bunch of 15 bananas indexed by 0 thru 14). And finally % emphasizes plural nature and having an associative index (%colors<red> corresponds to the 'red' key'd value in the %colors dictionary). You might argue that those are rigid. I'd counter that they correspond to human's natural processing circuits. But regardless, if you don't like them or want to repurpose them you can just create a slang or another lang that tweaks or entirely changes the grammar to suit your needs... [1] https://en.wikipedia.org/wiki/Unrestricted_grammar https://en.wikipedia.org/wiki/Unrestricted_grammar [2] https://github.com/masak/ipso https://github.com/masak/ipso [3] https://github.com/tony-o/perl6-slang-sql https://github.com/tony-o/perl6-slang-sql