3 ms·

Perl was designed to replace 16 different Unix commands, and in that respect it is successful. Python was created as a scripting language with exceptions, and i

Perl was designed to replace 16 different Unix commands, and in that respect it is successful. Python was created as a scripting language with exceptions, and in that respect it is also successful. I don't think either of these statements is true. This is not a flaw. It is a feature. Arguing about how it should have been done X way is pointless. I disagree. This is not about subjective aesthetics. There are some fruits that are poisonous and are thus objectively bad, totally apart from the question of what fruit you think tastes best. Some of perl's language design features are objectively bad. For example, the way references are implemented makes it absurdly difficult to reason about simple things like nested sequences. If that complexity was needed to get some positive benefit like outstanding performance, then maybe it would be justified. But there are no significant benefits. They are the way they are because Larry Wall didn't understand anything about programming languages when he made perl. As for parsing, it is impossible to parse Perl, as it is Turing-complete and nobody has solved the halting problem (yet). With respect, every language I'm familiar with can be easily parsed except for perl. This has nothing to do with Turing Completeness or the Halting Problem. This has to do with having a sufficiently well designed syntax that tools can easily parse files written in the language without having to implement the whole damn language. That's an important property to have every language besides perl nails it because it is easy to do, but perl doesn't because Larry Wall didn't know anything about programming language design when he started.

berntb 13y ago
As you showed (see chromatic's answer) in your first comment, you have no clue about even the small built in library in Perl. Yet you have lots and lots of really flaming opinions about something you obviously haven't used enough to understand the tradeoffs -- everything has good and bad sides. So, a counter question at your level: Why do we get so many stinking language war trolls out of your Python environment? Something must be seriously sick when an open source environment generates that type of sick behavior in its members? Now, I don't care about your personal problems -- but you trolls lower the HN quality. You all write the same flames about things you don't want to know. Just don't use it. (Afaik, Perl is executable directly when loading in a pre-phase -- which might change the execution environment for other code when it is compiled. this is another tradeoff, where Perl is squarely on the side of expressibility. A feature with plus and minus effects (like making syntax extensions easier) -- except for stinking language war trolls, where everything except their model is bad...) Edit: As I noted in another place -- yeah references suck. Now, can you discuss list comprehension as an extra kludge people have to learn just because Python lacks multi-instruction lambdas?
- MichaelSalib 13y ago
  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...?

berntb 13y ago

As you showed (see chromatic's answer) in your first comment, you have no clue about even the small built in library in Perl. Yet you have lots and lots of really flaming opinions about something you obviously haven't used enough to understand the tradeoffs -- everything has good and bad sides. So, a counter question at your level: Why do we get so many stinking language war trolls out of your Python environment? Something must be seriously sick when an open source environment generates that type of sick behavior in its members? Now, I don't care about your personal problems -- but you trolls lower the HN quality. You all write the same flames about things you don't want to know. Just don't use it. (Afaik, Perl is executable directly when loading in a pre-phase -- which might change the execution environment for other code when it is compiled. this is another tradeoff, where Perl is squarely on the side of expressibility. A feature with plus and minus effects (like making syntax extensions easier) -- except for stinking language war trolls, where everything except their model is bad...) Edit: As I noted in another place -- yeah references suck. Now, can you discuss list comprehension as an extra kludge people have to learn just because Python lacks multi-instruction lambdas?

MichaelSalib 13y ago
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...?