Live data from Hacker News

Perl - the Detroit of scripting languages

speakerdeck.com

81–90 of 100 posts

Re: Perl - the Detroit of scripting languages

#81
post #76

Earlier quoted context omitted.

Yeah, sorry man, at the point where you complain about sigils you've disqualified yourself from the discussion for lack of thinking things through far enough. Thanks for playing, bub.

Why, "bub", most sane languages don't have such cryptic, hard to read incantations. But you're obviously a zealot with a closed mind so I'm not sure why I'm even bothering to reply.

Apparently one of the mods decided i shouldn't be able to reply, thus different account. Here's a serious answer for you:

You complained about the simple presence of sigils, without even stopping to think and consider what advantages they bring. I may be rude, but close-minded? No.

Re: Perl - the Detroit of scripting languages

#82
post #79

Earlier quoted context omitted.

> comparable Not comparable. Better. > your LINQ DBIx::Class. I don't want to go to the effort of going into massive detail here, but in short: It allows you to write SQL access code under which you can use ANY database (SQLite, MySQL, MSSQL, Postgres, what have you), without changing a single line of your code. It will not only deploy your schema onto the database server, but also optimize your queries, so that for…

That's one tiny slice of what LINQ can do. It can also query native objects, XML, CSV files, and a wide variety of web APIs.

DBIx can do these things too. Anything you can write a DBI driver for, it can handle.

Re: Perl - the Detroit of scripting languages

#83
post #68

Earlier quoted context omitted.

>>I do think that providing multiple options where most languages have one option built-in is unnecessary cognitive load. (I'll assume you're not a troll despite acknowledging that you talk about a subject you don't know.) You are seriously arguing against flexibility and configurability of your programming environment? I guess you don't like Lisp either? To answer your specific point, re OO system: Today the de-fact…

I'm arguing that flexibility has a cost, and unless you can show me a tangible benefit, it's unnecessary cost. That you can build an OO system comparable to what other languages have built-in is a compelling demonstration of the extent of the flexibility, but it isn't a compelling demonstration of the need for the flexibility. Surely you have better examples of the extensibility of the language than stealing well-und…

>>That you can build an OO system comparable to what other languages have built-in

My explicit point was that it is better [edit: which was an answer to your question about value from flexibility, compared to the cognitive cost], don't do straw man attacks please. (Are you trolling?)

Edit: Thanks for the downvote. :-)

Edit 2: As answer to the next long, long comment with parts going all over: Of course complexity has costs. if you really just want a good reference on Moose to see exactly what it is, ask Mithaldu. He probably has better sources than me. This is what I give people (it is getting old): http://rjbs.manxome.org/talks/moose/Moose.pdf

Edit 3: And to avoid being called a "troll" -- don't write shit like "In 2013 nearly every problem has a language more appropriate than Perl." while you acknowledge you don't know the subject...

Re: Perl - the Detroit of scripting languages

#84
post #76

Earlier quoted context omitted.

Why, "bub", most sane languages don't have such cryptic, hard to read incantations. But you're obviously a zealot with a closed mind so I'm not sure why I'm even bothering to reply.

Apparently one of the mods decided i shouldn't be able to reply, thus different account. Here's a serious answer for you: You complained about the simple presence of sigils, without even stopping to think and consider what advantages they bring. I may be rude, but close-minded? No.

Explain how requiring a sigil in the default case improves readability.

Imagine how ugly C would be if every variable that wasn't a pointer dereference had to be prefixed with $.

I am not necessarily opposed to meaningful sigils, e.g. Ruvy's @, but using them everywhere is a pure misfeature that hurts readability.

Re: Perl - the Detroit of scripting languages

#85
Perl is actually far from abandoned and I would venture to guess (based on no facts and figures but my own personal experience) that there are more lines of Perl in production today than Python or Ruby combined.

But how can that be?! Building a large scale application with Perl would be like building a F111A Aardvark out of duct tape! Quite simply, because Perl is the perfect duct tape. Too many people (knowingly or not) think of Perl as a crappy version of Python when it's actually shell scripting on steroids.

You see, way up here, where projects are constantly in development, paradigms are constantly shifting, and people are building new and exciting things, Perl is an unwelcome high school acquaintance who shows up at the party and makes everybody feel awkward and bad. But way down there, where people are just trying to keep Sputnik up and running until the Soviet Union collapses, Perl is a rock star! If it's too "small" for Java but too "large" for .ksh -- guess what, use Perl.

In my opinion, if you want a scripting language with function signatures, little to no support for UNIX commands, real object orientation (Moose), yadda yadda yadda... just use Python. No one's going to blame you. Larry Wall's not gonna feel bad. You have a right to your impact gun and bolts.

Just leave my duct tape alone.

Re: Perl - the Detroit of scripting languages

#86
post #76

Earlier quoted context omitted.

Yeah, sorry man, at the point where you complain about sigils you've disqualified yourself from the discussion for lack of thinking things through far enough. Thanks for playing, bub.

Why, "bub", most sane languages don't have such cryptic, hard to read incantations. But you're obviously a zealot with a closed mind so I'm not sure why I'm even bothering to reply.

Using words like "sane" and "cryptic" and "incantations" doesn't really seem to fit an argument in good faith, but assuming you're sincere, I can explain.

Perl uses sigils for two reasons. First, to provide a separate namespace for variables and language keywords. Second, to allow amount contexts.

Reasonable people will disagree about the value of both of those reasons, but those are the reasons why sigils exist in Perl.

Re: Perl - the Detroit of scripting languages

#87
post #83

Earlier quoted context omitted.

I'm arguing that flexibility has a cost, and unless you can show me a tangible benefit, it's unnecessary cost. That you can build an OO system comparable to what other languages have built-in is a compelling demonstration of the extent of the flexibility, but it isn't a compelling demonstration of the need for the flexibility. Surely you have better examples of the extensibility of the language than stealing well-und…

>>That you can build an OO system comparable to what other languages have built-in My explicit point was that it is better [edit: which was an answer to your question about value from flexibility, compared to the cognitive cost], don't do straw man attacks please. ( Are you trolling?) Edit: Thanks for the downvote. :-) Edit 2: As answer to the next long, long comment with parts going all over: Of course complexity ha…

When someone says two systems are comparable, it is a different claim than that two systems are equivalent. In order for something to be better than something else they have to be comparable. Dynamic typing can be better than static typing only because they're both approaches to typing (please don't confuse this example with an opinion); static typing cannot be better than lexical scope because they're not comparable.

We're talking about the cost/benefit of flexibility as evidenced by systems like Moose. It's quite irrelevant to my point whether Moose is better or not, so it is quite a stretch to accuse me of a straw man attack. For that to be the case, I'd have to have said that Moose is worse than (say) Python's OO therefore flexibility is bad and Perl is bad by extension. What I'm actually saying is that flexibility isn't free, it has a cost, and that the cost must be offset by other benefits. If Moose is better, that's a benefit that might outweigh the cost, but nobody seems to be interested in telling me how it's better when they could instead attack the argument, by, for instance, hauling out the well-worn stack of logical fallacy accusations. If I sound irritable, it's only because I start conversations on HN in good faith expecting, you know, a conversation, and these kinds of vitriol-powered slamfests are not what I have in mind. Am I a troll indeed.

Edit: One need not know a language to find oneself in a niche where that language might be more appropriate. I didn't mean that remark to offend and I regret my wording. I certainly wasn't out to troll. That said, surely you do not believe one must learn a language inside out before knowing whether it is appropriate to a domain. I know many languages and work in several domains and never find myself thinking Perl would be better. I might not be in the right domains, but if we were having this conversation about C++, Java or Haskell it would be easier to rattle off a few example domains rather than scoff at the question.

Re: Perl - the Detroit of scripting languages

#88
post #84

Earlier quoted context omitted.

Apparently one of the mods decided i shouldn't be able to reply, thus different account. Here's a serious answer for you: You complained about the simple presence of sigils, without even stopping to think and consider what advantages they bring. I may be rude, but close-minded? No.

Explain how requiring a sigil in the default case improves readability. Imagine how ugly C would be if every variable that wasn't a pointer dereference had to be prefixed with $. I am not necessarily opposed to meaningful sigils, e.g. Ruvy's @, but using them everywhere is a pure misfeature that hurts readability.

I'll happily explain, thanks for asking.

First off, in Perl the parens for a function call are not mandatory.

As such it is very useful for functions and variables to be visually difference, especially when you're using functions to generate parameters for other functions without any temp variables inbetween.

my W = qq_mult ConjugateQ, qv_mult RotationQ, Vector;

You can't tell at a glance what's going on and will need to look carefully. Adding sigils makes it quite clear:

my $W = qq_mult $ConjugateQ, qv_mult $RotationQ, $Vector;

Further, most languages have only one type of variable, a name for a single thing. Perl has multiple types of variables that behave differently. For example:

my $res = munge $one;

I see this and know that the function munge is passed one single variable. However, consider this:

my $res = munge @two;

If there wasn't the @ there, it would be easy to assume that munge gets exactly one argument. However the @ there alerts us to the fact that @two is an auto-flattening array, and munge will end up with anywhere between 0 and MAX_INT arguments passed to it.

Similarly with hashes:

my $res = munge @two;

They also auto-flatten, so they need to be marked as being different from scalars, but they also flatten in a very different way from array, in that they flatten into a list that alternates the keys and values. So they need to be marked differently from arrays.

Lastly, due to functions, variables, array and hashes having explicit sigils, they can be recognized by editors without any heavy analysis, enabling editors to mark these four types with different colors, which is extremely useful. Personally i don't see the sigils anymore, and instead just see the colors with which the types are highlighted.

(Bonus set: Actually C is often written with sigils too. I've often seen code where variables are prefixes with p_, s_, a_, i_, etc. They are not enforced by the language, but people often force themselves to use them. The downside: They are inconsistent from project to project and have to be relearned every time.)

Re: Perl - the Detroit of scripting languages

#89
post #32

Earlier quoted context omitted.

> That's a cheap place to bootstrap a business for sure. Depends on what you're willing to give up. Emergency response time can be pretty important.

Especially in a city that is consistently in the top-5 most violent cities in the U.S. (disclaimer: I live in Flint, MI, another of those top-5 cities)

> (disclaimer: I live in Flint, MI, another of those top-5 cities)

Me too! Most violent city, 3 years running!

Re: Perl - the Detroit of scripting languages

#90
post #84

Earlier quoted context omitted.

Explain how requiring a sigil in the default case improves readability. Imagine how ugly C would be if every variable that wasn't a pointer dereference had to be prefixed with $. I am not necessarily opposed to meaningful sigils, e.g. Ruvy's @, but using them everywhere is a pure misfeature that hurts readability.

I'll happily explain, thanks for asking. First off, in Perl the parens for a function call are not mandatory. As such it is very useful for functions and variables to be visually difference, especially when you're using functions to generate parameters for other functions without any temp variables inbetween. my W = qq_mult ConjugateQ, qv_mult RotationQ, Vector; You can't tell at a glance what's going on and will nee…

> You can't tell at a glance what's going on and will need to > look carefully. Adding sigils makes it quite clear: > my $W = qq_mult $ConjugateQ, qv_mult $RotationQ, $Vector;

Actually, that's clear as mud. Is this a function call of 3 arguments? Function composition/chaining, an array of 3 items?

Post reply on HN