4 ms·

you have no clue about even the small built in library in Perl. I've written production perl code; no doubt with less skill than many posting here, but my comm

you have no clue about even the small built in library in Perl. I've written production perl code; no doubt with less skill than many posting here, but my comments are based on experience with the language. Moreover, I've avoided making personal attacks on anyone. That's something you might like to try. If you can. Perl is executable directly when loading in a pre-phase So, perl's design makes it impossible to process perl code from other languages or even with perl sans execution. OK, that's a problem...and what benefits do we get from that decision? Do we get lightning fast performance specifically from that design decision? No. Do we get more expressivity? I don't see any extra expressivity that stems from that decision; I mean, Common Lisp's load-time/compile-time eval-when constructs seem more powerful than perl's counterparts but it doesn't have this problem. I have no problem with language designers making decision decisions that I don't really care for. But some decisions that involve extra complexity for no benefit are just...wrong. I don't like C++'s template system, but I can see what problems it is intended to solve and I can see some benefits from it. What benefits accrue from making perl impossible to parse without execution? yeah references suck But that's not the problem! Lots of language features suck...the question is why does perl have references that are so hard to understand? Is there any reason besides 'Larry Wall didn't know anything about programming language design when he wrote perl and eternal backwards compatability mean we can never change this'? can you discuss list comprehension as an extra kludge people have to learn just because Python lacks multi-instruction lambdas? Err, I don't think you understand the issue here. The problem with python lambdas is that they can only contain expressions and not statements, so you can say lambda x: x+1 but you can't incorporate a try/finally statement into a lambda. That's a language wart, no question. But that has nothing to do with list comprehensions. Comprehensions limit you to expressions and not statements just like lambdas. With respect, I don't think you know what you're talking about here. I'm happy to discuss language design warts, including Python's, but I'd prefer to do so with people who, you know, know something about the subject.

berntb 13y ago
1. You really have no theories you want to share, about why we see this kind of trolls from Python people continuously? >>Moreover, I've avoided making personal attacks on anyone. I argued you wrote extreme flames about subjects you showed you didn't understand -- then claim to understand them. I call yet-another-Python-troll. >>I don't think you understand the issue here. You missed(?) my point: With real inline lambdas and map, you don't need to create/teach list comprehensions Python style. It is there from inflexibility ("no braces!") So, everything has warts(/tradeoffs), you flame about some that you obviously don't understand: >> what benefits do we get from that decision? You really see no possible benefit -- except in Common Lisp? -- from being able to modify the execution environment in code before running a program? 2. I gave the example -- to help with language extensions. No need for that in any environment...?
- MichaelSalib 13y ago
  You really have no theories you want to share Ah, I see you're still struggling with the 'no personal attacks' suggestion. It is OK; I understand that this may be beyond your capabilities. With real inline lambdas and map, you don't need to create/teach list comprehensions Python style. map allows you to iterate over nested loops? I don't think so. I don't think list/set/dict comprehensions impose a major cognitive load on programmers, but perhaps you find them difficult? Well, you really see no possible benefit -- except for in Common Lisp? -- from being able to modify the execution environment in code before running a program? You misunderstand. Common Lisp offers more expressivity when it comes to changing the load-time/compile-time environment than perl does. But CL is easily parseable by external tools. This isn't a hard problem to solve. CL did it over 3 decades ago. like making syntax extensions easier But that doesn't make any sense: you can have syntax extensions in your language without impeding external parsing; that's...really easy. So that can't be the answer. Then again, I'm not sure I've ever seen a real need to arbitrary syntax redefinition...does anyone actually use that feature?
  - berntb 13y ago
    You really show your troll nature when you complain about "personal attacks" (being called troll) while doing two personal attacks yourself: >>Ah, I see you're still struggling with the 'no personal attacks' suggestion. It is OK; I understand that this may be beyond your capabilities. >>I don't think [...] impose a major cognitive load on programmers, but perhaps you find them difficult? Thanks for a good laugh, troll. >>Common Lisp offers more expressivity You are arguing that the specific Common Lisp way is a better implementation of different execution phases. Not relevant, as you know. I argued that the Perl way had advantages, not that it was better than everything else (see chromatic in gp level too). This contradicts your original position that the compilation phases were just crazy and uniquely bad. So this is another point where you are shown to be trolling. Since you made two personal attacks, let me note that... ah, no. I should just pity you irritating trolls. I think I'll stop feeding you now. Please stop trolling on HN.
chromatic 13y ago
So, perl's design makes it impossible to process perl code from other languages or even with perl sans execution. No, it doesn't. Anyone who told you so was fibbing. Perl's design allows you to add your own keywords to the language in such a way that the parser knows their arity and any contextual coercions--in other words, as if they were operators defined in the parser itself. This is rare (it doesn't happen often) and it's almost never ambiguous, but because the language used to define these custom keywords is Turing complete, it's possible to create pathological cases which depend on random factors to define a keyword in one of multiple ways... ... but no one ever does that except to prove that it's possible.

berntb 13y ago

1. You really have no theories you want to share, about why we see this kind of trolls from Python people continuously? >>Moreover, I've avoided making personal attacks on anyone. I argued you wrote extreme flames about subjects you showed you didn't understand -- then claim to understand them. I call yet-another-Python-troll. >>I don't think you understand the issue here. You missed(?) my point: With real inline lambdas and map, you don't need to create/teach list comprehensions Python style. It is there from inflexibility ("no braces!") So, everything has warts(/tradeoffs), you flame about some that you obviously don't understand: >> what benefits do we get from that decision? You really see no possible benefit -- except in Common Lisp? -- from being able to modify the execution environment in code before running a program? 2. I gave the example -- to help with language extensions. No need for that in any environment...?

MichaelSalib 13y ago
You really have no theories you want to share Ah, I see you're still struggling with the 'no personal attacks' suggestion. It is OK; I understand that this may be beyond your capabilities. With real inline lambdas and map, you don't need to create/teach list comprehensions Python style. map allows you to iterate over nested loops? I don't think so. I don't think list/set/dict comprehensions impose a major cognitive load on programmers, but perhaps you find them difficult? Well, you really see no possible benefit -- except for in Common Lisp? -- from being able to modify the execution environment in code before running a program? You misunderstand. Common Lisp offers more expressivity when it comes to changing the load-time/compile-time environment than perl does. But CL is easily parseable by external tools. This isn't a hard problem to solve. CL did it over 3 decades ago. like making syntax extensions easier But that doesn't make any sense: you can have syntax extensions in your language without impeding external parsing; that's...really easy. So that can't be the answer. Then again, I'm not sure I've ever seen a real need to arbitrary syntax redefinition...does anyone actually use that feature?
- berntb 13y ago
  You really show your troll nature when you complain about "personal attacks" (being called troll) while doing two personal attacks yourself: >>Ah, I see you're still struggling with the 'no personal attacks' suggestion. It is OK; I understand that this may be beyond your capabilities. >>I don't think [...] impose a major cognitive load on programmers, but perhaps you find them difficult? Thanks for a good laugh, troll. >>Common Lisp offers more expressivity You are arguing that the specific Common Lisp way is a better implementation of different execution phases. Not relevant, as you know. I argued that the Perl way had advantages, not that it was better than everything else (see chromatic in gp level too). This contradicts your original position that the compilation phases were just crazy and uniquely bad. So this is another point where you are shown to be trolling. Since you made two personal attacks, let me note that... ah, no. I should just pity you irritating trolls. I think I'll stop feeding you now. Please stop trolling on HN.

chromatic 13y ago

So, perl's design makes it impossible to process perl code from other languages or even with perl sans execution. No, it doesn't. Anyone who told you so was fibbing. Perl's design allows you to add your own keywords to the language in such a way that the parser knows their arity and any contextual coercions--in other words, as if they were operators defined in the parser itself. This is rare (it doesn't happen often) and it's almost never ambiguous, but because the language used to define these custom keywords is Turing complete, it's possible to create pathological cases which depend on random factors to define a keyword in one of multiple ways... ... but no one ever does that except to prove that it's possible.