The Perl Short Questions Megathread: executable line noise

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > The Perl Short Questions Megathread: executable line noise

magimix: Dec 31, 2003; MY FAT WAIFU!!!
She's fetish efficient; Nap Ghost

Ninjew posted:

I have found the camel book to be utterly useless. Its fun to read, but fails in actually being a good handbook for the language. I've found perl's man pages to be infinitely more readable, concise, and useful.

For new perl programmers, the must read man page (besides perlre) is perlref. Without understanding and using references, it is impossible to harness the full flexibility of the language.

Totally agree with both of these. I guess it is just a 'different strokes' thing, because I know lots of people who rave about the 'camel' book, but I don't like the way it is written. To me it is, at best, an okay-ish reference, but I didn't find it useful when I was learning to exploit the language. And the need to understand references is vital - it is, at the very least, key to building complex data structures in Perl.

For an OO bent, I'd recommend 'Object Oriented Perl' by Damian Conway.

Also, as I don't think I saw it in the OP; Perldoc.

While I would never claim that Perl is the be-all and end-all of languages, or that it is without fault, of the languages I've used in anger it is the one I've enjoyed using the most.
Edit: Actually, this opinion will be somewhat biased by the fact that I programme Perl for a living.

magimix fucked around with this message at 09:57 on Oct 25, 2007

# ¿ Oct 25, 2007 09:52

Adbot: ADBOT LOVES YOU

# ¿ Apr 30, 2024 03:35

magimix: Dec 31, 2003; MY FAT WAIFU!!!
She's fetish efficient; Nap Ghost

Kidane posted:

Essentially, I'm trying to match one array against another. Here is what I've got:
code:
foreach(@php_available_modules) {
    @already_installed = grep $_, @php_installed_modules;
    @available_to_install = grep(/[^$_/], @php_installed_modules);
}

I found your description of the problem a bit confusing to be honest. So, assuming I haven't entirely misunderstood you, might the following do what you want?

code:

my @installed;
my @available;
my %installed = map {$_ => 1} @php_installed_modules;
foreach my $module (@php_available_modules)
{
	exists $installed{$module} ? 
		push @installed, $module :
		push @available, $module;
}

So @installed contains those php_available_modules that are in php_installed_modules, and @available contains those php_available_modules that are not in php_installed_modules.

magimix fucked around with this message at 12:27 on Mar 7, 2008

# ¿ Mar 7, 2008 12:21

magimix: Dec 31, 2003; MY FAT WAIFU!!!
She's fetish efficient; Nap Ghost

Kidane posted:

Yes, that's exactly what I'm trying to do.

I considered using a hash but the sub started swelling up and I'd like to keep this portion of my code to as few lines as possible.

I'd say worry about the functional aspect of your code for now, rather than its line-count. I created a hash of php_installed_modules so that I could iterate through php_available_modules once only, and do a single hash-lookup for each element therein.

Your original code has you iterating though php_installed_modules twice for every element in php_available_modules.

# ¿ Mar 7, 2008 12:26

magimix: Dec 31, 2003; MY FAT WAIFU!!!
She's fetish efficient; Nap Ghost

Kidane posted:

You're right, of course. I've never used map before so I was shying away from it. My original code (before I tried using grep) looked like this
code:
foreach (@php_available_modules) {
    my $avail = $_;
    $installed = 0;
        foreach(@php_installed_modules) {
            if ($avail eq $_) {
                $installed = 1;
            }
        }
        if (not $installed) {
            push(@available_to_install, $avail);
        }
        else {
            push(@already_installed, $avail);
        }
}
Which is very awkward (I've only been doing this for a couple months). Your code worked perfectly so I am going to look in to what map does and add it to my toolbox.

Thanks a lot for your quick response!

I'm still got a nagging doubt that I'm missing something. Anyway, would the following also do what you want?

code:

my %installed = map {$_ => 1} @php_installed_modules;
my @available = grep {!exists $installed{$_}} @php_available_modules;

In my test code, this produces the same @available as my previous code does. This is predicated around the fact that in the previous code @installed always had a one to one correlation with @php_installed_modules, so there was no sense duplicating that data. It also depends on the set of installed modules always being a subset of the available modules.

# ¿ Mar 7, 2008 12:44

magimix: Dec 31, 2003; MY FAT WAIFU!!!
She's fetish efficient; Nap Ghost

Triple Tech posted:

After the first deref, you don't need subsequent derefers.

$a->{lookup}->[lookup] == $a->{lookup}[lookup]

That's just a syntactic nicety. Same with how you usually don't need to include the quotes around a literal hash-key (e.g. $test->{'key'} vs $test->{key}). However, I've always preferred to keep dereferences 'explicit' by using '->'. I like the arrows :3:

Edit: How the gently caress did I not spot I'd been 100%, thoroughly beaten?! Ninja Rope :argh:

# ¿ Jun 10, 2008 08:28

magimix: Dec 31, 2003; MY FAT WAIFU!!!
She's fetish efficient; Nap Ghost

German Joey posted:

syntactic niceties go a long way to keep your code from looking like line noise, especially when you're working with a structure thats more than a few levels deep.

Sounds like we've got a new doctrinal conflict on our hands! I was getting bored of tabs-vs-spaces, braces-on-same-line-vs-on-new-line, and suchlike anyway.

:can:

# ¿ Jun 10, 2008 09:01

magimix: Dec 31, 2003; MY FAT WAIFU!!!
She's fetish efficient; Nap Ghost

I might be flying off in totally the wrong direction, but can MySQL actually handle multiple active statements on a single database handle?

I've always found I couldn't execute a second statement on a DB handle without first fetching or discarding the result-set of the previously executed statement.

# ¿ Jun 19, 2008 15:51

magimix: Dec 31, 2003; MY FAT WAIFU!!!
She's fetish efficient; Nap Ghost

As it was explained to me once, the set of things that are 'false' consists of the empty string, numeric zero, and UNDEF. Conversely, the set of things that are 'true' is everything not in the set 'false'.

# ¿ Dec 19, 2008 19:33

magimix: Dec 31, 2003; MY FAT WAIFU!!!
She's fetish efficient; Nap Ghost

Sartak posted:

Yes. We're discussing which false value Perl chooses in certain situations.

Even in these formal shorts, I feel like a failure

# ¿ Dec 19, 2008 20:44

magimix: Dec 31, 2003; MY FAT WAIFU!!!
She's fetish efficient; Nap Ghost

SA Support Robot posted:

Just curious, what is everyone's opinion here of the Perl6 situation? Anyone have any real expectations to move major applications to it?

I wrote off Perl6 long ago. I believe it was an enormous mistake to basically set Perl adrift to chase down the whole Parrot project. I won't even consider using Perl6 until there are stable packages in enterprise Linux distros, and even then I'll hold off until I see reputable reports of its stability/performance in business-critical production scenarios.

While many interpreted languages were evolving and embraced the rise of web applications, Perl's developers veered off into the weeds. They all but destroyed Perl as a product. It will take a lot to win me over again.

I'm kind of with you on this one. While Perl6 has been slowly (slowly) gestating, everything else has moved forward relentlessly, usually in an iterative, steadily-improving manner.

Much of what we might want from it is now served to us from competing technologies that we've elected to make use of in the meantime. We still actively use Perl5 (and will for the foreseeable future), and develop new systems with it, but we'd absolutely not go to Perl6 (in my opinion, though I'm not the person that'd be making that sort of decision) 'just because'.

Any changes we make to our infrastructure go through as much analysis, review, and testing as developmental changes, and with a massive legacy codebase we'd probably be hard pushed to justify shunting to Perl6 runtime.

And for new-build? Well where Perl in general fits, Perl5 already fits, and for other cases, we already have an established use of alternate technologies (with their own extant codebases, system of support, processes, etc, etc).

# ¿ Aug 2, 2010 18:54

magimix: Dec 31, 2003; MY FAT WAIFU!!!
She's fetish efficient; Nap Ghost

Powered Descent posted:

Waking this thread up for a general newbie question: is there anything a native speaker of C can do to better "get" Perl? Because so far I feel like I'm scrambling to impose order on a chaotic mess.

Back in the day I spent several years as a C++ developer. I've now jumped headfirst into a new job as a Linux admin, and so I'm learning Perl as fast as I can. And by a lot of measures that's going very well -- I can write perfectly functional code that does what I need it to do. But my Perl code looks almost exactly like C, because I still think in C and then translate the syntax as necessary. Other people's code is enigmatic at best -- it's like figuring out a rebus. Anything that's described as "Perlish" seems designed to be as obfuscated and impenetrable as humanly possible.

Clearly I still don't "get" Perl. So much important stuff is left implicit and unstated. (I'm still completely at the very concept of a default variable. Why the hell would you DO that? I can't think of a single reason to ever use $_ in place of a real variable, and the very first thing that happens in my subroutines is to shift the real parameters out of that @_ thing.) All this implicit stuff feels like building a house out of jello.

I'm clearly still missing an essential concept here. Can anyone recommend any likely paths to enlightenment, to that "aha", to that moment of grokking just what the hell Larry Wall was driving at? Any books, tutorials, psychoactive drugs, meditations upon mountaintops?

Personally, I don't think you are missing enlightenment, as such. Like any language, you are using Perl to implement solutions to problems. Nothing about that precludes the writing of well structured, readable, maintainable code. One can exploit the strengths of the language without being intentionally terse or cryptic. That said, Perl being as permissive as it can be, you might sometimes have to wrestle with some real poo poo. With that in mind, try to learn the language fundamentals. Understand its types (especially if you are coming from a strongly-typed background), understand context, and key concepts. Beyond that, if you haven't already done so, bookmark http://perldoc.perl.org/. It'll help you more ably exploit Perl's strengths (that is to say, to 'think' in Perl, rather than mentally transliterate from what you'd do in C++), and also deconstruct much of the pointlessly terse and cryptic Perl that so many people seem to poop out[1].

That said, the various (http://perldoc.perl.org/perlvar.html) predefined variables in Perl do for the most part perform important duties - often their use is definitely necessary, or at the least recommended. But, by virtue of them being all predefined and what-not, they can be, and often are (in my opinion) used in scenarios where said use is not necessary or beneficial. To touch upon a specific perlvar you mention - in a 'foreach' my preference is to use a lexical as opposed to $_. However, when using things like 'map' and 'grep, use of $_ is expected and appropriate.

[1] Its a sore spot for me, I guess. Over the years I've reviewed a poo poo-load of code from a wide variety of people, and I've also had to pick apart and rebuild understanding of large, ancient, hairy legacy Perl systems made by people that left donkeys years ago.

magimix fucked around with this message at 10:28 on Jun 23, 2013

# ¿ Jun 23, 2013 10:20

Adbot: ADBOT LOVES YOU

# ¿ Apr 30, 2024 03:35

magimix: Dec 31, 2003; MY FAT WAIFU!!!
She's fetish efficient; Nap Ghost

qntm posted:

Perl code:
print foreach @array;
...and now you know how it's done, I think you will understand why you shouldn't do it.

There is a book, Perl Best Practices, which you may find illuminating. It explains and justifies which practices are good and which are bad.

Your code is too verbose! :argh:

Perl code:

print @array;

Actually I'm just replying to get behind your mention of Perl Best Practices, and to say something I forgot to in my original post - Powered Descent, know that Larry Wall's "Programming Perl" is a poo poo book. It is a poor language reference, and I regard it as a *terrible* book for anyone trying to learn the language, let alone learn to use it well. 'Well' in this context having 'readability', 'clarity', and 'maintainability' as core requirements. (Also the style of the book rubs me up the wrong way. It's like the technical-book version of an aging hipster. I guess that is the least of its problems though.)

# ¿ Jun 23, 2013 11:25

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > The Perl Short Questions Megathread: executable line noise