functional functions

punkish has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: functional functions by Zaxo (Archbishop) on May 30, 2007 at 04:18 UTC
Near the beginning of perlfunc, there is a section called "Perl Functions by Category". When I was first learning perl, I read that section at least once a week for several months. The familiarity I got with the kinds of things that perl's builtins do was immediately useful whenever I had an unfamiliar job to do. Familiarity is the key. If you never do any low-level socket programming in perl, you'll never use connect or recv. Knowing they exist as a group assures you that perl can handle a job of that kind and that there are likely some higher level ease-of-use modules. Many perl functions are derived from unix library or system functions. Learning to use them in perl is a great education in unix. If you know unix, you have a head start on learning perl. After Compline, Zaxo	[reply]
Re^2: functional functions by blazar (Canon) on May 30, 2007 at 09:32 UTC
Many perl functions are derived from unix library or system functions. Learning to use them in perl is a great education in unix. If you know unix, you have a head start on learning perl. I second that and although for various reasons I've recently turned into a sort of self-unsatisfied Windows-kinda-guy who plans of turning back to Linux (and maybe BSD) as much as possible, without ever finding the time to do so, basically I would describe myself as NIX-oriented mind. However on the basis of a rational thinking rather than on that of an emotional one, I think that that kind of heritage in Perl is not that good... in fact as far as basic language features are concerned, I think it would be better for the language itself for it to be OS-agnostic not only in actual functionality, but even in look & feel. I think that they're trying to "correct" this bias for Perl 6.	[reply]
Re^3: functional functions by Zen (Deacon) on May 30, 2007 at 13:55 UTC
This is not a flame. Re-read first line. And again. OS agnostic for the sake of being agnostic doesn't solve much. It's tried to be language agnostic, too. Now it's not recognizable to anybody- nobody wins. Yet another syntax to memorize and port to. But there's still time to be convinced, it's not out yet.	[reply]
Re^4: functional functions by blazar (Canon) on May 30, 2007 at 15:37 UTC
Re^5: functional functions by Zen (Deacon) on May 30, 2007 at 16:20 UTC
Some notes below your chosen depth have not been shown here
Re: functional functions by bobf (Monsignor) on May 30, 2007 at 04:58 UTC
It sounds like what you're saying is that you've identified and learned the core set of functions and operators that you need to use on a daily basis to get your work done. If those 64 functions are all you need, then thank Perl for being so powerful. :) I think we all know our own core set, determined (or at least influenced) by the projects we've been on. I think most people (including myself) tend to learn new things as new needs arise, but in addition I try to read documentation as I have time so I'm familiar with the capabilities of the language even if I don't remember the specifics (see also Zaxo's comment to this effect). I don't think there is anything wrong with knowing only a subset of a language. In fact, I would guess very few people (i.e., the true gurus) really know all Perl has to offer. If the post you mentioned in the OP^* opened your eyes to a new function and inspired you to browse through the docs again, good! I hope you enjoy the the journey. :) ^*FWIW, I am not only familiar with pos, but I also used it for nearly an identical purpose as mdunnbass (searching a genomic sequence for matches to a query sequence).	[reply]
Re^2: functional functions by blazar (Canon) on May 30, 2007 at 10:42 UTC
It sounds like what you're saying is that you've identified and learned the core set of functions and operators that you need to use on a daily basis to get your work done. If those 64 functions are all you need, then thank Perl for being so powerful. :) Thoroughly seconded, although it would be fair to remind that there are also some functions like study and reset which are hardly useful nowadays, if they've ever been. Actually I was quite surprised when I discovered them. I don't think there is anything wrong with knowing only a subset of a language. I don't know for "a language", although I suppose that in most cases it is so, however that is certainly the case by design with Perl, as `$Larry` himself wrote. Of course, if you use it regularly and learn more and more along the way, you will become e more refined and knowledgeable "speaker". In fact, I would guess very few people (i.e., the true gurus) really know all Perl has to offer. I would dare to push that as far as to say that even true gurus have different areas of expertise and may not really know all that Perl has to offer.	[reply] [d/l]
Re: functional functions by graff (Chancellor) on May 30, 2007 at 04:31 UTC
<pedantic> Four of the seven things you cited (`if, else, for, while`) aren't really functions, per se, but are flow-control ~~"operators"~~ well, not "operators", exactly, but keywords in syntactic constructions. </pedantic> You may have noticed, in the full perlfunc man page, how the functions can be grouped into categories, and some of those categories are quite specialized -- some are even OS-specific (check the section about "Portability"). To the extent that your normal coding tasks don't take you through some of those categories, you never happen to need those functions. So what? It's good enough to have a vague sense about the categories that are out there, and then you just learn the functions as you need them (i.e. if you don't need them, don't bother and don't worry about it). As for PHP's 3000 functions, I suppose that probably relates to having a different perspective on "modularizing" code, and having a different threshold for the trade-off between creating a uniform run-time environment (bloated with functions that will only be used by 5% of PHP programmers), vs. managing a site-specific module library (where processes only load the functions they use, but there's somewhat more care needed for maintenance). If you counted up everything provided via supplemental CPAN modules, the total number of functions available in Perl is surely an order of magnitude greater than 3000. Thankfully, you really only need to learn about the ones that are relevant to your task. (But then, sometimes you have to figure out which of several alternative sets of functions would be best -- not a simple or linear task.)	[reply] [d/l]
Re^2: functional functions by blazar (Canon) on May 30, 2007 at 09:57 UTC
<pedantic> Four of the seven things you cited (if, else, for, while) aren't really functions, per se, but are flow-control ~~"operators"~~ well, not "operators", exactly, but keywords in syntactic constructions. </pedantic> Yep, incidentally AIUI in Perl 6 they will actually become much more of actual functions. I suspect this is inspired by Smalltalk and perhaps some similar languages, in which, for example, IIRC a conditional is of the form: `CONDITION ifTrue: [DO SOMETHING] ifFalse: [DO SOMETHING ELSE]` [download] and it works in such a way that the message `ifTrue:ifFalse:` is sent to the (boolean) object returned by `CONDITION` and the latter responds to it by selecting to the appropriate block sent as a parameter depending on its own value. In Perl 6 objects are pervasive too, but I believe that control structures are rather of a functional nature, however with this distinction in place, I still think that a somewhat comparable degree of orthogonality and consistency is being sought. As for PHP's 3000 functions, I suppose that probably relates to having a different perspective on "modularizing" code, and having a different threshold for the trade-off between creating a uniform run-time environment (bloated with functions that will only be used by 5% of PHP programmers), vs. managing a site-specific module library (where processes only load the functions they use, but there's somewhat more care needed for maintenance). Yep, there are various reasons why generally Perl crowds do not like PHP, and the latter being bloated with core functions is one of those. Perhaps Perl itself has "too many" functions to begin with, but at least a large number of them is consistent enough in naming and corresponding functionality, while one accusation moved to PHP's is that due to the "urge" to stuff so many of them together, quite a lot of them do not follow any logical naming scheme... Of course, should one want the language with the least number of built-in functions, and FWIW of keywords, she should seek for io, which strives for extreme simplicity and is actually an interesting, not purely academic, language.	[reply] [d/l] [select]
Re^2: functional functions by sanPerl (Friar) on May 30, 2007 at 05:07 UTC
Four of the seven things you cited (if, else, for, while) aren't really functions, per se, but are flow-control "operators" well, not "operators", exactly, but keywords in syntactic constructions. I think punkish is very much aware of this fact. Considering that he is into Perl programming since 4+ years. I think what he meant is, till date he used to developed complicated logics using loops, conditions etc, rather than simply using built-in functions.	[reply]
Re: functional functions by moritz (Cardinal) on May 30, 2007 at 09:52 UTC
Sorry, could not resist: The task you are doing with a regex could be faster with the `index` builtin, seemingly one of the 216 you don't use ;-) BTW Perl 6 has a nice solution to the builtin flood: nearly all builtins are methods, ie they belong to a class, and therefore don't exists as "global" functions. Perl 6 in German	[reply] [d/l]
Re^2: functional functions by blazar (Canon) on May 30, 2007 at 10:22 UTC
BTW Perl 6 has a nice solution to the builtin flood: nearly all builtins are methods, ie they belong to a class, and therefore don't exists as "global" functions. Based on previous conversations, I know you know better than I do, but I believe that more precisely a nice work of reorganization is being made: stuff that would better exist as a method will, and stuff still better suited to be a "plain" function will. Actually the current Synopsis 29 lists quite a lot of them, but perhaps the most interesting part to note is what the document itself writes of builtin functions: Read more... (1210 Bytes) Speaking of methods, one thing that they will replace with a very good overall effect is the bazillion of special variables: granted, they ~~were~~ a very concise and convenient way to do things but are often misleading due to the fact that they're too loosely coupled with the things they do, and the stuff they act upon. So some will regret them and I bet I occasionally will too, but not too much...	[reply] [d/l]
Re: functional functions by Old_Gray_Bear (Bishop) on May 30, 2007 at 18:07 UTC
This is one of the things that really drew me to Perl -- there was a rich set of well thought out basic functions, and a slew of additional bits designed for specific problem domains. (Think about trying to write socket code in a language that does not have the concept of 'network' as one of its fundamental data-constructs.) I found out early on that I used around 30 'functions' over and over in every day working code. When I found myself jumping through hoops to do something, I usually found that there was already a Perl built-in that either was specific for the problem at hand or at least did 85% of the heavy lifting for me. Over the years I have built my repertoire up to maybe 60 more functions. (These are built-ins that I have used often enough so that I recognize the hallmarks of the 'This is an xxx() kind of problem, go read `perlfunc xxx`' when it crops up in my coding.) Over the years, I have been primarily doing data munging and system administration, so my tool set is somewhat asymmetric. But, I suspect that this is not unusual, everyone knows the functions that are specific to the Usual Problem that they face every day. I have encountered the same phenomena in CPAN as well. I have settled on a core of maybe 15 modules that address my run-of-the-mill problems, and around 100 that have been used a couple or three times. I may not have not used them much, but when I needed it they were Just The Thing the Doctor Ordered(tm). I love the fact that TIMTOWTDI is embedded in the fabric of the Perl. I may not take advantage of all of the alternate solutions available (this worked last time ....), but when you need it, the fact that there are alternative solutions designed into the language can be a glorious thing. It keeps the Language from growing stale -- I always have some new nook to explore. ---- I Go Back to Sleep, Now. OGB	[reply] [d/l]
Re: functional functions by agianni (Hermit) on May 30, 2007 at 15:57 UTC
While getting to know the built-in functions of Perl is very important, I would also suggest that, once you are comfortable with the core functions, getting into the habit of with working with CPAN modules is also very important. I've been coding Perl for quite some time and counted about 80 of the functions that I've used in the past. But most of the new problems I come up against are complicated enough that I don't want to learn how to use the additional 136 functions to solve them. So I let someone else use them and use their CPAN modules instead. I just went back trough the past year and it looks like I've installed a new CPAN module a month and I probably look at two or three a month that I don't install. I'm not by any means suggesting that it wouldn't be a good idea to perldoc perlfunc every so often to refresh your memory, I just think that CPAN is one of the most valuable tools of a Perl developer and I found that it took some time to get comfortable with the idea of jumping in an learning the interface to someone else's module. `perl -e 'split//,q{john hurl, pest caretaker}and(map{print @_[$_]}(joi +n(q{},map{sprintf(qq{%010u},$_)}(2*23074993,51016415261,75979 +36997,13177145131,3*26789167*181))=~/\d{2}/g));'` [download]	[reply] [d/l]
Re: functional functions by Moron (Curate) on May 30, 2007 at 13:21 UTC
But, can you imagine how many would you use if every choice NOT to use a function (or method!!) were a conscious one based on fair comparison between the options available? OK, so unless you are very familiar with all the functions and methods you won't be able to do that automatically. But forcing yourself to make conscious informed decisions in this regard, instead of doing what you always did, for just a few days would get your vocabulary rapidly moving in an upward direction, I guarantee it. __________________________________________________________________________________ ^M Free your mind!	[reply]
Re: functional functions by welchavw (Pilgrim) on May 30, 2007 at 18:53 UTC
Only 64...kinda reminds me of RISC vs CISC (how many addressing modes does PHP need, anyway? ;)). It is profoundly strange, of course, to consider Perl RISC'ish in any way, though it makes sense with your subset of the language. Just my thoughts.	[reply]
Re^2: functional functions by kosmo (Novice) on May 31, 2007 at 13:23 UTC
Only 64...kinda reminds me of RISC vs CISC (how many addressing modes does PHP need, anyway? ;)). It is profoundly strange, of course, to consider Perl RISC'ish in any way, though it makes sense with your subset of the language. Just my thoughts. Except for the whole fact that there are few RISC architectures still widely used, in favor of the more bloated x86. Yet Perl is still one of the most popular languages around the globe... I don't think I even regularly use 64 Perl functions. Maybe 16 on a regular basis? Maybe 64 since I started Perl in the 7th grade, so 7 or 8 years. That averages to like 8 functions a year (yeah yeah, I know the math makes no sense). To be able to write so much that does so much with so little, I think thats a tribute to the power of Perl.	[reply]
216 functions (Oh, My!) by herby1620 (Monk) on May 30, 2007 at 21:38 UTC
Having built an interpretive language for a very specialized application, I found that many times I needed to implement a "function" in the base language. Most of the time these implementations of "functions" were to make things "easier" at the interpretive language level, some were "one-time" things that probably could have been done as some code that was interpreted. There were always trade-offs. Some were more apparent than others (doing it inside the interpreter was MUCH faster). Not knowing the mind set of $Larry, I assume that (at least in early iterations) the same thing took place, which yields the "More than one way" syndrome we all enjoy. So, to know all 200+ functions isn't the best use of ones time, but every once in a while, scanning a book might yield some insight. It all boils down to knowing that while it probably IS possible to implement a regular expression engine in Perl [without using regular expressions], the language has that "stuff" already there, and understanding this helps considerably.	[reply]
Re: functional functions by Akoya (Scribe) on May 31, 2007 at 17:08 UTC
Although I am new to the monastery, I am not new to Perl. I have been using Perl for nearly 10 years. Staggering, when I think about it! Especially considering how little I know compared to the many gurus in the community. Your post was very thought provoking, or rather, it provoked a self examination of my own knowledge of the language. Like you, there are many functions and features of the language that I have not learned. However, the one feature of Perl that makes it great is its flexibility. It is because of its flexibility that we all continually learn. Many of us tend to do very repetitive tasks in Perl. This tends to put blinders on us--we tread the familiar path, without looking for other directions. Every once in a while, we discover someone elses solution to the same or similar task. Inevitably, we learn something new, whether it is an introduction to a new function, or an enhanced understanding of a familiar one, or a technique resulting in an improved script. Don't judge yourself too harshly for the limit of your knowledge--be content with the knowlege of how productive you are with that knowlege. Be delighted that, despite your experience, and productivity, you have learned (and will continue to learn) something new! P.S., After having reviewing perlfunc, I have found that I use only about 35 functions on a regular basis ;) -- Akoya	[reply]