3 ms·

Some people actually prefer not having 100,000 built-ins Have you actually ever looked at Python? The core language is pretty small; much smaller than perl cer

Some people actually prefer not having 100,000 built-ins Have you actually ever looked at Python? The core language is pretty small; much smaller than perl certainly. My point is that if you design the core well enough with orthogonal components and capabilities, you can give people the equivalent of many thousands of purpose-built modules. I have no idea what you're trying to say with your fruit analogy. Perl does have a small core that everyone can learn and use. That hasn't been my experience; the core language seems to have a staggering number of rarely used quite odd features that accumulated early on. It seems extremely hard to write a new implementation of perl that supports all that cruft; one can't even parse perl correctly except by using the existing implementation.

peterwwillis 13y ago
Let's not get too wrapped up in language design. 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. Thus my fruit analogy: Python and Perl are different kinds of fruit. They are designed differently and you use them differently. This is not a flaw. It is a feature. Arguing about how it should have been done X way is pointless. As for parsing, it is impossible to parse Perl, as it is Turing-complete and nobody has solved the halting problem (yet).
- MichaelSalib 13y ago
  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.
- dragonwriter 13y ago
  > As for parsing, it is impossible to parse Perl, as it is Turing-complete and nobody has solved the halting problem (yet). Most Turing-complete languages can be parsed (even Ruby, which is, among currently-popular languages that aren't Perl, noted for being parsing-unfriendly.) Perl can't be parsed not just because it is Turing-complete, but because (unlike most other languages), parsing Perl requires simulating its execution and it is Turing-complete, which combined require solving the halting problem to parse perl. Insofar as it is valuable to be able to parse code written in a programming language, perl's unique barrier to parsing is a drawback.
  - peterwwillis 13y ago
    Really the halting problem comes down to "Can we tell if a function will end or not?" A simple while ( time ) { 1 } will stop us from finding that out very nicely, so the fact that it's not parseable is actually a separate issue. (A much simpler halting problem using parsing is do 1;) We could remove the ability for Perl to compile, interpret and execute code at run-time, which would mainly involve removing eval, use, require, import, do, etc. But would that be better or worse than not being able to "parse" Perl code? (As an aside: Ruby is also subject to the halting problem, and thus cannot be parsed; you just can't get away from the pesky thing!)
    - MichaelSalib 13y ago
      With respect, this is incorrect. You can have load-time execution without making parsing impossible. See Common Lisp for an example.
    - dragonwriter 13y ago
      > Really the halting problem comes down to "Can we tell if a function will end or not?" Except that "program" is usually used instead of function, that's the usual statement of the halting problem, not something it "comes down to". > A simple while ( time ) { 1 } will stop us from finding that out very nicely, so the fact that it's not parseable is actually a separate issue. The problem with parsing Perl is that Perl cannot be parsed independently of simulating its execution. That fact, combined with the halting problem, means that it cannot be parsed (or, more accurately, that any program that correctly parses Perl cannot be guaranteed to terminate on all valid inputs.) > As an aside: Ruby is also subject to the halting problem, and thus cannot be parsed All Turing-complete programming languages are subject to the halting problem. But that's not a problem for parsing most of them (including Ruby) the way it is for Perl because parsing most languages does not require simulating the execution of the code being parsed. Ruby can be parsed, though its parser is notoriously ugly. [1] [1] see, e.g., http://programmingisterrible.com/post/42432568185/how-to-parse-ruby http://programmingisterrible.com/post/42432568185/how-to-par...

peterwwillis 13y ago

Let's not get too wrapped up in language design. 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. Thus my fruit analogy: Python and Perl are different kinds of fruit. They are designed differently and you use them differently. This is not a flaw. It is a feature. Arguing about how it should have been done X way is pointless. As for parsing, it is impossible to parse Perl, as it is Turing-complete and nobody has solved the halting problem (yet).

MichaelSalib 13y ago
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.
dragonwriter 13y ago
> As for parsing, it is impossible to parse Perl, as it is Turing-complete and nobody has solved the halting problem (yet). Most Turing-complete languages can be parsed (even Ruby, which is, among currently-popular languages that aren't Perl, noted for being parsing-unfriendly.) Perl can't be parsed not just because it is Turing-complete, but because (unlike most other languages), parsing Perl requires simulating its execution and it is Turing-complete, which combined require solving the halting problem to parse perl. Insofar as it is valuable to be able to parse code written in a programming language, perl's unique barrier to parsing is a drawback.
- peterwwillis 13y ago
  Really the halting problem comes down to "Can we tell if a function will end or not?" A simple while ( time ) { 1 } will stop us from finding that out very nicely, so the fact that it's not parseable is actually a separate issue. (A much simpler halting problem using parsing is do 1;) We could remove the ability for Perl to compile, interpret and execute code at run-time, which would mainly involve removing eval, use, require, import, do, etc. But would that be better or worse than not being able to "parse" Perl code? (As an aside: Ruby is also subject to the halting problem, and thus cannot be parsed; you just can't get away from the pesky thing!)
  - MichaelSalib 13y ago
    With respect, this is incorrect. You can have load-time execution without making parsing impossible. See Common Lisp for an example.
  - dragonwriter 13y ago
    > Really the halting problem comes down to "Can we tell if a function will end or not?" Except that "program" is usually used instead of function, that's the usual statement of the halting problem, not something it "comes down to". > A simple while ( time ) { 1 } will stop us from finding that out very nicely, so the fact that it's not parseable is actually a separate issue. The problem with parsing Perl is that Perl cannot be parsed independently of simulating its execution. That fact, combined with the halting problem, means that it cannot be parsed (or, more accurately, that any program that correctly parses Perl cannot be guaranteed to terminate on all valid inputs.) > As an aside: Ruby is also subject to the halting problem, and thus cannot be parsed All Turing-complete programming languages are subject to the halting problem. But that's not a problem for parsing most of them (including Ruby) the way it is for Perl because parsing most languages does not require simulating the execution of the code being parsed. Ruby can be parsed, though its parser is notoriously ugly. [1] [1] see, e.g., http://programmingisterrible.com/post/42432568185/how-to-parse-ruby http://programmingisterrible.com/post/42432568185/how-to-par...