3 ms·

I think you misunderstood what "more expressive" meant. It doesn't mean "more concise", though Perl can excel at that too. It means that expressions can be stat

I think you misunderstood what "more expressive" meant. It doesn't mean "more concise", though Perl can excel at that too. It means that expressions can be stated in more meaningful ways. do_the_thing() if $is_ok; warn_the_user() unless $is_ok; The if/unless pair, along with the ability to put conditionals either before or after the statement to execute, is just one example of Perl's ability to be very readable.

chrisseaton 11y ago
If we're honest with ourselves these discussions are never really about anything more than taste and have almost no technical foundation, but with that said I don't think the trailing conditional is more readable. In the rest of Perl the order in the text of an action normally indicates the sequence of the side effects, but here the first thing to be executed is after the first thing in the text.
- DougWebb 11y ago
  Larry Wall is a linguist first, and the design of Perl's syntax reflects that. So I can totally buy taste being more important than technical foundation, in the same way good graphic design is done. These expressions with the conditionals on the end are supposed to reflect English phrasing. English isn't strict about the order of parts of speech; you can mix them around to change the emphasis. These expressions are the same; they're not meant to strictly indicate order of execution, they're meant to express programmer intent, the way one programmer might explain the logic to another programmer.
  - chrisseaton 11y ago
    > These expressions with the conditionals on the end are supposed to reflect English phrasing. But nobody's ever explained why that would be a good thing to do. We say things like 'you can read it out loud and it sounds like English', without ever arguing why this is a good thing. Do most programmers even have English as a first language? I'm not sure aspiring to be like natural languages actually has any merit. I think we should aspire to precision and clarity. Natural languages rarely have those qualities.
    - grayclhn 11y ago
      From DougWebb, explaining why this would be a good thing to do. >> These expressions are the same; they're not meant to strictly indicate order of execution, they're meant to express programmer intent. We can achieve perfect precision and clarity by naming all of our variables x1, x2, x3, x4, etc. But it's better to give descriptive variable names because it helps us and anyone else reading the code understand what it does. This sort of expression is similar.
      - chrisseaton 11y ago
        I can't see any argument in there. 'meant to express programmer intent'? What does that mean? Basing programming languages on mathematical notation or something else would also of course be 'meant to express programmer intent'. Why are natural languages a better foundation for programming languages than, for example, maths notation or calculi? Everyone in the Perl community seems to think they just intuitively know it is, but can't explain why.
        DougWebb 11y ago
        When you're speaking to another programmer, explaining what a bit of your code is trying to do, do you speak in mathematical notation? I doubt it. I don't think even mathematicians do that. If you want a well-expressed explaination for why Perl's approach is a good idea, you should read what Larry Wall has written about it. All I can really say is that it worked really well for me and my team for many years. We rarely misunderstood each other's intent, even though our code reviews were mostly just reading commit diffs.
        grayclhn 11y ago
        Think of it as a commenting or documentation system that's also interpreted by the language. Comments that can never get out of date. If you think that human-readable comments and documentation are not useful... then I'm not going to try to convince you that you would benefit from perl's syntactic flexibility. But surely you recognize that there are some people that like documentation, useful comments, and informative variable names.
- edibleEnergy 11y ago
  While I agree with you that they are not more readable, there are some other notable cases like that in the language, for example: map { row => $_ } $db->get_rows
mattbillenstein 11y ago
This is harder to parse in my mind than: if is_ok: do_the_thing() else: warn_the_user() In that you can see more or less visually what the intent is rather than having to mentally parse the text. But perhaps that's just personal taste. IMHO, expressiveness and conciseness are largely the same idea because when you talk about the former, you mean being able to bang out an idea in fewer lines of code yielding the latter. Having a complex grammar and a myriad of ways to do the same thing seems very neat, but in the end the productivity gained in the writing, you waste several times in the reading, so it ends up being a net loss. But Perl lost the dynamic language wars a long time ago -- I think perhaps some of the flavor got picked up in Ruby? And having a language read like English is IMO, a bad idea -- English is very ambiguous in many cases -- mimicking this in your programming language would be a bad idea indeed.

chrisseaton 11y ago

If we're honest with ourselves these discussions are never really about anything more than taste and have almost no technical foundation, but with that said I don't think the trailing conditional is more readable. In the rest of Perl the order in the text of an action normally indicates the sequence of the side effects, but here the first thing to be executed is after the first thing in the text.

DougWebb 11y ago
Larry Wall is a linguist first, and the design of Perl's syntax reflects that. So I can totally buy taste being more important than technical foundation, in the same way good graphic design is done. These expressions with the conditionals on the end are supposed to reflect English phrasing. English isn't strict about the order of parts of speech; you can mix them around to change the emphasis. These expressions are the same; they're not meant to strictly indicate order of execution, they're meant to express programmer intent, the way one programmer might explain the logic to another programmer.
- chrisseaton 11y ago
  > These expressions with the conditionals on the end are supposed to reflect English phrasing. But nobody's ever explained why that would be a good thing to do. We say things like 'you can read it out loud and it sounds like English', without ever arguing why this is a good thing. Do most programmers even have English as a first language? I'm not sure aspiring to be like natural languages actually has any merit. I think we should aspire to precision and clarity. Natural languages rarely have those qualities.
  - grayclhn 11y ago
    From DougWebb, explaining why this would be a good thing to do. >> These expressions are the same; they're not meant to strictly indicate order of execution, they're meant to express programmer intent. We can achieve perfect precision and clarity by naming all of our variables x1, x2, x3, x4, etc. But it's better to give descriptive variable names because it helps us and anyone else reading the code understand what it does. This sort of expression is similar.
    - chrisseaton 11y ago
      I can't see any argument in there. 'meant to express programmer intent'? What does that mean? Basing programming languages on mathematical notation or something else would also of course be 'meant to express programmer intent'. Why are natural languages a better foundation for programming languages than, for example, maths notation or calculi? Everyone in the Perl community seems to think they just intuitively know it is, but can't explain why.
      - DougWebb 11y ago
        When you're speaking to another programmer, explaining what a bit of your code is trying to do, do you speak in mathematical notation? I doubt it. I don't think even mathematicians do that. If you want a well-expressed explaination for why Perl's approach is a good idea, you should read what Larry Wall has written about it. All I can really say is that it worked really well for me and my team for many years. We rarely misunderstood each other's intent, even though our code reviews were mostly just reading commit diffs.
      - grayclhn 11y ago
        Think of it as a commenting or documentation system that's also interpreted by the language. Comments that can never get out of date. If you think that human-readable comments and documentation are not useful... then I'm not going to try to convince you that you would benefit from perl's syntactic flexibility. But surely you recognize that there are some people that like documentation, useful comments, and informative variable names.
edibleEnergy 11y ago
While I agree with you that they are not more readable, there are some other notable cases like that in the language, for example: map { row => $_ } $db->get_rows

mattbillenstein 11y ago

This is harder to parse in my mind than: if is_ok: do_the_thing() else: warn_the_user() In that you can see more or less visually what the intent is rather than having to mentally parse the text. But perhaps that's just personal taste. IMHO, expressiveness and conciseness are largely the same idea because when you talk about the former, you mean being able to bang out an idea in fewer lines of code yielding the latter. Having a complex grammar and a myriad of ways to do the same thing seems very neat, but in the end the productivity gained in the writing, you waste several times in the reading, so it ends up being a net loss. But Perl lost the dynamic language wars a long time ago -- I think perhaps some of the flavor got picked up in Ruby? And having a language read like English is IMO, a bad idea -- English is very ambiguous in many cases -- mimicking this in your programming language would be a bad idea indeed.