5 ms·

"So far I have not found..." What else have you tried?

by jingo 13y ago

Mithaldu 13y ago
I think it's important to note that there is an implication in his question of the code of the alternative being as easy to read and write as Perl. One could of course write a much faster text processing tool in Assembler, but well ...
- TylerE 13y ago
  > easy to read as Perl. So, that rules out Brainf--k I guess
  - Mithaldu 13y ago
    Yes that is correct. Brainfuck is not as readable as Perl. (I think you need to train more with your witty comebacks. Also drop the meme that Perl is not very readable, when it has lately improved a LOT [1] in that regard.) [1] https://metacpan.org/module/Moo#SYNOPSIS https://metacpan.org/module/Moo#SYNOPSIS
    - TylerE 13y ago
      But actually look at the SOURCE of Moo instead of a toy example, and I see plenty of stuff that's exactly the kind of suboptimal readability I associate with perl....sigils all over the place, @_, the lack of proper function argument handling, etc. Any toy example can be made to look clean.
      - Mithaldu 13y ago
        Yeah, sorry man, at the point where you complain about sigils you've disqualified yourself from the discussion for lack of thinking things through far enough. Thanks for playing, bub.
        TylerE 13y ago
        Why, "bub", most sane languages don't have such cryptic, hard to read incantations. But you're obviously a zealot with a closed mind so I'm not sure why I'm even bothering to reply.
        Mithaldu_ 13y ago
        Apparently one of the mods decided i shouldn't be able to reply, thus different account. Here's a serious answer for you: You complained about the simple presence of sigils, without even stopping to think and consider what advantages they bring. I may be rude, but close-minded? No.
        TylerE 13y ago
        Explain how requiring a sigil in the default case improves readability. Imagine how ugly C would be if every variable that wasn't a pointer dereference had to be prefixed with $. I am not necessarily opposed to meaningful sigils, e.g. Ruvy's @, but using them everywhere is a pure misfeature that hurts readability.
        meepmeepmeepmee 13y ago
        I'll happily explain, thanks for asking. First off, in Perl the parens for a function call are not mandatory. As such it is very useful for functions and variables to be visually difference, especially when you're using functions to generate parameters for other functions without any temp variables inbetween. my W = qq_mult ConjugateQ, qv_mult RotationQ, Vector; You can't tell at a glance what's going on and will need to look carefully. Adding sigils makes it quite clear: my $W = qq_mult $ConjugateQ, qv_mult $RotationQ, $Vector; Further, most languages have only one type of variable, a name for a single thing. Perl has multiple types of variables that behave differently. For example: my $res = munge $one; I see this and know that the function munge is passed one single variable. However, consider this: my $res = munge @two; If there wasn't the @ there, it would be easy to assume that munge gets exactly one argument. However the @ there alerts us to the fact that @two is an auto-flattening array, and munge will end up with anywhere between 0 and MAX_INT arguments passed to it. Similarly with hashes: my $res = munge @two; They also auto-flatten, so they need to be marked as being different from scalars, but they also flatten in a very different way from array, in that they flatten into a list that alternates the keys and values. So they need to be marked differently from arrays. Lastly, due to functions, variables, array and hashes having explicit sigils, they can be recognized by editors without any heavy analysis, enabling editors to mark these four types with different colors, which is extremely useful. Personally i don't see the sigils anymore, and instead just see the colors with which the types are highlighted. (Bonus set: Actually C is often written with sigils too. I've often seen code where variables are prefixes with p_, s_, a_, i_, etc. They are not enforced by the language, but people often force themselves to use them. The downside: They are inconsistent from project to project and have to be relearned every time.)
    - deleted 13y ago
      [deleted]

"So far I have not found..." What else have you tried?

by jingo 13y ago

"So far I have not found..." What else have you tried?

I think it's important to note that there is an implication in his question of the code of the alternative being as easy to read and write as Perl. One could of course write a much faster text processing tool in Assembler, but well ...

TylerE 13y ago
> easy to read as Perl. So, that rules out Brainf--k I guess
- Mithaldu 13y ago
  Yes that is correct. Brainfuck is not as readable as Perl. (I think you need to train more with your witty comebacks. Also drop the meme that Perl is not very readable, when it has lately improved a LOT [1] in that regard.) [1] https://metacpan.org/module/Moo#SYNOPSIS https://metacpan.org/module/Moo#SYNOPSIS
  - TylerE 13y ago
    But actually look at the SOURCE of Moo instead of a toy example, and I see plenty of stuff that's exactly the kind of suboptimal readability I associate with perl....sigils all over the place, @_, the lack of proper function argument handling, etc. Any toy example can be made to look clean.
    - Mithaldu 13y ago
      Yeah, sorry man, at the point where you complain about sigils you've disqualified yourself from the discussion for lack of thinking things through far enough. Thanks for playing, bub.
      - TylerE 13y ago
        Why, "bub", most sane languages don't have such cryptic, hard to read incantations. But you're obviously a zealot with a closed mind so I'm not sure why I'm even bothering to reply.
        Mithaldu_ 13y ago
        Apparently one of the mods decided i shouldn't be able to reply, thus different account. Here's a serious answer for you: You complained about the simple presence of sigils, without even stopping to think and consider what advantages they bring. I may be rude, but close-minded? No.
        TylerE 13y ago
        Explain how requiring a sigil in the default case improves readability. Imagine how ugly C would be if every variable that wasn't a pointer dereference had to be prefixed with $. I am not necessarily opposed to meaningful sigils, e.g. Ruvy's @, but using them everywhere is a pure misfeature that hurts readability.
        meepmeepmeepmee 13y ago
        I'll happily explain, thanks for asking. First off, in Perl the parens for a function call are not mandatory. As such it is very useful for functions and variables to be visually difference, especially when you're using functions to generate parameters for other functions without any temp variables inbetween. my W = qq_mult ConjugateQ, qv_mult RotationQ, Vector; You can't tell at a glance what's going on and will need to look carefully. Adding sigils makes it quite clear: my $W = qq_mult $ConjugateQ, qv_mult $RotationQ, $Vector; Further, most languages have only one type of variable, a name for a single thing. Perl has multiple types of variables that behave differently. For example: my $res = munge $one; I see this and know that the function munge is passed one single variable. However, consider this: my $res = munge @two; If there wasn't the @ there, it would be easy to assume that munge gets exactly one argument. However the @ there alerts us to the fact that @two is an auto-flattening array, and munge will end up with anywhere between 0 and MAX_INT arguments passed to it. Similarly with hashes: my $res = munge @two; They also auto-flatten, so they need to be marked as being different from scalars, but they also flatten in a very different way from array, in that they flatten into a list that alternates the keys and values. So they need to be marked differently from arrays. Lastly, due to functions, variables, array and hashes having explicit sigils, they can be recognized by editors without any heavy analysis, enabling editors to mark these four types with different colors, which is extremely useful. Personally i don't see the sigils anymore, and instead just see the colors with which the types are highlighted. (Bonus set: Actually C is often written with sigils too. I've often seen code where variables are prefixes with p_, s_, a_, i_, etc. They are not enforced by the language, but people often force themselves to use them. The downside: They are inconsistent from project to project and have to be relearned every time.)
  - deleted 13y ago
    [deleted]