|
Install cpanminus, installation is then simply 'cpanm Whatever::Module'
|
#
?
May 1, 2014 05:28
|
|
|
|
| # ? May 21, 2024 15:01 |
|
|
Roseo posted:Install cpanminus, installation is then simply 'cpanm Whatever::Module' Yep, that's what I have in my notes.
|
|
#
?
May 1, 2014 06:18
|
|
|
The OP is going on 7 years old. For beginner programmers who are looking at programming as a hobby, should I be looking at perl 5 or 6? Is Learning Perl still the go to book?
|
|
#
?
May 8, 2014 03:22
|
|
|
Hughmoris posted:The OP is going on 7 years old. For beginner programmers who are looking at programming as a hobby, should I be looking at perl 5 or 6? Is Learning Perl still the go to book? edit: I would assume Learning Perl would still be adequate if you're specifically intent on using perl though
|
|
#
?
May 8, 2014 05:18
|
|
|
het posted:Honestly, unless you have a specific reason to choose perl you'd probably be better off looking at python or ruby if you're just interested in programming as a hobby.  Hughmoris posted:The OP is going on 7 years old. For beginner programmers who are looking at programming as a hobby, should I be looking at perl 5 or 6? Is Learning Perl still the go to book? My personal recommendations are Modern Perl and Ovid's Beginning Perl. Learning Perl is even in the most recent edition simply poo poo: http://perl-tutorial.org/rejected/learning_perl_6th/
|
|
#
?
May 8, 2014 10:38
|
|
|
Mithaldu posted:Way to comment on things you have demonstrably little knowledge of. I feel the same about Learning Perl looking back at it now that I have a few years of Perl under my belt. One of my junior coworkers was reading through it recently, and complaining about all the weird examples it tries to give you in an attempt to explain how things work, but it just comes off as, "Don't ever do this, but look at all the crazy poo poo you can manipulate to no useful purpose." Modern Perl is fantastic and free online. It will get you through what both Learning Perl & Intermediate Perl cover. I've never looked into "Mastering Perl", so I can't vouch for it, but the next big step once you're comfortable with object oriented Perl, exception handling, closures, etc would be Higher Order Perl -- it's pretty great, has some complex insights, and dives a bit into functional programming. Data Munging with Perl was recently put online for free as well. Quite a bit of the modules it uses are deprecated, but in terms of parsing/sorting/formatting random info into something useable, it's pretty interesting and the techniques it uses are still quite apt. Lanithro fucked around with this message at 18:58 on May 8, 2014 |
|
#
?
May 8, 2014 18:55
|
|
|
Mithaldu posted:Way to comment on things you have demonstrably little knowledge of. edit: fair point though, I just shouldn't have bothered to say anything about Learning Perl. het fucked around with this message at 05:53 on May 9, 2014 |
|
#
?
May 9, 2014 05:24
|
|
|
het posted:Way to be a dickhead, I guess? The important part is that anyone who's looking to get into perl because they have a general interest in learning programming as a hobby should be informed that it's probably not the best option (depending on what they want to do with it). Yeah, I learned perl 20 years ago, sorry for not keeping up with beginner texts. Why shouldn't people be learning perl? Because you learned it 20 years ago, or because you don't like what 20 year old perl looks like? I can't tell because you just told the guy to learn python or ruby without listing any reasons why those are better alternatives. I don't doubt that in many cases that holds true, but if your only argument listed is "just learn python or ruby" what type of response can he really give?
|
|
#
?
May 9, 2014 17:56
|
|
|
uG posted:Why shouldn't people be learning perl? Because you learned it 20 years ago, or because you don't like what 20 year old perl looks like? I can't tell because you just told the guy to learn python or ruby without listing any reasons why those are better alternatives. I don't doubt that in many cases that holds true, but if your only argument listed is "just learn python or ruby" what type of response can he really give? I'm thinking he made the suggestion because Perl isn't the hip/fresh/new/popular language these days, and a lot more people seem to be doing active work in Python and Ruby. A lot of people think Perl is a dirty word. Which is a shame, because I love it, but you need to stay aware of what's going on in the tech world.
|
|
#
?
May 9, 2014 18:10
|
|
|
prefect posted:I'm thinking he made the suggestion because Perl isn't the hip/fresh/new/popular language these days, and a lot more people seem to be doing active work in Python and Ruby. A lot of people think Perl is a dirty word. Which is a shame, because I love it, but you need to stay aware of what's going on in the tech world. (and while I learned it 20 years ago, I still do work in perl in my job, and it's not some ancient codebase, so don't get the impression I'm saying that based just on decades-out-of-date perl code)
|
|
#
?
May 10, 2014 05:32
|
|
|
het posted:It's not even the "dirty word" aspect, or popularity/"hipness", just that I think both of those languages are more approachable for beginners. That said, i disagree with your opionion. In my experience the language itself plays less of a role in how approachable it is and Ruby and Python are certainly not saints. One general thing to keep is in mind that programming newbies tend to be VERY confused by OO, but can grok imperative programming intuitively, yet both of these languages go strongly OO-first. Further, both of them have some very ugly warts that lead to common newbie confusion: http://www.toptal.com/python/top-10-mistakes-that-python-programmers-make http://stackoverflow.com/questions/372652/what-are-the-ruby-gotchas-a-newbie-should-be-warned-about However, for most languages this can be fixed by well-written documentation, which is where Perl sucked for a LONG time and where Python and Ruby absolutely excelled in, thanks to having excellent docs on their languages website front and center (Python) or having excellent writers (_why). However with Modern Perl and Ovid's Beginning Perl, Perl has caught up with that. (See for example this explanation on context: http://modernperlbooks.com/books/modern_perl_2014/01-perl-philosophy.html#Q29udGV4dA ) An additional issue is also how newbies find language learning materials. For those who didn't go to the Perl website, but googled "perl tutorial" (many), they found, until 2011, a Perl 4 tutorial. With http://perl-tutorial.org this has been somewhat fixed and newbies can now actually find good learning materials. So, i do consider it ill-advised to claim perl is less newbie-approachable than others, if you don't take into account how a newbie does experience their first approach to Perl nowadays.
|
|
#
?
May 10, 2014 19:44
|
|
|
I want to export a global method (used for logging of course) to all packages in my company's namespaces, and if a new package in my company's namespaces is loaded dynamically I want to detect that and export my method to there too. I can't figure out a good way of doing this, I have two ideas but they aren't all that ideal. One is to create a package dedicated to exporting a global logging method, and explicitly use'ing that package to export my logging method into the namespace that invoked &import. The other idea is to override a global and hijack its functionality (eg hijack CORE::GLOBAL::log), checking caller and deferring to regular logarithm behavior if called by an unexpected package. I had some other idea that are terrible, one is autodetecting every package in my companies namespaces (grepping for '^package' directives in .pm files in my lib paths) and pre-exporting my logging method to all packages. An even worse one was overriding strict::import (except that is lexical, getting it to work when you have multiple packages in a file is a no go) I had an even worser idea, but apparently providing your own UNIVERSAL::AUTOLOAD impl is bad. Does anything cleaner exist?
|
|
#
?
May 12, 2014 07:13
|
|
|
homercles posted:I had an even worser idea, but apparently providing your own UNIVERSAL::AUTOLOAD impl is bad.
|
|
#
?
May 12, 2014 14:26
|
|
|
het posted:It's not even the "dirty word" aspect, or popularity/"hipness", just that I think both of those languages are more approachable for beginners. I'm not even saying the poster in question shouldn't necessarily learn Perl, just that if they chose that without being aware that a lot of people would recommend other languages for learning, it would be useful for them to be aware of that. I probably shouldn't have used words like "hipness" -- a little too flippant. I was thinking in terms of getting work -- there are Perl jobs out there, and there is work being done in Perl for jobs that aren't explicitly titled "Perl programmer", but you'll see a lot more job ads with Python or Java or (ugh) Ruby in the list of requirements. But the initial request was about programming as a hobby, so Perl's not so bad a suggestion -- CPAN is still a super-fantastic resource.
|
|
#
?
May 12, 2014 14:31
|
|
|
prefect posted:I probably shouldn't have used words like "hipness" -- a little too flippant. I was thinking in terms of getting work -- there are Perl jobs out there, and there is work being done in Perl for jobs that aren't explicitly titled "Perl programmer", but you'll see a lot more job ads with Python or Java or (ugh) Ruby in the list of requirements. But the initial request was about programming as a hobby, so Perl's not so bad a suggestion -- CPAN is still a super-fantastic resource. CPAN is amazing for Perl resources. And it's surprisingly easy to publish on, when you develop something useful. That said, I would not recommend Perl to any newbie. You will find far too many bad and out of date resources when googling. To abuse the old idiom, it is incredibly easy to shoot yourself in the foot in 3 characters or less. Idiomatic perl is hard to get up to date on. Python or Ruby will offer much better resources when googling, good tutorials, and look better on the resume. I will always pick Perl for my projects out of those 3 (because I think they're all functionally equivalent), but I think recommending it as a language is not the right course.
|
|
#
?
May 13, 2014 00:20
|
|
|
homercles posted:One is to create a package dedicated to exporting a global logging method, and explicitly use'ing that package to export my logging method into the namespace that invoked &import.
|
|
#
?
May 13, 2014 01:20
|
|
|
Mithaldu posted:Frankly, that is the sanest way i can think of doing this, as you can very tightly control when it should happen. On the other hand, your idea itself is entirely loving insane and i don't understand what the issue is with simply telling people to do use Our::Log 'log_info'; whenever they wish to log. I was trying to remember this last one (much better than mucking with &UNIVERSAL::AUTOLOAD), and that's putting a coderef into @INC to get notified when a library is about to be loaded, but before it actually is eval'ed. You can then open the file, scan through it for package declarations and pre-stash your prototyped "globals" into the to-be-loaded namespaces. 
|
|
#
?
May 13, 2014 02:16
|
|
|
Jifty used sub _ for localization, which is exposed globally thanks to $_ and @_ and the magic of typeglobs.
|
|
#
?
May 13, 2014 22:31
|
|
|
As merely something to do, I've been muddling my way through Beginning Perl. I've discovered CodeAbbey.com so I've been trying to work on problems as I work my way through the book. I'm already stuck. Here is the problem #3: http://www.codeabbey.com/index/task_view/sums-in-loop Basically, I have an N amount (the first number) of pairs of numbers. I want to read in a pair of numbers, add them, print the sum, then move on to the next pair of numbers. code:*It looks like this is a theme on some of their problems. Read in a line of user input, perform some operation on that line, then move onto the next line and repeat.
|
|
#
?
Jun 3, 2014 03:40
|
|
|
Hughmoris posted:As merely something to do, I've been muddling my way through Beginning Perl. I've discovered CodeAbbey.com so I've been trying to work on problems as I work my way through the book. If you wanted to do it from a file, it's relatively simple. You want to open the text file with a filehandle as a reference, and then loop through the filehandle to go one line at a time, doing things to each line as appropriate. code:Doing it from <STDIN> is going to be a little bit different and with a little bit of googling you should be able to figure out how that works. I recommend doing some test scripts and printing out everything as you go so you understand how things work, rather than trying to get it right the first time. Olesh fucked around with this message at 04:11 on Jun 3, 2014 |
|
#
?
Jun 3, 2014 04:09
|
|
|
Olesh posted:Helpful information... Thanks for taking the time to write that up. After hacking away at it, I managed to get the correct solution. It ain't pretty but it works. code:
|
|
#
?
Jun 3, 2014 04:46
|
|
|
I don't want to go golf crazy or anything silly, but I'd do this. Might even use File::Slurp to remove the manual fh open if the file is known to be quite small. Removing boiler plate via core-ish modules.code:code:
|
|
#
?
Jun 3, 2014 05:32
|
|
|
homercles posted:I don't want to go golf crazy or anything silly, but I'd do this. Might even use File::Slurp to remove the manual fh open if the file is known to be quite small. Removing boiler plate via core-ish modules. I'll have to sit down and try to figure those out. Now that I've figured out how to properly read in a file and split it into an array, I've knocked out the next 5 problems. 
|
|
#
?
Jun 3, 2014 06:04
|
|
|
Still working my way through the basics of Perl using Beginning Perl. When declaring a subroutine, is it recommended to declare it at the beginning or end of the program? I'm using an online IDE at the moment and the program seems to run both ways. I can declare the subroutine before I ever call it, or I can declare the subroutine after I call it. Both run fine.
|
|
#
?
Jun 8, 2014 23:39
|
|
|
Hughmoris posted:Still working my way through the basics of Perl using Beginning Perl. When declaring a subroutine, is it recommended to declare it at the beginning or end of the program? I'm using an online IDE at the moment and the program seems to run both ways. I can declare the subroutine before I ever call it, or I can declare the subroutine after I call it. Both run fine. I hope you mean the book Ovid wrote, not the terribly outdated one.  As for subroutines: Put them below any possible code you have in the global scope of your script or module. The reason for that is very simple: You save someone else the trouble to see if you hid any compile-time code between or under your subroutines.
|
|
#
?
Jun 9, 2014 03:11
|
|
|
homercles posted:I don't want to go golf crazy or anything silly, but I'd do this. Might even use File::Slurp to remove the manual fh open if the file is known to be quite small. Removing boiler plate via core-ish modules. Not to be a dick, but neither of these is easy for a beginner to understand, and more importantly, they give the wrong answer. From the site... quote:Input data will contain the total count of pairs to process in the first line. Yours include 3 as part of the answer, which is not part of the pairs to be summed.
|
|
#
?
Jun 10, 2014 16:29
|
|
|
code:
|
|
#
?
Jun 10, 2014 21:47
|
|
|
Is there a case-sensitive method to test for file existence? For example, if I have a file named C:/Abc.txt, then I want "it does not exist" to print: code:
|
|
#
?
Jun 12, 2014 19:28
|
|
|
mister_gosh posted:Is there a case-sensitive method to test for file existence? You can loop through a glob and test each file with a case insensitive regex.
|
|
#
?
Jun 12, 2014 19:38
|
|
|
mister_gosh posted:Is there a case-sensitive method to test for file existence? On windows that is meaningless, since, if you have a file named Abc.txt, you cannot have a file named abc.txt, and trying to access either will access the same file.
|
|
#
?
Jun 12, 2014 23:48
|
|
|
Toe Rag posted:Not to be a dick, but neither of these is easy for a beginner to understand, and more importantly, they give the wrong answer. From the site... The intention was not to write beginner code since that resembles K&R C.I've just gotten bitten by POSIX behavior or whatever, we're stashing a bunch of data into __DATA__, the DATA handle is literally an open file descriptor of the file in question. Since fork() will use the same underlying file descriptor in the kernel, all our reads to DATA in sibling apache processes are slapfighting each other. It was a very lazy approach to stuff some lookup in the __DATA__ portion, turns out it was disastrous.
|
|
#
?
Jun 13, 2014 06:09
|
|
|
Mithaldu posted:On windows that is meaningless, since, if you have a file named Abc.txt, you cannot have a file named abc.txt, and trying to access either will access the same file. Sounds to me like this person is more interested in which case (a/A) Windows has stored for the file's name than whether it strictly "exists".
|
|
#
?
Jun 13, 2014 11:41
|
|
|
Current Work Status: Discovered one of our most important bits of code is a Frankensteinian mish-mash of Moose and Moo, because a contributor tried to s/Moose/Moo/ but got it wrong and left half of the relevant roles untouched 
|
|
#
?
Jul 3, 2014 12:04
|
|
|
Mario Incandenza posted:Current Work Status: Discovered one of our most important bits of code is a Frankensteinian mish-mash of Moose and Moo, because a contributor tried to s/Moose/Moo/ but got it wrong and left half of the relevant roles untouched But it still works? 
|
|
#
?
Jul 3, 2014 12:22
|
|
|
Yeah, Moo will load Moose roles just fine (though using both libraries simultaneously is pretty weirdo).
|
|
#
?
Jul 3, 2014 19:14
|
|
|
Is there a "standard" way people set up development environments and track dependencies for Catalyst applications? I'm most familiar with tools like Bundler and Composer. I know Carton exists, but I'm not sure how well it works with Catalyst and their (otherwise great) documentation is a bit light on setup information.
|
|
#
?
Jul 7, 2014 06:11
|
|
|
fidel sarcastro posted:Is there a "standard" way people set up development environments and track dependencies for Catalyst applications? I'm most familiar with tools like Bundler and Composer. I know Carton exists, but I'm not sure how well it works with Catalyst and their (otherwise great) documentation is a bit light on setup information. I don't think there is a standard way, since getting Perl deps into production depends on too many variables. (What does policy say, system packages, do we have a compiler, etc.) Carton is a great solution and will work for almost all situations. However for a better answer you should go with the standard support way, hang out in #catalyst on irc.perl.org for a week (that means don't loving disconnect, get a bouncer/shell if you don't have a useful machine) and ask questions as you set things up.
|
|
#
?
Jul 7, 2014 09:03
|
|
|
Mithaldu posted:(that means don't loving disconnect, get a bouncer/shell if you don't have a useful machine) Why is this such a big deal? I thought you were all about lowering the barrier to entry.
|
|
#
?
Jul 7, 2014 16:39
|
|
|
It's really frustrating to both asker and answerer if a lengthy and thoughtful reply to your question gets lost because you were disconnected when someone who had the ability and time to answer got around to it. I don't recall if the bot that hangs around in the perl channels has a !tell command to get around this problem. That being said, many new Perl users these days aren't coming from a unix-heavy background or a 90s-mirc background and won't be that familiar with bouncers or screen or tmux specifically or irc in general, and telling them gently how to avoid disconnects and their attendant issues is nicer and more profitable than berating them.
Blotto Skorzany fucked around with this message at 16:50 on Jul 7, 2014 |
|
#
?
Jul 7, 2014 16:47
|
|
|
|
| # ? May 21, 2024 15:01 |
|
|
Filburt Shellbach posted:Why is this such a big deal? I thought you were all about lowering the barrier to entry. Maybe it's because i sit in #win32, but i see this kind of poo poo almost daily: code:
|
|
#
?
Jul 7, 2014 18:01
|
|