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

«‹›72 »

Stabby McDamage: Dec 11, 2005; Doctor Rope

I'm a big fan of Perl, using it at home, at work, and sometimes in the bathroom, so I thought I'd christen the Cavern with a Perl thread before those whitespace-delimited python bastards get here.

Perl is a compact, occasionally cryptic scripting language born of the brain of Larry Wall (see fig. 1).

Fig 1: Larry Wall. If you find something weird about Perl, this is the cause.

To sum up the language, Perl is a higher level language than C and Java, and is in the same camp as Python and Ruby. It's great for small to medium-size programs, especially for data munging, database access, job control, etc. It's a mix of C, shell script, sed/awk, and even a bit of LISP. Despite being higher level, it doesn't lose it's UNIX roots, so if you like forks and pipes but not pointers, Perl is for you.

Features
- Automatic data typing and memory management.
- Flexible arrays that grow and shrink as needed.
- Hashes, which allow arbitrary key-value pairs (AKA "associative arrays" in PHP or "dictionaries" in Python).
- Hashes and arrays can contain references to other hashes or arrays, making complex data structures easy to implement. (I once wrote an web-based game that stored the entire state of the universe in a single hash).
- Core functions include sorting, list grepping, mapping functions onto lists, and other labor-savers.
- Many low-level C system calls are included, so you can fork(), alarm(), umask(), setpgrp(), ioctl(), etc. You can even set interrupt handlers!
- Subroutines can be passed as variables ("higher-order programming").
- Regular expressions are built into the syntax of the language.
- Object oriented programming is supported through packages.
- A super-gigantic ton of existing libraries can be instantly installed via the Comprehensive Perl Archive Network (CPAN).

Getting Perl
- If you're on Linux or OSX, you have it.
- If you're on Windows, get ActiveState Perl or the Cygwin suite, which includes Perl.

For new users
If you want to go the book route, I'd pick up Learning Perl, then Programming Perl, then study the Perl Cookbook (all linked below). But that's me. You could also go through some of these tutorials and documents:
- Picking Up Perl is a free online book that introduces Perl.
- About.com's Perl section has several tutorials.
- Perl Lessons is a brief introductory course.

Web resources and references
- Perldoc, the web-based version of the perldoc manpages.
- The single-page built-in function reference "perlfunc" is quite handy.
- All the extra modules live on the Comprehensive Perl Archive Network (CPAN), and can be installed with the "cpan" command-line tool.
- The Perl Monks like helping folks learn Perl, and have a huge blog of examples and help.
- Perl Regular Expression Quick Reference - Print out and stick on wall.
- A ton of Perl examples, projects, and documentation can be found at Perl.com and About.com's Perl section.
- Perl Design Patterns. A wiki applying the principles of design patterns (common code configurations to solve a certain kind of problem) to Perl. The problem index is useful.

Books
- Learning Perl, 3rd ed. The O'Reilly book for learning the language. Google Books.
- Programming Perl, 3rd ed. Called the "camel book", this is the definitive reference, also from O'Reilly. Google Books.
- The Perl Cookbook, from O'Reilly, is a collection of techniques and examples ranging from the simple to the complex. It's the only printed reference book I frequently use. Google Books.
- Perl Best Practices. Style and design tips to make your code maintainable and good. If you use this from the start, then you won't have to resort to...
- Perl Medic. It's about keeping up legacy ("poo poo") code, and transforming it into something that doesn't give you the tetanus. Glowing reviews at TechBookReport.

Stabby McDamage fucked around with this message at 15:19 on Oct 26, 2007

# ? Oct 24, 2007 21:30

Adbot: ADBOT LOVES YOU

# ? Apr 18, 2024 11:41

syphon^2: Sep 22, 2004

I would like to kick things off with a Perl question. (this is almost E/N)

I'm a beginner when it comes to programming. I work for my company's Build Team, which I've heard best described as "Half IT, half developer". Most of our stuff is written in Perl, so I picked up O'Reilly's Learning Perl and read through it. I've also grabbed Intermediate Perl, and am about halfway through that.

For the last year or so, I've been doing a lot of development in Perl. I've dabbled in other languages, but this is really my first. I've written several scripts for use in a command prompt (my company is solely win32), and have recently started creating basic CGI web-apps.

Basically, my question is, where do I go from here? I can continue learning Perl (I've only brief glimpses into Object-Oriented Perl), or I can focus on learning to create bigger and better web-apps with Perl, or I can move on to a different language altogether. I don't think I'll ever be a full-time developer, but obviously I enjoy coding in Perl and want to learn more, even if that means going to Python or Ruby.

Lots of people are kinda pressuring me into learning Ruby, but I'm hesitant to try to "start over" and learn a whole new language. Part of the reason I'm happy with where I am with Perl is that I'm at a stage where I can produce actual deliverables, while still having plenty of room to learn more.

So, Perl gurus, where do I go next?

# ? Oct 24, 2007 22:13

tef: May 30, 2004; -> some l-system crap ->

syphon^2 posted:

Basically, my question is, where do I go from here? ... I enjoy coding in Perl and want to learn more, even if that means going to Python or Ruby.

Learning other languages is a good idea, but you might want to get more confident in perl first. You will programming idioms you can bring to other languages, and ruby or python won't seem so much of a big step.

If you understand the web model, have you considered branching out somewhat? A simple web server would cover using file and network i/o, as well as simple parsing for http/1.0. It's up to you how far you go with using libraries, as you could avoid writing a lot of code, and get a working project quicker.

It will also allow you to gain a deeper understanding of the tools you use every day.

# ? Oct 24, 2007 23:01

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

Ahh, welcome home, brothers.

Just wanna throw it out there that I love Perl and work at a Perl shop in NYC, so if anyone needs job, holla back.

syphon^2, two awesome concepts that are not-exclusive to Perl but good launching points from where you are are functional programming and object-oriented programming.

The first part to functional programming is understanding the concept of an anonymous block/function, and seeing how it can be passed around like a value. If you understand how custom sorts, or how map and grep work, you're well on your way for basic, practical, Perl-wise functional programming. For future reference, the greater launch off point from there would be to read HOP (Higher Order Perl), but that's pretty intense, I don't grok all of it myself.

The other one, OOP... I think a lot of formal OOP fans will point out that Perl's current implementation of OOP is kinda... Not good. But! Don't let that stop you from learning the basics. A Perl object is kinda like a basic data primitive (usually a hash) that has a special name and has functions attached to it called methods.

It's pretty awesome. I've never done OOP until my first corporate job, so I can understand your hesitation in learning. Just... Get out there and do something. Anything! Rolling your own content management system seems to be a pretty full goal, if you want.

# ? Oct 25, 2007 04:27

Stabby McDamage: Dec 11, 2005; Doctor Rope

syphon^2 posted:

So, Perl gurus, where do I go next?

As much as I like Perl, anyone who programmer should be largely language-agnostic. Pick up more languages, learn their strengths and weaknesses, and add them to your toolbox. Moving from low level languages to higher ones is generally easy, as you're just adding to your feature set; C->Perl and Perl->Python are examples of this. Moving the other direction is harder: you have to learn new skills and ways of thinking. Perl->C will be painful, but you'll grow a lot as a programmer.

That said, leveling up in Perl is also a virtue, as it's good to have a "home" language where you can knock out language-neutral problems quickly. Pick up the "camel book" (linked in OP), as it covers all the interesting stuff (and some of the less interesting).

Also, it may sound weird, but I read the Perl Cookbook cover to cover, even though is supposed to be a reference. That's where you learn neat ways to turn the bucket of knowledge that regular texts give you into real programming horsepower.

OOP in Perl is good if you want to make a few modules interact and have a clean namespace. However, doing a lot of heavy lifting using OOP principles can get very hairy very fast if you're not experienced and disciplined. It pains me to say, but if you find yourself thinking how to "architect" or "refactor" a Perl program, it may be time to move to another language.

# ? Oct 25, 2007 04:59

Ninjew: Aug 3, 2004

God, I love perl. No other language gives you the same kind of freedom to cheat and create very clever solutions to problems. Have a problem that would be best solved using a functional language like LISP? Just set no strict refs, and off you go! It is very refreshing to be able to actually program in a way that is not limited or constrained by the language. Don't listen to anyone who says that this flexibility is a negative aspect of perl, rather than a positive one. They are very wrong.

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.

# ? Oct 25, 2007 09:27

Ninjew: Aug 3, 2004

Stabby McDamage posted:

- Subroutines can be passed as variables ("closures").

Actually, this isn't what a closure is. A closure is a logical concept that comes along with perl being a formal language: in any abstract block of code (subroutine, anonymous block), you can have free variables; that is, variables that aren't declared (lets assume that we have strict vars on) , or, in logical terms, aren't bound. Perl supports closures, in that, if that variable is bound outside of that block of code, it is considered as a constant, not a variable, in that code. For example:

code:

my $teh = "asdf\n";
{
    print $teh;
}

This is an example of a closure, although a rather pointless one. Or, in a little more practical example:

code:

use strict;
my $asdf = "asdf\n";
my $ref = sub { my $foo = shift; print "$foo$asdf"; };
&{$ref}("teh")

OUTPUT:
tehasdf

The fact that perl supports creating references to subroutines does not imply that it supports closures - that is, allowing externally bound variables to be bound inside blocks where they appear as free (unbound) variables.

# ? Oct 25, 2007 09:46

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

floWenoL: Oct 23, 2002

Ninjew posted:

Perl supports closures, in that, if that variable is bound outside of that block of code, it is considered as a constant, not a variable, in that code. For example:

I'm not sure what exactly you mean by "constant", but if you mean the value of the variable is fixed to whatever the value is at the time of the creation of the closure, it's not true:

code:

use strict;
my $asdf = 'asdf';
my $ref = sub { my $foo = shift; print "$foo$asdf\n"; };
$ref->('teh');
$asdf = 'wut';
$ref->('teh');

prints "tehasdf" and "tehwut".

floWenoL fucked around with this message at 11:44 on Oct 25, 2007

# ? Oct 25, 2007 11:40

floWenoL: Oct 23, 2002

Ninjew posted:

God, I love perl. No other language gives you the same kind of freedom to cheat and create very clever solutions to problems. Have a problem that would be best solved using a functional language like LISP? Just set no strict refs, and off you go! It is very refreshing to be able to actually program in a way that is not limited or constrained by the language. Don't listen to anyone who says that this flexibility is a negative aspect of perl, rather than a positive one. They are very wrong.

You are equally wrong in painting Perl's flexibility (to say it in the best possible way) in a rose-colored light (mixing metaphors here). It's a double-edged sword, and frankly, the negative edge is bigger. I'm also not sure why you associate the behavior of "no strict refs" with functional languages, given that that is a feature shared by most, if not all, dynamic languages, functional or not.

Edit:
I like Perl, but let's not turn this thread into a wankfest.

# ? Oct 25, 2007 11:53

Stabby McDamage: Dec 11, 2005; Doctor Rope

floWenoL posted:

... It's a double-edged sword, and frankly, the negative edge is bigger...
I like Perl, but let's not turn this thread into a wankfest.

Then we can just agree that it's an excellent language for stabbing things until they die, and that children should be kept away from it.

# ? Oct 25, 2007 18:06

There Will Be Penalty: May 18, 2002; Makes a great pet!

Ninjew posted:

Stabby McDamage posted:
- Subroutines can be passed as variables ("closures").

Actually, this isn't what a closure is. *snip*

Nice clarification. Also, whether or not your language supports closures, the concept of passing subroutines (or subroutine references) as variables is properly termed "higher-order programming".

:eng101:

# ? Oct 25, 2007 19:38

Ninjew: Aug 3, 2004

floWenoL posted:

I'm not sure what exactly you mean by "constant", but if you mean the value of the variable is fixed to whatever the value is at the time of the creation of the closure, it's not true:

You're right- I got closures from formal logic mixed up with perl's implementation.

floWenoL posted:

I'm also not sure why you associate the behavior of "no strict refs" with functional languages, given that that is a feature shared by most, if not all, dynamic languages, functional or not.

I was giving an example of perl's flexibility, not comparing it to other languages.

# ? Oct 25, 2007 21:55

Z-Bo: Jul 2, 2005; more like z-butt

Have any Perl folks read the book Perl Medic? If so, I was wondering what you thought of it. I read a book review for Perl Medic at TechBookReviews and they claimed it was "highly recommended".

# ? Oct 25, 2007 22:03

ashgromnies: Jun 19, 2004

Z-Bo posted:

Have any Perl folks read the book Perl Medic? If so, I was wondering what you thought of it. I read a book review for Perl Medic at TechBookReviews and they claimed it was "highly recommended".

Nope, but that review convinced me to buy it, after maintaining a shitload of legacy perl code.

# ? Oct 25, 2007 22:19

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

Z-Bo posted:

Have any Perl folks read the book Perl Medic? If so, I was wondering what you thought of it. I read a book review for Perl Medic at TechBookReviews and they claimed it was "highly recommended".

I have it and I wasn't impressed. I have a fairly good grasp of software (I think?) and how unit tests work...

But you know what I think the book is good for? Collating that stuff into one place so that someone who didn't know about any of it would have a really broad understanding. So, it wasn't as in depth as I personally would have liked, but I think it did a good job introducing some concepts and strategies for otherwise daunting tasks.

It comes up short in some places, where you'd like to know more, but as far as I can tell, people are very all or nothing with unit tests, so if you're from the nothing camp, then this book is an okay have. I'd suggest reading it at a bookstore to see how much value it can provide to you. I don't regret purchasing it, but I wish there was more to it.

# ? Oct 25, 2007 22:49

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

Could you add PerlMonks to the OP, please? If the reader is willing to take the time to form well-worded questions (as they do here), the community loves to give back and help people learn more about Perl.

# ? Oct 26, 2007 03:09

repeater: Dec 21, 2001; "Choo-Choo"
The Hurkey Jerkey Dancer

^^ Agreed

"Perl Best Practices" by Damian Conway is hands-down the best perl book I have ever read, and (even though it is all perl) has a ton of general "do it right like this and here is why and why not" kind of advice for those of us that jump around languages a lot.

It is formatted very similar to the Cookbook, but the answers are more focused on maintainability and clean coding practices rather than "look what I can do!" - which is what really bugs me about the cookbook.

It really made me appreciate the language more, even as a really ocd-ish coder living in a perl shop.

Perl Design Patterns is also a great resource, especially the Problem Index. Most of the common big-picture / refactoring problems found in perl applications are targeted there with suggestions for a clean design fix.

Also, everyone should use Inside-Out Objects and be happy.

# ? Oct 26, 2007 11:05

SmirkingJack: Nov 27, 2002

Stabby McDamage posted:

Books
- Learning Perl, 3rd ed. The O'Reilly book for learning the language. Google Books.

~~Is there an appreciable difference between the third and fourth editions of this book? Or rather, should I specifically buy the third edition instead of the fourth?~~

Never mind, the third edition I saw listed was for a different title. Bleh.

SmirkingJack fucked around with this message at 14:52 on Oct 26, 2007

# ? Oct 26, 2007 14:47

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

1) How do you feel about Perl6? I saw a Google Video of Audrey's talk to a Japanese audience and it was pretty amazing. It was a really good presentation and I'm absolutely sold on Perl6. I'm a believer! I think if I knew more about what was required to contribute, I would. But I won't speak Haskellese or whatever.

2) What experience do you have with code coverage? James Keenan at perl seminar ny presented about it and it seemed pretty interesting. I honestly thought unit testing was the end all be all of how to pimp out your code, but code coverage testing seems to be a second tier above that. Very interesting.

# ? Oct 26, 2007 15:27

ashgromnies: Jun 19, 2004

Triple Tech posted:

1) How do you feel about Perl6? I saw a Google Video of Audrey's talk to a Japanese audience and it was pretty amazing. It was a really good presentation and I'm absolutely sold on Perl6. I'm a believer! I think if I knew more about what was required to contribute, I would. But I won't speak Haskellese or whatever.

I'm just unsure if perl6 will be released in time to be useful - they've been developing it since, what, 2000? So many other dynamic languages have been picking up speed and getting massive developer support - perl6 looks very cool, but I don't know how well it will fare since it seems like new projects written in perl are becoming less common and it's being used more to maintain legacy code.

Just my $.02

# ? Oct 26, 2007 16:47

npe: Oct 15, 2004

Perl 6 is just so different that it's really a different language altogether. That means it has to overcome the same inertia to switch that every other language has to overcome today to get people off perl. I guess what I'm saying is, what is keeping me on perl today is what's going to keep me from using perl 6 tomorrow.

# ? Oct 26, 2007 18:27

ashgromnies: Jun 19, 2004

Satan's Scallion posted:

Perl 6 is just so different that it's really a different language altogether. That means it has to overcome the same inertia to switch that every other language has to overcome today to get people off perl. I guess what I'm saying is, what is keeping me on perl today is what's going to keep me from using perl 6 tomorrow.

Yea, you're right about that. It will all come down to what it does better than other languages people are using.

# ? Oct 26, 2007 20:12

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

ashgromnies posted:

Yea, you're right about that. It will all come down to what it does better than other languages people are using.

Larry Wall posted:

Playing football is like programming in the large. You have to agree on a lot of rules to do it with other people. Perl5 doesn't make it terribly easy to agree on a set of rules, and we hope to make that easier in Perl6. You have to have discipline to do programming in the large, but you'll choose the discipline by turning up the big discipline knob yourself, not by having someone else turn it up for you. Perl6 will give you the big knob.

I'm not aware of any other language making that kind of promise. :colbert:

# ? Oct 26, 2007 20:20

ashgromnies: Jun 19, 2004

rotor posted:

I'm not aware of any other language making that kind of promise.

That sounds interesting, what does he mean exactly? I haven't been keeping up on the Perl6 featureset.

# ? Oct 26, 2007 20:22

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

ashgromnies posted:

That sounds interesting, what does he mean exactly? I haven't been keeping up on the Perl6 featureset.

Honestly, I don't know, I was just making a wang joke. Which I seem to be doing a lot in the last couple days, that's a little troubling. :-/

anyway, found the quote here if it helps at all.

# ? Oct 26, 2007 20:30

repeater: Dec 21, 2001; "Choo-Choo"
The Hurkey Jerkey Dancer

ashgromnies posted:

I'm just unsure if perl6 will be released in time to be useful - they've been developing it since, what, 2000? So many other dynamic languages have been picking up speed and getting massive developer support - perl6 looks very cool, but I don't know how well it will fare since it seems like new projects written in perl are becoming less common and it's being used more to maintain legacy code.

The main core of people working on Perl6 seem to be doing some really kickass stuff, but unfortunately I will still be ignoring it until it get close enough to release (all the stuff I do needs stable, not bleeding edge). Also, I am pretty agnostic to the language I work in, so I am not sitting around tapping my foot waiting for "the new perl". Perl 5.x is getting the job done, so that is what I use.

The best part of the whole Perl6 thing is the backporting of some of the cool and handy stuff from 6 for use in 5.x:

See: Perl6::* on CPAN

(Notice most of the cool ones are by Damien Conway, because he is awesome as all hell)

While I am at it and kissing Conway's rear end, I also really reccomend the Getopt::Euclid module, which lets you write a perldoc explaining your script usage while ALSO using that same perldoc to know how to grab command opts and type checking them without extra work from you.

For example,

code:

  =item  --foo <bar>
  
  Specify a bar number for a foo (must be a positive number, defaults to 1234)

  =for Euclid:
    bar.type:    +int
    bar.default: 1234

Next time you run your script:

* The help / usage / man flags will show the new command line option (duh)
* User can specify --foo 2132142 without extra work from you
* Your code can grab it as $ARGV{foo} (much prettier than the normal way of doing it via getopts or straight @ARGV)
* Default is set somewhere sane
* Input / type checking is done before it even GETS to your code, including proper error messages (you do NOT ever have to write type checking error messages for your input params again)

So yea, not amazingly cool, but it is little stuff like that for perl that makes me love it. Someone just went "wait, this is the best way to express this common task just once and just make it work, so you can move on to the actual bizlogic code you get paid to write" - and I can get behind that kind of thinking.

repeater fucked around with this message at 22:48 on Oct 26, 2007

# ? Oct 26, 2007 22:45

floWenoL: Oct 23, 2002

Triple Tech posted:

1) How do you feel about Perl6? I saw a Google Video of Audrey's talk to a Japanese audience and it was pretty amazing. It was a really good presentation and I'm absolutely sold on Perl6. I'm a believer! I think if I knew more about what was required to contribute, I would. But I won't speak Haskellese or whatever.

I saw Audrey's presentation live when she went to Amazon. There's some nifty stuff in Perl 6, but it's going to suffer from the same problem as Perl 5, but to a larger extent: to do any maintainable work you need to adopt a set of coding conventions (e.g., "Perl Best Practices") and resolve to only use a subset of the language. And this quickly gets ugly when you have to work with code from a different base (and different conventions and subsets of the language).

# ? Oct 27, 2007 01:24

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

I have this new coding style I've adopted, and personally, I like it. But I'm pretty sure no one else is keen on it. What do you guys think?

I don't know if this illustrates it enough, but it's tucking a whole set of temporary variables inside the scope of a do-block, where the last line/return value of the do block is what we actually want.

The reason I did this is because sometimes, to fetch the data we want, we have to go through these multi-phase transforms of data. I feel like all the temporary variables we use pollute the namespace. Like, certain structures aren't used for anything but the derivation of the last data structure. So I figured, why not tuck it into one temporary scope.

It's kinda like... An unwound subroutine.

code:

sub old_way {
  my $self = shift;

  my @resources = Global::get_resources();
  my $filter = $self->getFilter;

  my $boolean = grep { $_ eq $filter } @resources;

  return $boolean;
}

sub new_way {
  my $self = shift;

  my $boolean = do {
    my @resources = Global::get_resources();
    my $filter = $self->getFilter;

    grep { $_ eq $filter } @resources;
  };

  return $boolean;
}

# ? Oct 30, 2007 18:46

heeen: May 14, 2005; CAT NEVER STOPS

^^ I think you don't even need do, wouldn't just curly brackets suffice?

a little gem I recently stumbled over:
How to sort a subset by a given ordered superset:

code:

#/usr/bin/perl -w
my @subset=('z','v','a','t');
my @ordered_total=(a..z);
print "$_," for (@subset);
print "\n";
print "$_," for (@ordered_total);
print "\n";


my %h; 
$h{ $_} = 1 for @subset;
my @ordered_sub = grep $h{ $_}, @ordered_total;


print "$_," for (@ordered_sub);
print "\n";

code:

z,v,a,t,
a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z,
a,t,v,z,

# ? Oct 30, 2007 19:15

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

I don't think you can save the value of an anonymous block, hence the do part. And, how would you differentiate it from an anonymous hash? I can't even come up with a compilable example without a do.

# ? Oct 30, 2007 19:40

Twlight: Feb 18, 2005; I brag about getting free drinks from my boss to make myself feel superior; Fun Shoe

I have a large file that has strings that I would like to extract into a new file, I know I have to use regex but I'm unsure as to How I should format it. I want to save all words that have WS-xxxxx where xxxx is a name everything else in the file I don't care about. Any Ideas?

# ? Oct 30, 2007 19:57

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

Twlight posted:

I have a large file that has strings that I would like to extract into a new file, I know I have to use regex but I'm unsure as to How I should format it. I want to save all words that have WS-xxxxx where xxxx is a name everything else in the file I don't care about. Any Ideas?

Well, what you're saving in the ideal Perl world would probably become an array. How that is serialized is completely up to you and shouldn't matter. You could freeze/thaw the entire structure (overkill). The simplest way to go about it would be to have each item be a line in a text file.

There's also YAML, tie'ing that array/file...

# ? Oct 30, 2007 20:04

floWenoL: Oct 23, 2002

Triple Tech posted:

I have this new coding style I've adopted, and personally, I like it. But I'm pretty sure no one else is keen on it. What do you guys think?

I don't know if this illustrates it enough, but it's tucking a whole set of temporary variables inside the scope of a do-block, where the last line/return value of the do block is what we actually want.

That's actually pretty cool. I'd rather have a 'return' explicitly in the last line of the block, though.

Edit:
Oops, do {} doesn't support return. :|

floWenoL fucked around with this message at 22:30 on Oct 30, 2007

# ? Oct 30, 2007 20:22

Twlight: Feb 18, 2005; I brag about getting free drinks from my boss to make myself feel superior; Fun Shoe

Triple Tech posted:

Well, what you're saving in the ideal Perl world would probably become an array. How that is serialized is completely up to you and shouldn't matter. You could freeze/thaw the entire structure (overkill). The simplest way to go about it would be to have each item be a line in a text file.

There's also YAML, tie'ing that array/file...

This is what I have so far, it cut down a lot of the txt that I didn't need. now each line has this format

code:

ip adress<tab>ws-username(this is the info i want)<tab>unused info

here is my code

open(FILE,"pso.txt");
@arr = <FILE>;

open(NEWFILE,">newfile.txt");
foreach $line(@arr)
{
	if($line =~ m/.ws\-/i)
		{
			print NEWFILE $line;
    }

# ? Oct 30, 2007 20:28

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

Twlight, I would break down the code into phases, platonic ideal first, storage second. The point is, you want your two idioms in two seperate paragraphs and not bound so tightly together.

floWenoL, I don't think do-block supports return, only subroutines.

code:

# untested

# phase one, capture
my @wanted_values = do {
  open DATA, "pso.txt";
  my $file = do { local $/; <DATA> };
  close DATA;

  ($file =~ /expr/g);
};

# phase two, storage
freeze @wanted_values, "wanted.txt"; # or whatever

# or...
open STORAGE, "saved.txt";
print STORAGE join "\n", @wanted_values;
close STORAGE;

# or...
YAML::out(\@wanted_values, "wanted.txt"); # or whatever

# ? Oct 30, 2007 20:38

tef: May 30, 2004; -> some l-system crap ->

Triple Tech posted:

I feel like all the temporary variables we use pollute the namespace. Like, certain structures aren't used for anything but the derivation of the last data structure. So I figured, why not tuck it into one temporary scope.

Isn't that what my is for?

code:

my $main = "outer";
{
    my $temp = "yes";  # create a lexically scoped variable
    $main="inner";     # set the outer variable
    print "Inner: main=$main, temp=$temp\n";
}                      # temp is deallocated
print "Outer: main=$main, temp=$temp\n";

Inner: main=inner, temp=yes
Outer: main=inner, temp=

quote:

I have this new coding style I've adopted, and personally, I like it. But I'm pretty sure no one else is keen on it. What do you guys think?

Here is a simple metric to evaluate coding styles:

Does it make the code simpler?
Does it make the code more general?
Does it make the code clearer?

Yours doesn't make the code simpler, or clearer.

tef fucked around with this message at 20:59 on Oct 30, 2007

# ? Oct 30, 2007 20:55

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

tef posted:

Does it make the code simpler?
Does it make the code more general?
Does it make the code clearer?

Yours doesn't make the code simpler, or clearer.

That's funny, I think it does satisfy all of those points.

1) It makes it apparent that an assignment is dependent on that paragraph of code and nothing else.
2) That paragraph is a matter of implementation, like a method. How it's done shouldn't be of concern, other than that it is done.
3) It's clear that the variables introduced into that scope are destroyed as the assignment ends, reducing the confusion as to whether or not a top level variable is used later on.

I adopted this particular coding style out of frustration of maintaining other people's code, where a variable introduced near the top of a subroutine may or may not have been used at all in the subroutine itself. I feel like my style says, "this definitely is in use right now by this other variable" instead of "well we're predeclaring something, but I'm going to leave it up to you to figure out whether or not its useful!".

# ? Oct 30, 2007 21:26

floWenoL: Oct 23, 2002

heeen posted:

^^ I think you don't even need do, wouldn't just curly brackets suffice?

a little gem I recently stumbled over:
How to sort a subset by a given ordered superset:

Yeah, that works, but you can do it a bit neater:

code:

#!/usr/bin/perl

use strict;
use warnings;

my @subset = qw(z v a t);
my @ordered_total = ('a'..'z');

print join(',', @subset) . "\n";
print join(',', @ordered_total) . "\n";

my %h = map { $_ => 1 } @subset;
my @ordered_sub = grep { $h{$_} } @ordered_total;

print join(',', @ordered_sub) . "\n";

And if you have many subsets to sort, it might be better overall to have an element => position hash and sort each subset according to that.

# ? Oct 30, 2007 22:32

Adbot: ADBOT LOVES YOU

# ? Apr 18, 2024 11:41

floWenoL: Oct 23, 2002

tef posted:

Here is a simple metric to evaluate coding styles:

Does it make the code simpler?
Does it make the code more general?
Does it make the code clearer?

Yours doesn't make the code simpler, or clearer.

I disagree. His way reduces the time in which the variable is in an "invalid state", which arguably makes it clearer.

# ? Oct 30, 2007 22:35

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

«‹›72 »