Comment by berntb | Hacker News Reader

Comment by berntb | Hacker News Reader

Parent Full thread

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...?

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?

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.

Reply on news.ycombinator.com