First: you're confusing "missing feature" with "weakness". Some people actually prefer not having 100,000 built-ins. IMHO comparing how you eat an apple with how you eat an orange is stupid. It's not the same fruit, and they work a little differently, and that is okay. If you prefer eating apples because you think the way to eat oranges is stupid, that is okay too.
Second: You don't have to use a module to find the largest element in a list. But you can if you want, and you may find the module does it better than you do. Also, List::Util has been shipped with core perl since 5.8.0, so you don't have to download it.
Third: Perl does have a small core that everyone can learn and use. The fact that you don't understand it or what modules are for does not discredit it.
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.
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).
> 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.
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!)
> 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]
You might want to check chromatic's comment on this subject in this comment tree (he has written, amongst other things, my favorite Perl book and hence has gone over these subjects carefully). He argues the halting problem for the parser is only an academic problem.
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.
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?
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.
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.
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...?
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?
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.
Second: You don't have to use a module to find the largest element in a list. But you can if you want, and you may find the module does it better than you do. Also, List::Util has been shipped with core perl since 5.8.0, so you don't have to download it.
Third: Perl does have a small core that everyone can learn and use. The fact that you don't understand it or what modules are for does not discredit it.