Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Perl - the Detroit of scripting languages

speakerdeck.com

Post reply on HN
Print view View original

51–60 of 100 posts

Re: Perl - the Detroit of scripting languages

#51

Post by tbrownaw »

pyre wrote: post #27
tbrownaw wrote: post #16

Earlier quoted context omitted.

Well, what does "efficient" actually mean here? I like Perl (for medium-small programs) because it's quick to write, doesn't require lots of boilerplate like Java does, and allows a much more direct translation of my intent than shell scripts do.

Personally, if sounds like you need to expand your horizons if you feel that Perl is mostly competing with Java or shell scripts as the best language for the job.

How so?

Shell scripts are for things that have almost no logic besides running other programs.

Perl is for things that do have internal logic, and aren't big enough for the lack of formal function parameters to be an issue.

Java is for things that talk to the database (or need other libraries, such as for reading/writing Excel files), or are too large to keep in my head all at once (most of which talk to the database anyway).

C is for the one program I have that needs the suid flag set, and the one wrapper that resets the process group ID. I don't like C.

The server that all these need to run on, is an AIX box that doesn't have Python or OCaml or Ruby installed. If it did, I suppose it's possible I'd use one of these for some of the cases where I use Perl or Java now. Or probably not, since less people know them (except maybe Python?).

PL/SQL is for things that run inside the database, because it's what the database (Oracle) comes with.

C#/.NET is for things that run on my and my coworkers' laptops, because Visual Studio provides a wrapper/installer that makes it dead simple to publish updates.

Re: Perl - the Detroit of scripting languages

#52

Post by antitrust »

A few thoughts:

Trends come and go, but it's the general purpose languages that remain.

Perl seems to fit in that space that was occupied by the various BASICs in the 1980s, meaning that it was the best glue for everyday tasks. It's quick to write, has the right tools, and plays well with system tools.

In general, in my experience, it's the quality of staff and not the tools that makes the difference. Good management, coders and business-side analysts make a much bigger difference than what language you use.

In general, in my experience, few experienced Perl programmers use vanilla Perl. Almost all of them rely heavily on libraries and write code according to their own knowledge of what's most efficient.

Be wary of the world of trends in programming. It is as fickle as trends in education, interior design or nutrition. Then again, I'm still waiting for the Pascal comeback.

Re: Perl - the Detroit of scripting languages

#53

Post by chromatic »

SeanDav wrote: post #49
guylhem wrote: post #2

In perl5 : - I can have a prototype running in a matter of minutes - I have access to a vast library of modules doing everything I need (which helps the former) - I write quick and efficient code Do I really care about what other people think about the languages and tools I use? No. However, I do care about efficiency and results And, uh, working with a language that has been out for tens of years makes me believe my…

In 10 years you could say exactly the same thing, except that: - Perl 6 will STILL be in development - You just lost 10 years of development experience and related marketability because now all those fad-du-jour systems are established industry leaders - Nothing would have have changed back in Perl 5 land because everyone can only develop in 5.8.x or 5.10.x in case they break something. The upside of course is that t…

Nothing would have have changed back in Perl 5 land because everyone can only develop in 5.8.x or 5.10.x in case they break something.

Seems doubtful to me. With yearly releases and a two year support cycle, only the enterprisey distribution nonsense is still infected with that particular brokenness.

Re: Perl - the Detroit of scripting languages

#54

Post by veesahni »

Mithaldu wrote: post #28
veesahni wrote: post #24

Earlier quoted context omitted.

> The difference is that OO syntax sugar is implemented in core in Python and Ruby, while in Perl it is implemented in Perl directly I see what you mean. However, that syntax sugar is what people are used to from other OO implementations. Lacking that sugar meant that I found myself regularly explaining the workings of blessed hashes.

Yes, that is true. I only meant to correct your use of fake. In the past OO was a holy pain in the behind in Perl. However, nowadays that has changed considerably, and with Moo [1] we have a reliable, pure perl, fast, and easy-to-use sugar layer for OO. :) [1] https://metacpan.org/module/Moo#SYNOPSIS

I'll check out Moo :)

Re: Perl - the Detroit of scripting languages

#55

Post by jack-r-abbit »

Mithaldu wrote: post #14

Before you comment, please keep the following things in mind: The talk was held by Stevan Little, the creator of Moose, the person who experimented in Moe on a modern Perl 5, and the person who is currently working on a Meta-Object-Protocol that can be put in the Perl core to make good OO available out of the box, on which Moose, Moo and friends can built. He dearly loves Perl and has done a lot for it. This talk is…

I won't comment then because the tiny tiny print was so painfully horrible to read I only made a few slides in. He seemed to be making a point though. Just the presentation was horrible.

Re: Perl - the Detroit of scripting languages

#58

Post by VLM »

Mithaldu wrote: post #43
dj-wonk wrote: post #23

To add two different thoughts: * Perl is widely used and has inspired many other languages. These are not small accomplishments. * How many major revision bumps can a language undergo before it loses its identity? How many breaking changes are allowed before it becomes something else? Perhaps the name is about something more than the language as crystallized at any one point in time? But how do you convey that to the…

To the last point: I'm fairly sure that the identity of a language is defined by its teaching materials. Up until 2012 all Perl teaching materials were largely based on text written in the early 90s. And as well, any newbie program tended to look like it was almost Perl 4. This was in spite of there being a concensus and strong effort to push among the active Perl community that modern Perl was the way forward. Then…

"Modern Perl by chromatic"

I have a copy on my desk and this cannot be emphasized enough that one inward facing book on what boils down to style and good taste, has already had more impact on the language than the last two decades of outward facing comparisons.

Insert forest and trees analogies in that we've got way too many presentations over the decades about how one individual tree needs trimming or fertilizing or bonsai treatment as compared to how our neighbors orchard does the same, but not enough real forestry management presentations.

Re: Perl - the Detroit of scripting languages

#59

Post by TylerE »

mhurron wrote: post #50
mkohlmyr wrote: post #29

Earlier quoted context omitted.

Well that's great... For your very narrow use case.. It is not however an effective rebuttal to the points brought up in a more general case.

Wait, you think opening and reading files of various sizes is a narrow case for a language named Practical Extraction and Report Language?

In the case of arguing for general relevance, yes.

It's like saying: Hey, all I do is bang in nails! The hammer is only tool anyone ever needs!

Re: Perl - the Detroit of scripting languages

#60

Post by TylerE »

Mithaldu wrote: post #45
jingo wrote: post #42

Earlier quoted context omitted.

"So far I have not found..." What else have you tried?

I think it's important to note that there is an implication in his question of the code of the alternative being as easy to read and write as Perl. One could of course write a much faster text processing tool in Assembler, but well ...

> easy to read as Perl.

So, that rules out Brainf--k I guess

Post reply on HN