The Periodic table of Perl operators Posted Feb 17, 2009 15:17 UTC (Tue) by asamardzic (guest, #27161) [Link] (12 responses) Amazing... It came to me recently that Mathematica may fare well against Perl with regards to the number of so-called "special syntax" operators available, but after looking into this piece of art - I'd say no way anything (out of more widely used programming systems) could come even close to Perl here :-) The Periodic table of Perl operators Posted Feb 17, 2009 16:07 UTC (Tue) by donbarry (guest, #10485) [Link] (10 responses) You ain't seen nothing yet.. The "quick reference card" for J (a dialect of the grand old language APL, but using the ASCII character set instead of the special greek-laden APL character set) shows its unique look: http://www.jsoftware.com/jwiki/HenryRich?action=AttachFil... Note that a recursive factorial definition can be given in just a few characters: executing 1:`(]*$:@<:) @. * "0 i. 6 yields 1 1 2 6 24 120 Perl is positively verbose in comparison. The Periodic table of Perl operators Posted Feb 17, 2009 17:58 UTC (Tue) by joey (guest, #328) [Link] (8 responses) Haskell is also no slouch in the operators department. Even leaving aside that `func` can be used to turn any function into an infix operator. All the custom monadic operators are particularly "fun". The Periodic table of Perl operators Posted Feb 17, 2009 22:30 UTC (Tue) by eru (subscriber, #2753) [Link] (4 responses) I have always wondered about this enthusiasm in some languages to overload operator symbols. I think it is equivalent to promoting the use of one-letter function and variable names... The Periodic table of Perl operators Posted Feb 18, 2009 15:27 UTC (Wed) by jzbiciak (guest, #5246) [Link] (3 responses) Tell that to mathematicians. It seems like the further you go in mathematics, the fewer actual words there are and the more dense the symbology gets. Programming languages like APL seem to come straight from a higher-level mathematics textbook. If your target audience is mathematicians, then allowing them to write in their "native" language can be a plus, not a minus. It might leave the rest of us behind, though. Personally, I don't mind single-letter variable names and terse symbols if it doesn't get in the way of clarity. Naming your index variable "index" is overkill when "i" is widely understood to mean "index," and most programmers would have encountered that usage in their early teens in an algebra class. Again, a terse usage first encountered in mathematics, but in this case, widely enough encountered that we should all be familiar with it. The Periodic table of Perl operators Posted Feb 18, 2009 23:20 UTC (Wed) by donbarry (guest, #10485) [Link] Well in APL (and particularly in J) it's not "overloading", it's merely having a rich set of primitives, which can be combined in an extraordinary number of ways, and as in mathematics, few of these are anticipated directly by the authors. J in particular takes this further by building aspects of dynamic metaprogramming into the language -- functions can be composed, mapped across datasets, adjusted with adverbs which affect the rank of data decomposition into the functional maw, even composed into a "gerund" (a functional array) which can be indexed dynamically as it is mapped onto a dataset. Terse? yes. Unreadable? (can be, though putting one trick per line and commenting it gets around this). Powerful? Indescribably so. Unfortunately, the authors of most of these languages' implementations never fell into the free software movement. There are poor APL implementations (and one great implementation of a weakened but sped up APL, A+) and only the single proprietary (but free as beer) J interpreter. The Periodic table of Perl operators Posted Feb 19, 2009 8:00 UTC (Thu) by eru (subscriber, #2753) [Link] (1 responses) Tell that to mathematicians. I suspect the reason for their tradition is to make it easier to write mathematics by hand. Naming your index variable "index" is overkill when "i" is widely understood to mean "index, I believe the important consideration is locality, and the frequency of the identifier use. It is OK to give terse names to local temporary variables, but not to a global function, unless the function is very commonly used (like the standard library functions of C). Of course following convention matters also. Using "+" instead of asking the programmer to spell "plus" improves clarity, but not when you then allow the programmer to redefine "+" to mean something different. The Periodic table of Perl operators Posted Feb 19, 2009 15:57 UTC (Thu) by jzbiciak (guest, #5246) [Link] I guess Zipf's Law applies to some extent--some things are waaaay more common than others--and it's useful to provide a Huffman-like coding to make common things more efficient. That is, give common tokens compact representations, and uncommon tokens much more verbose representations. (This has the added benefit of introducing folks gently to stuff they may not see very often if the verbose representation is also self-explaining.) For example, one of the things I prefer about C over Pascal is that blocks begin and end with "{" and "}", where in Pascal it's the much more verbose "BEGIN" and "END" keywords. Their information content is low due to their high frequency, so their size should be small. Only early beginners need the concept of "beginning and ending of block" explained. In contrast, it's probably better to name the function "defenestrate_obfuscation()" verbosely, rather than as something compact like "defOb()", since it's unlikely to be encountered often, and the later is impenetrable. One of the things I don't like about some of the more recent programming traditions, such as iterators in C++, is that the code gets very verbose when expressing what ought to be very compact topics. Why spell the start of a list ".begin()" and the end of the list ".end()" if you're going to be using it regularly? It begs for something more compact. Perl 6 (we were talking about Perl 6, right?) has perhaps gone too far in this direction, though. We'll see. The Periodic table of Perl operators Posted Feb 18, 2009 10:16 UTC (Wed) by epa (subscriber, #39769) [Link] (2 responses) The cool thing about Haskell is that you can define your own operators with pretty much any punctuation characters you want. (I think Perl 6 will have the same but I'm not sure.) The Periodic table of Perl operators Posted Feb 19, 2009 0:00 UTC (Thu) by chromatic (guest, #26207) [Link] Perl 6 will have the same. (Rakudo doesn't support that just yet.) The Periodic table of Perl operators Posted Feb 19, 2009 2:50 UTC (Thu) by quotemstr (subscriber, #45331) [Link] Let's not forget LISP. Depending on how you look at it, either nothing is an operation, or everything is. :-) The Periodic table of Perl operators Posted Feb 21, 2009 13:36 UTC (Sat) by akulkis (guest, #56783) [Link] "Note that a recursive factorial definition can be given in just a few characters: executing 1:`(]*$:@<:) @. * "0 i. 6 yields 1 1 2 6 24 120" You write that as if you mistakenly believe that's a good thing. It's not. Read Wirth, and his comments on the unnamed language (obviously a reference to APL) and the cult of developing "one liner" source code which is properly spread across several lines of code (cf "German: A language which crams into one word what is properly stated in a sentance") Nor forget the line from the list of things "Real Programmers(tm)" don't do: Real Programmers don't program in APL because ANYBODY can be obscure in APL. J is nothing more than an even more obfuscated variant of APL. The Periodic table of Perl operators Posted Feb 18, 2009 10:15 UTC (Wed) by epa (subscriber, #39769) [Link] Do remember that this is for Perl 6, which is still in development and not ready for production use yet. Although Perl 5 is not exactly short of operators either... Wow! I am overwhelmed Posted Feb 18, 2009 12:49 UTC (Wed) by ctg (guest, #3459) [Link] I think a singularity has been reached; this is both completely whimsical and yet deeply useful. Sublime and ridiculous. How do you short-circuit XOR? Posted Feb 18, 2009 13:40 UTC (Wed) by Max.Hyre (subscriber, #1054) [Link] (3 responses) I've been away from Perl for a while (to put it kindly). Maybe it's a concept that's been floating around for a while, and I missed it. In column 23 there's a list operator ``xor'' which short circuits. What is the condition for short-circuiting XOR?? How do you short-circuit XOR? Posted Feb 19, 2009 5:24 UTC (Thu) by jimparis (guest, #38647) [Link] (1 responses) I know little about Perl 6, but I imagine that if you have lazy evaluation, then an implementation of xor like: if (not A) return B; if (not B) return A; return 0; would be short-circuiting because you might only have to evaluate one argument (assuming, again, that you have lazy eval. and returning B doesn't require evaluating B) How to short-circuit XOR; gotcha Posted Feb 19, 2009 16:42 UTC (Thu) by Max.Hyre (subscriber, #1054) [Link] Thanks, both you and im14u2c. Sure, short-circuiting logical xor is a snap. I, however, was thinking of bitwise xor, hence my confusion. How do you short-circuit XOR? Posted Feb 19, 2009 6:07 UTC (Thu) by jzbiciak (guest, #5246) [Link] I do believe it's a bug in the chart. This page shows the logical XOR operator (^^), but omits "(short circuit)" after it. My first guess is that it's equivalent to the C incantation: #define XOR(a,b) ((!!(a)) != (!!(b))) That is, the !!(a) and !!(b) coerce 'a' and 'b' to be boolean values, and then XOR returns "true" when they are unequal. And for the optimization freaks out there, I realize that you don't need the double-not in this case. You could write it as: #define XOR(a,b) ((!(a)) != (!(b))) So, all the lazy-eval hocus pocus aside, I don't think it's intended to be short-circuit at all. I think it's just meant to be a version of != that coerces its arguments to boolean predicates first. Or maybe I'm just projecting something I've wanted several times in C onto what I see in this Perl 6 description. :-) The Periodic table of Perl operators Posted Feb 18, 2009 23:11 UTC (Wed) by flewellyn (subscriber, #5047) [Link] (3 responses) GAH. And people say Lisp is horrible? That hurts my eyes right there! The Periodic table of Perl operators Posted Feb 19, 2009 2:04 UTC (Thu) by chromatic (guest, #26207) [Link] (2 responses) Some people complain about Lisp's homoiconicity making the language pretty and every program written in the language ugly. At least with Perl, any ugliness that people see isn't the result of homoiconicity. The Periodic table of Perl operators Posted Feb 19, 2009 3:05 UTC (Thu) by flewellyn (subscriber, #5047) [Link] (1 responses) Too much syntax in Perl. Too many punctuation marks. I would much rather have things spelled out. I know what "CALL-NEXT-METHOD" means a lot more easily than .* or something. The Periodic table of Perl operators Posted Feb 19, 2009 9:03 UTC (Thu) by chromatic (guest, #26207) [Link] I have the opposite preference. I like being able to see the structure of a program -- its parts of speech, if you will. The use of symbols such as sigils and non-word operators gives subtle cues. When I read Lisp or Scheme, I feel like I have to keep a mental stack of operations and their order of execution to understand what's happening. I'm not sure if there's any way to measure this, but I feel like such a language taxes my short term memory more heavily, where an operator- and symbol-rich language such as Perl draws from long term memory and clumping of symbols. (I'm sure experience and preference have great effect here too.)
Posted Feb 17, 2009 15:17 UTC (Tue) by asamardzic (guest, #27161) [Link] (12 responses)
The Periodic table of Perl operators Posted Feb 17, 2009 16:07 UTC (Tue) by donbarry (guest, #10485) [Link] (10 responses) You ain't seen nothing yet.. The "quick reference card" for J (a dialect of the grand old language APL, but using the ASCII character set instead of the special greek-laden APL character set) shows its unique look: http://www.jsoftware.com/jwiki/HenryRich?action=AttachFil... Note that a recursive factorial definition can be given in just a few characters: executing 1:`(]*$:@<:) @. * "0 i. 6 yields 1 1 2 6 24 120 Perl is positively verbose in comparison. The Periodic table of Perl operators Posted Feb 17, 2009 17:58 UTC (Tue) by joey (guest, #328) [Link] (8 responses) Haskell is also no slouch in the operators department. Even leaving aside that `func` can be used to turn any function into an infix operator. All the custom monadic operators are particularly "fun". The Periodic table of Perl operators Posted Feb 17, 2009 22:30 UTC (Tue) by eru (subscriber, #2753) [Link] (4 responses) I have always wondered about this enthusiasm in some languages to overload operator symbols. I think it is equivalent to promoting the use of one-letter function and variable names... The Periodic table of Perl operators Posted Feb 18, 2009 15:27 UTC (Wed) by jzbiciak (guest, #5246) [Link] (3 responses) Tell that to mathematicians. It seems like the further you go in mathematics, the fewer actual words there are and the more dense the symbology gets. Programming languages like APL seem to come straight from a higher-level mathematics textbook. If your target audience is mathematicians, then allowing them to write in their "native" language can be a plus, not a minus. It might leave the rest of us behind, though. Personally, I don't mind single-letter variable names and terse symbols if it doesn't get in the way of clarity. Naming your index variable "index" is overkill when "i" is widely understood to mean "index," and most programmers would have encountered that usage in their early teens in an algebra class. Again, a terse usage first encountered in mathematics, but in this case, widely enough encountered that we should all be familiar with it. The Periodic table of Perl operators Posted Feb 18, 2009 23:20 UTC (Wed) by donbarry (guest, #10485) [Link] Well in APL (and particularly in J) it's not "overloading", it's merely having a rich set of primitives, which can be combined in an extraordinary number of ways, and as in mathematics, few of these are anticipated directly by the authors. J in particular takes this further by building aspects of dynamic metaprogramming into the language -- functions can be composed, mapped across datasets, adjusted with adverbs which affect the rank of data decomposition into the functional maw, even composed into a "gerund" (a functional array) which can be indexed dynamically as it is mapped onto a dataset. Terse? yes. Unreadable? (can be, though putting one trick per line and commenting it gets around this). Powerful? Indescribably so. Unfortunately, the authors of most of these languages' implementations never fell into the free software movement. There are poor APL implementations (and one great implementation of a weakened but sped up APL, A+) and only the single proprietary (but free as beer) J interpreter. The Periodic table of Perl operators Posted Feb 19, 2009 8:00 UTC (Thu) by eru (subscriber, #2753) [Link] (1 responses) Tell that to mathematicians. I suspect the reason for their tradition is to make it easier to write mathematics by hand. Naming your index variable "index" is overkill when "i" is widely understood to mean "index, I believe the important consideration is locality, and the frequency of the identifier use. It is OK to give terse names to local temporary variables, but not to a global function, unless the function is very commonly used (like the standard library functions of C). Of course following convention matters also. Using "+" instead of asking the programmer to spell "plus" improves clarity, but not when you then allow the programmer to redefine "+" to mean something different. The Periodic table of Perl operators Posted Feb 19, 2009 15:57 UTC (Thu) by jzbiciak (guest, #5246) [Link] I guess Zipf's Law applies to some extent--some things are waaaay more common than others--and it's useful to provide a Huffman-like coding to make common things more efficient. That is, give common tokens compact representations, and uncommon tokens much more verbose representations. (This has the added benefit of introducing folks gently to stuff they may not see very often if the verbose representation is also self-explaining.) For example, one of the things I prefer about C over Pascal is that blocks begin and end with "{" and "}", where in Pascal it's the much more verbose "BEGIN" and "END" keywords. Their information content is low due to their high frequency, so their size should be small. Only early beginners need the concept of "beginning and ending of block" explained. In contrast, it's probably better to name the function "defenestrate_obfuscation()" verbosely, rather than as something compact like "defOb()", since it's unlikely to be encountered often, and the later is impenetrable. One of the things I don't like about some of the more recent programming traditions, such as iterators in C++, is that the code gets very verbose when expressing what ought to be very compact topics. Why spell the start of a list ".begin()" and the end of the list ".end()" if you're going to be using it regularly? It begs for something more compact. Perl 6 (we were talking about Perl 6, right?) has perhaps gone too far in this direction, though. We'll see. The Periodic table of Perl operators Posted Feb 18, 2009 10:16 UTC (Wed) by epa (subscriber, #39769) [Link] (2 responses) The cool thing about Haskell is that you can define your own operators with pretty much any punctuation characters you want. (I think Perl 6 will have the same but I'm not sure.) The Periodic table of Perl operators Posted Feb 19, 2009 0:00 UTC (Thu) by chromatic (guest, #26207) [Link] Perl 6 will have the same. (Rakudo doesn't support that just yet.) The Periodic table of Perl operators Posted Feb 19, 2009 2:50 UTC (Thu) by quotemstr (subscriber, #45331) [Link] Let's not forget LISP. Depending on how you look at it, either nothing is an operation, or everything is. :-) The Periodic table of Perl operators Posted Feb 21, 2009 13:36 UTC (Sat) by akulkis (guest, #56783) [Link] "Note that a recursive factorial definition can be given in just a few characters: executing 1:`(]*$:@<:) @. * "0 i. 6 yields 1 1 2 6 24 120" You write that as if you mistakenly believe that's a good thing. It's not. Read Wirth, and his comments on the unnamed language (obviously a reference to APL) and the cult of developing "one liner" source code which is properly spread across several lines of code (cf "German: A language which crams into one word what is properly stated in a sentance") Nor forget the line from the list of things "Real Programmers(tm)" don't do: Real Programmers don't program in APL because ANYBODY can be obscure in APL. J is nothing more than an even more obfuscated variant of APL. The Periodic table of Perl operators Posted Feb 18, 2009 10:15 UTC (Wed) by epa (subscriber, #39769) [Link] Do remember that this is for Perl 6, which is still in development and not ready for production use yet. Although Perl 5 is not exactly short of operators either...
Posted Feb 17, 2009 16:07 UTC (Tue) by donbarry (guest, #10485) [Link] (10 responses)
Note that a recursive factorial definition can be given in just a few characters:
executing 1:`(]*$:@<:) @. * "0 i. 6 yields 1 1 2 6 24 120
Perl is positively verbose in comparison.
The Periodic table of Perl operators Posted Feb 17, 2009 17:58 UTC (Tue) by joey (guest, #328) [Link] (8 responses) Haskell is also no slouch in the operators department. Even leaving aside that `func` can be used to turn any function into an infix operator. All the custom monadic operators are particularly "fun". The Periodic table of Perl operators Posted Feb 17, 2009 22:30 UTC (Tue) by eru (subscriber, #2753) [Link] (4 responses) I have always wondered about this enthusiasm in some languages to overload operator symbols. I think it is equivalent to promoting the use of one-letter function and variable names... The Periodic table of Perl operators Posted Feb 18, 2009 15:27 UTC (Wed) by jzbiciak (guest, #5246) [Link] (3 responses) Tell that to mathematicians. It seems like the further you go in mathematics, the fewer actual words there are and the more dense the symbology gets. Programming languages like APL seem to come straight from a higher-level mathematics textbook. If your target audience is mathematicians, then allowing them to write in their "native" language can be a plus, not a minus. It might leave the rest of us behind, though. Personally, I don't mind single-letter variable names and terse symbols if it doesn't get in the way of clarity. Naming your index variable "index" is overkill when "i" is widely understood to mean "index," and most programmers would have encountered that usage in their early teens in an algebra class. Again, a terse usage first encountered in mathematics, but in this case, widely enough encountered that we should all be familiar with it. The Periodic table of Perl operators Posted Feb 18, 2009 23:20 UTC (Wed) by donbarry (guest, #10485) [Link] Well in APL (and particularly in J) it's not "overloading", it's merely having a rich set of primitives, which can be combined in an extraordinary number of ways, and as in mathematics, few of these are anticipated directly by the authors. J in particular takes this further by building aspects of dynamic metaprogramming into the language -- functions can be composed, mapped across datasets, adjusted with adverbs which affect the rank of data decomposition into the functional maw, even composed into a "gerund" (a functional array) which can be indexed dynamically as it is mapped onto a dataset. Terse? yes. Unreadable? (can be, though putting one trick per line and commenting it gets around this). Powerful? Indescribably so. Unfortunately, the authors of most of these languages' implementations never fell into the free software movement. There are poor APL implementations (and one great implementation of a weakened but sped up APL, A+) and only the single proprietary (but free as beer) J interpreter. The Periodic table of Perl operators Posted Feb 19, 2009 8:00 UTC (Thu) by eru (subscriber, #2753) [Link] (1 responses) Tell that to mathematicians. I suspect the reason for their tradition is to make it easier to write mathematics by hand. Naming your index variable "index" is overkill when "i" is widely understood to mean "index, I believe the important consideration is locality, and the frequency of the identifier use. It is OK to give terse names to local temporary variables, but not to a global function, unless the function is very commonly used (like the standard library functions of C). Of course following convention matters also. Using "+" instead of asking the programmer to spell "plus" improves clarity, but not when you then allow the programmer to redefine "+" to mean something different. The Periodic table of Perl operators Posted Feb 19, 2009 15:57 UTC (Thu) by jzbiciak (guest, #5246) [Link] I guess Zipf's Law applies to some extent--some things are waaaay more common than others--and it's useful to provide a Huffman-like coding to make common things more efficient. That is, give common tokens compact representations, and uncommon tokens much more verbose representations. (This has the added benefit of introducing folks gently to stuff they may not see very often if the verbose representation is also self-explaining.) For example, one of the things I prefer about C over Pascal is that blocks begin and end with "{" and "}", where in Pascal it's the much more verbose "BEGIN" and "END" keywords. Their information content is low due to their high frequency, so their size should be small. Only early beginners need the concept of "beginning and ending of block" explained. In contrast, it's probably better to name the function "defenestrate_obfuscation()" verbosely, rather than as something compact like "defOb()", since it's unlikely to be encountered often, and the later is impenetrable. One of the things I don't like about some of the more recent programming traditions, such as iterators in C++, is that the code gets very verbose when expressing what ought to be very compact topics. Why spell the start of a list ".begin()" and the end of the list ".end()" if you're going to be using it regularly? It begs for something more compact. Perl 6 (we were talking about Perl 6, right?) has perhaps gone too far in this direction, though. We'll see. The Periodic table of Perl operators Posted Feb 18, 2009 10:16 UTC (Wed) by epa (subscriber, #39769) [Link] (2 responses) The cool thing about Haskell is that you can define your own operators with pretty much any punctuation characters you want. (I think Perl 6 will have the same but I'm not sure.) The Periodic table of Perl operators Posted Feb 19, 2009 0:00 UTC (Thu) by chromatic (guest, #26207) [Link] Perl 6 will have the same. (Rakudo doesn't support that just yet.) The Periodic table of Perl operators Posted Feb 19, 2009 2:50 UTC (Thu) by quotemstr (subscriber, #45331) [Link] Let's not forget LISP. Depending on how you look at it, either nothing is an operation, or everything is. :-) The Periodic table of Perl operators Posted Feb 21, 2009 13:36 UTC (Sat) by akulkis (guest, #56783) [Link] "Note that a recursive factorial definition can be given in just a few characters: executing 1:`(]*$:@<:) @. * "0 i. 6 yields 1 1 2 6 24 120" You write that as if you mistakenly believe that's a good thing. It's not. Read Wirth, and his comments on the unnamed language (obviously a reference to APL) and the cult of developing "one liner" source code which is properly spread across several lines of code (cf "German: A language which crams into one word what is properly stated in a sentance") Nor forget the line from the list of things "Real Programmers(tm)" don't do: Real Programmers don't program in APL because ANYBODY can be obscure in APL. J is nothing more than an even more obfuscated variant of APL.
Posted Feb 17, 2009 17:58 UTC (Tue) by joey (guest, #328) [Link] (8 responses)
The Periodic table of Perl operators Posted Feb 17, 2009 22:30 UTC (Tue) by eru (subscriber, #2753) [Link] (4 responses) I have always wondered about this enthusiasm in some languages to overload operator symbols. I think it is equivalent to promoting the use of one-letter function and variable names... The Periodic table of Perl operators Posted Feb 18, 2009 15:27 UTC (Wed) by jzbiciak (guest, #5246) [Link] (3 responses) Tell that to mathematicians. It seems like the further you go in mathematics, the fewer actual words there are and the more dense the symbology gets. Programming languages like APL seem to come straight from a higher-level mathematics textbook. If your target audience is mathematicians, then allowing them to write in their "native" language can be a plus, not a minus. It might leave the rest of us behind, though. Personally, I don't mind single-letter variable names and terse symbols if it doesn't get in the way of clarity. Naming your index variable "index" is overkill when "i" is widely understood to mean "index," and most programmers would have encountered that usage in their early teens in an algebra class. Again, a terse usage first encountered in mathematics, but in this case, widely enough encountered that we should all be familiar with it. The Periodic table of Perl operators Posted Feb 18, 2009 23:20 UTC (Wed) by donbarry (guest, #10485) [Link] Well in APL (and particularly in J) it's not "overloading", it's merely having a rich set of primitives, which can be combined in an extraordinary number of ways, and as in mathematics, few of these are anticipated directly by the authors. J in particular takes this further by building aspects of dynamic metaprogramming into the language -- functions can be composed, mapped across datasets, adjusted with adverbs which affect the rank of data decomposition into the functional maw, even composed into a "gerund" (a functional array) which can be indexed dynamically as it is mapped onto a dataset. Terse? yes. Unreadable? (can be, though putting one trick per line and commenting it gets around this). Powerful? Indescribably so. Unfortunately, the authors of most of these languages' implementations never fell into the free software movement. There are poor APL implementations (and one great implementation of a weakened but sped up APL, A+) and only the single proprietary (but free as beer) J interpreter. The Periodic table of Perl operators Posted Feb 19, 2009 8:00 UTC (Thu) by eru (subscriber, #2753) [Link] (1 responses) Tell that to mathematicians. I suspect the reason for their tradition is to make it easier to write mathematics by hand. Naming your index variable "index" is overkill when "i" is widely understood to mean "index, I believe the important consideration is locality, and the frequency of the identifier use. It is OK to give terse names to local temporary variables, but not to a global function, unless the function is very commonly used (like the standard library functions of C). Of course following convention matters also. Using "+" instead of asking the programmer to spell "plus" improves clarity, but not when you then allow the programmer to redefine "+" to mean something different. The Periodic table of Perl operators Posted Feb 19, 2009 15:57 UTC (Thu) by jzbiciak (guest, #5246) [Link] I guess Zipf's Law applies to some extent--some things are waaaay more common than others--and it's useful to provide a Huffman-like coding to make common things more efficient. That is, give common tokens compact representations, and uncommon tokens much more verbose representations. (This has the added benefit of introducing folks gently to stuff they may not see very often if the verbose representation is also self-explaining.) For example, one of the things I prefer about C over Pascal is that blocks begin and end with "{" and "}", where in Pascal it's the much more verbose "BEGIN" and "END" keywords. Their information content is low due to their high frequency, so their size should be small. Only early beginners need the concept of "beginning and ending of block" explained. In contrast, it's probably better to name the function "defenestrate_obfuscation()" verbosely, rather than as something compact like "defOb()", since it's unlikely to be encountered often, and the later is impenetrable. One of the things I don't like about some of the more recent programming traditions, such as iterators in C++, is that the code gets very verbose when expressing what ought to be very compact topics. Why spell the start of a list ".begin()" and the end of the list ".end()" if you're going to be using it regularly? It begs for something more compact. Perl 6 (we were talking about Perl 6, right?) has perhaps gone too far in this direction, though. We'll see. The Periodic table of Perl operators Posted Feb 18, 2009 10:16 UTC (Wed) by epa (subscriber, #39769) [Link] (2 responses) The cool thing about Haskell is that you can define your own operators with pretty much any punctuation characters you want. (I think Perl 6 will have the same but I'm not sure.) The Periodic table of Perl operators Posted Feb 19, 2009 0:00 UTC (Thu) by chromatic (guest, #26207) [Link] Perl 6 will have the same. (Rakudo doesn't support that just yet.) The Periodic table of Perl operators Posted Feb 19, 2009 2:50 UTC (Thu) by quotemstr (subscriber, #45331) [Link] Let's not forget LISP. Depending on how you look at it, either nothing is an operation, or everything is. :-)
Posted Feb 17, 2009 22:30 UTC (Tue) by eru (subscriber, #2753) [Link] (4 responses)
The Periodic table of Perl operators Posted Feb 18, 2009 15:27 UTC (Wed) by jzbiciak (guest, #5246) [Link] (3 responses) Tell that to mathematicians. It seems like the further you go in mathematics, the fewer actual words there are and the more dense the symbology gets. Programming languages like APL seem to come straight from a higher-level mathematics textbook. If your target audience is mathematicians, then allowing them to write in their "native" language can be a plus, not a minus. It might leave the rest of us behind, though. Personally, I don't mind single-letter variable names and terse symbols if it doesn't get in the way of clarity. Naming your index variable "index" is overkill when "i" is widely understood to mean "index," and most programmers would have encountered that usage in their early teens in an algebra class. Again, a terse usage first encountered in mathematics, but in this case, widely enough encountered that we should all be familiar with it. The Periodic table of Perl operators Posted Feb 18, 2009 23:20 UTC (Wed) by donbarry (guest, #10485) [Link] Well in APL (and particularly in J) it's not "overloading", it's merely having a rich set of primitives, which can be combined in an extraordinary number of ways, and as in mathematics, few of these are anticipated directly by the authors. J in particular takes this further by building aspects of dynamic metaprogramming into the language -- functions can be composed, mapped across datasets, adjusted with adverbs which affect the rank of data decomposition into the functional maw, even composed into a "gerund" (a functional array) which can be indexed dynamically as it is mapped onto a dataset. Terse? yes. Unreadable? (can be, though putting one trick per line and commenting it gets around this). Powerful? Indescribably so. Unfortunately, the authors of most of these languages' implementations never fell into the free software movement. There are poor APL implementations (and one great implementation of a weakened but sped up APL, A+) and only the single proprietary (but free as beer) J interpreter. The Periodic table of Perl operators Posted Feb 19, 2009 8:00 UTC (Thu) by eru (subscriber, #2753) [Link] (1 responses) Tell that to mathematicians. I suspect the reason for their tradition is to make it easier to write mathematics by hand. Naming your index variable "index" is overkill when "i" is widely understood to mean "index, I believe the important consideration is locality, and the frequency of the identifier use. It is OK to give terse names to local temporary variables, but not to a global function, unless the function is very commonly used (like the standard library functions of C). Of course following convention matters also. Using "+" instead of asking the programmer to spell "plus" improves clarity, but not when you then allow the programmer to redefine "+" to mean something different. The Periodic table of Perl operators Posted Feb 19, 2009 15:57 UTC (Thu) by jzbiciak (guest, #5246) [Link] I guess Zipf's Law applies to some extent--some things are waaaay more common than others--and it's useful to provide a Huffman-like coding to make common things more efficient. That is, give common tokens compact representations, and uncommon tokens much more verbose representations. (This has the added benefit of introducing folks gently to stuff they may not see very often if the verbose representation is also self-explaining.) For example, one of the things I prefer about C over Pascal is that blocks begin and end with "{" and "}", where in Pascal it's the much more verbose "BEGIN" and "END" keywords. Their information content is low due to their high frequency, so their size should be small. Only early beginners need the concept of "beginning and ending of block" explained. In contrast, it's probably better to name the function "defenestrate_obfuscation()" verbosely, rather than as something compact like "defOb()", since it's unlikely to be encountered often, and the later is impenetrable. One of the things I don't like about some of the more recent programming traditions, such as iterators in C++, is that the code gets very verbose when expressing what ought to be very compact topics. Why spell the start of a list ".begin()" and the end of the list ".end()" if you're going to be using it regularly? It begs for something more compact. Perl 6 (we were talking about Perl 6, right?) has perhaps gone too far in this direction, though. We'll see.
Posted Feb 18, 2009 15:27 UTC (Wed) by jzbiciak (guest, #5246) [Link] (3 responses)
Tell that to mathematicians. It seems like the further you go in mathematics, the fewer actual words there are and the more dense the symbology gets. Programming languages like APL seem to come straight from a higher-level mathematics textbook. If your target audience is mathematicians, then allowing them to write in their "native" language can be a plus, not a minus. It might leave the rest of us behind, though.
Personally, I don't mind single-letter variable names and terse symbols if it doesn't get in the way of clarity. Naming your index variable "index" is overkill when "i" is widely understood to mean "index," and most programmers would have encountered that usage in their early teens in an algebra class. Again, a terse usage first encountered in mathematics, but in this case, widely enough encountered that we should all be familiar with it.
The Periodic table of Perl operators Posted Feb 18, 2009 23:20 UTC (Wed) by donbarry (guest, #10485) [Link] Well in APL (and particularly in J) it's not "overloading", it's merely having a rich set of primitives, which can be combined in an extraordinary number of ways, and as in mathematics, few of these are anticipated directly by the authors. J in particular takes this further by building aspects of dynamic metaprogramming into the language -- functions can be composed, mapped across datasets, adjusted with adverbs which affect the rank of data decomposition into the functional maw, even composed into a "gerund" (a functional array) which can be indexed dynamically as it is mapped onto a dataset. Terse? yes. Unreadable? (can be, though putting one trick per line and commenting it gets around this). Powerful? Indescribably so. Unfortunately, the authors of most of these languages' implementations never fell into the free software movement. There are poor APL implementations (and one great implementation of a weakened but sped up APL, A+) and only the single proprietary (but free as beer) J interpreter. The Periodic table of Perl operators Posted Feb 19, 2009 8:00 UTC (Thu) by eru (subscriber, #2753) [Link] (1 responses) Tell that to mathematicians. I suspect the reason for their tradition is to make it easier to write mathematics by hand. Naming your index variable "index" is overkill when "i" is widely understood to mean "index, I believe the important consideration is locality, and the frequency of the identifier use. It is OK to give terse names to local temporary variables, but not to a global function, unless the function is very commonly used (like the standard library functions of C). Of course following convention matters also. Using "+" instead of asking the programmer to spell "plus" improves clarity, but not when you then allow the programmer to redefine "+" to mean something different. The Periodic table of Perl operators Posted Feb 19, 2009 15:57 UTC (Thu) by jzbiciak (guest, #5246) [Link] I guess Zipf's Law applies to some extent--some things are waaaay more common than others--and it's useful to provide a Huffman-like coding to make common things more efficient. That is, give common tokens compact representations, and uncommon tokens much more verbose representations. (This has the added benefit of introducing folks gently to stuff they may not see very often if the verbose representation is also self-explaining.) For example, one of the things I prefer about C over Pascal is that blocks begin and end with "{" and "}", where in Pascal it's the much more verbose "BEGIN" and "END" keywords. Their information content is low due to their high frequency, so their size should be small. Only early beginners need the concept of "beginning and ending of block" explained. In contrast, it's probably better to name the function "defenestrate_obfuscation()" verbosely, rather than as something compact like "defOb()", since it's unlikely to be encountered often, and the later is impenetrable. One of the things I don't like about some of the more recent programming traditions, such as iterators in C++, is that the code gets very verbose when expressing what ought to be very compact topics. Why spell the start of a list ".begin()" and the end of the list ".end()" if you're going to be using it regularly? It begs for something more compact. Perl 6 (we were talking about Perl 6, right?) has perhaps gone too far in this direction, though. We'll see.
Posted Feb 18, 2009 23:20 UTC (Wed) by donbarry (guest, #10485) [Link]
Terse? yes. Unreadable? (can be, though putting one trick per line and commenting it gets around this). Powerful? Indescribably so.
Unfortunately, the authors of most of these languages' implementations never fell into the free software movement. There are poor APL implementations (and one great implementation of a weakened but sped up APL, A+) and only the single proprietary (but free as beer) J interpreter.
Posted Feb 19, 2009 8:00 UTC (Thu) by eru (subscriber, #2753) [Link] (1 responses)
I suspect the reason for their tradition is to make it easier to write mathematics by hand.
Naming your index variable "index" is overkill when "i" is widely understood to mean "index,
I believe the important consideration is locality, and the frequency of the identifier use. It is OK to give terse names to local temporary variables, but not to a global function, unless the function is very commonly used (like the standard library functions of C). Of course following convention matters also. Using "+" instead of asking the programmer to spell "plus" improves clarity, but not when you then allow the programmer to redefine "+" to mean something different.
The Periodic table of Perl operators Posted Feb 19, 2009 15:57 UTC (Thu) by jzbiciak (guest, #5246) [Link] I guess Zipf's Law applies to some extent--some things are waaaay more common than others--and it's useful to provide a Huffman-like coding to make common things more efficient. That is, give common tokens compact representations, and uncommon tokens much more verbose representations. (This has the added benefit of introducing folks gently to stuff they may not see very often if the verbose representation is also self-explaining.) For example, one of the things I prefer about C over Pascal is that blocks begin and end with "{" and "}", where in Pascal it's the much more verbose "BEGIN" and "END" keywords. Their information content is low due to their high frequency, so their size should be small. Only early beginners need the concept of "beginning and ending of block" explained. In contrast, it's probably better to name the function "defenestrate_obfuscation()" verbosely, rather than as something compact like "defOb()", since it's unlikely to be encountered often, and the later is impenetrable. One of the things I don't like about some of the more recent programming traditions, such as iterators in C++, is that the code gets very verbose when expressing what ought to be very compact topics. Why spell the start of a list ".begin()" and the end of the list ".end()" if you're going to be using it regularly? It begs for something more compact. Perl 6 (we were talking about Perl 6, right?) has perhaps gone too far in this direction, though. We'll see.
Posted Feb 19, 2009 15:57 UTC (Thu) by jzbiciak (guest, #5246) [Link]
I guess Zipf's Law applies to some extent--some things are waaaay more common than others--and it's useful to provide a Huffman-like coding to make common things more efficient. That is, give common tokens compact representations, and uncommon tokens much more verbose representations. (This has the added benefit of introducing folks gently to stuff they may not see very often if the verbose representation is also self-explaining.)
For example, one of the things I prefer about C over Pascal is that blocks begin and end with "{" and "}", where in Pascal it's the much more verbose "BEGIN" and "END" keywords. Their information content is low due to their high frequency, so their size should be small. Only early beginners need the concept of "beginning and ending of block" explained. In contrast, it's probably better to name the function "defenestrate_obfuscation()" verbosely, rather than as something compact like "defOb()", since it's unlikely to be encountered often, and the later is impenetrable.
One of the things I don't like about some of the more recent programming traditions, such as iterators in C++, is that the code gets very verbose when expressing what ought to be very compact topics. Why spell the start of a list ".begin()" and the end of the list ".end()" if you're going to be using it regularly? It begs for something more compact.
Perl 6 (we were talking about Perl 6, right?) has perhaps gone too far in this direction, though. We'll see.
Posted Feb 18, 2009 10:16 UTC (Wed) by epa (subscriber, #39769) [Link] (2 responses)
The Periodic table of Perl operators Posted Feb 19, 2009 0:00 UTC (Thu) by chromatic (guest, #26207) [Link] Perl 6 will have the same. (Rakudo doesn't support that just yet.) The Periodic table of Perl operators Posted Feb 19, 2009 2:50 UTC (Thu) by quotemstr (subscriber, #45331) [Link] Let's not forget LISP. Depending on how you look at it, either nothing is an operation, or everything is. :-)
Posted Feb 19, 2009 0:00 UTC (Thu) by chromatic (guest, #26207) [Link]
Posted Feb 19, 2009 2:50 UTC (Thu) by quotemstr (subscriber, #45331) [Link]
Posted Feb 21, 2009 13:36 UTC (Sat) by akulkis (guest, #56783) [Link]
You write that as if you mistakenly believe that's a good thing. It's not.
Read Wirth, and his comments on the unnamed language (obviously a reference to APL) and the cult of developing "one liner" source code which is properly spread across several lines of code (cf "German: A language which crams into one word what is properly stated in a sentance")
Nor forget the line from the list of things "Real Programmers(tm)" don't do:
Real Programmers don't program in APL because ANYBODY can be obscure in APL.
J is nothing more than an even more obfuscated variant of APL.
Posted Feb 18, 2009 10:15 UTC (Wed) by epa (subscriber, #39769) [Link]
Posted Feb 18, 2009 12:49 UTC (Wed) by ctg (guest, #3459) [Link]
Posted Feb 18, 2009 13:40 UTC (Wed) by Max.Hyre (subscriber, #1054) [Link] (3 responses)
In column 23 there's a list operator ``xor'' which short circuits. What is the condition for short-circuiting XOR??
How do you short-circuit XOR? Posted Feb 19, 2009 5:24 UTC (Thu) by jimparis (guest, #38647) [Link] (1 responses) I know little about Perl 6, but I imagine that if you have lazy evaluation, then an implementation of xor like: if (not A) return B; if (not B) return A; return 0; would be short-circuiting because you might only have to evaluate one argument (assuming, again, that you have lazy eval. and returning B doesn't require evaluating B) How to short-circuit XOR; gotcha Posted Feb 19, 2009 16:42 UTC (Thu) by Max.Hyre (subscriber, #1054) [Link] Thanks, both you and im14u2c. Sure, short-circuiting logical xor is a snap. I, however, was thinking of bitwise xor, hence my confusion. How do you short-circuit XOR? Posted Feb 19, 2009 6:07 UTC (Thu) by jzbiciak (guest, #5246) [Link] I do believe it's a bug in the chart. This page shows the logical XOR operator (^^), but omits "(short circuit)" after it. My first guess is that it's equivalent to the C incantation: #define XOR(a,b) ((!!(a)) != (!!(b))) That is, the !!(a) and !!(b) coerce 'a' and 'b' to be boolean values, and then XOR returns "true" when they are unequal. And for the optimization freaks out there, I realize that you don't need the double-not in this case. You could write it as: #define XOR(a,b) ((!(a)) != (!(b))) So, all the lazy-eval hocus pocus aside, I don't think it's intended to be short-circuit at all. I think it's just meant to be a version of != that coerces its arguments to boolean predicates first. Or maybe I'm just projecting something I've wanted several times in C onto what I see in this Perl 6 description. :-)
Posted Feb 19, 2009 5:24 UTC (Thu) by jimparis (guest, #38647) [Link] (1 responses)
How to short-circuit XOR; gotcha Posted Feb 19, 2009 16:42 UTC (Thu) by Max.Hyre (subscriber, #1054) [Link] Thanks, both you and im14u2c. Sure, short-circuiting logical xor is a snap. I, however, was thinking of bitwise xor, hence my confusion.
Posted Feb 19, 2009 16:42 UTC (Thu) by Max.Hyre (subscriber, #1054) [Link]
I, however, was thinking of bitwise xor, hence my confusion.
Posted Feb 19, 2009 6:07 UTC (Thu) by jzbiciak (guest, #5246) [Link]
I do believe it's a bug in the chart. This page shows the logical XOR operator (^^), but omits "(short circuit)" after it.
My first guess is that it's equivalent to the C incantation:
#define XOR(a,b) ((!!(a)) != (!!(b)))
That is, the !!(a) and !!(b) coerce 'a' and 'b' to be boolean values, and then XOR returns "true" when they are unequal.
And for the optimization freaks out there, I realize that you don't need the double-not in this case. You could write it as:
#define XOR(a,b) ((!(a)) != (!(b)))
So, all the lazy-eval hocus pocus aside, I don't think it's intended to be short-circuit at all. I think it's just meant to be a version of != that coerces its arguments to boolean predicates first.
Or maybe I'm just projecting something I've wanted several times in C onto what I see in this Perl 6 description. :-)
Posted Feb 18, 2009 23:11 UTC (Wed) by flewellyn (subscriber, #5047) [Link] (3 responses)
The Periodic table of Perl operators Posted Feb 19, 2009 2:04 UTC (Thu) by chromatic (guest, #26207) [Link] (2 responses) Some people complain about Lisp's homoiconicity making the language pretty and every program written in the language ugly. At least with Perl, any ugliness that people see isn't the result of homoiconicity. The Periodic table of Perl operators Posted Feb 19, 2009 3:05 UTC (Thu) by flewellyn (subscriber, #5047) [Link] (1 responses) Too much syntax in Perl. Too many punctuation marks. I would much rather have things spelled out. I know what "CALL-NEXT-METHOD" means a lot more easily than .* or something. The Periodic table of Perl operators Posted Feb 19, 2009 9:03 UTC (Thu) by chromatic (guest, #26207) [Link] I have the opposite preference. I like being able to see the structure of a program -- its parts of speech, if you will. The use of symbols such as sigils and non-word operators gives subtle cues. When I read Lisp or Scheme, I feel like I have to keep a mental stack of operations and their order of execution to understand what's happening. I'm not sure if there's any way to measure this, but I feel like such a language taxes my short term memory more heavily, where an operator- and symbol-rich language such as Perl draws from long term memory and clumping of symbols. (I'm sure experience and preference have great effect here too.)
Posted Feb 19, 2009 2:04 UTC (Thu) by chromatic (guest, #26207) [Link] (2 responses)
The Periodic table of Perl operators Posted Feb 19, 2009 3:05 UTC (Thu) by flewellyn (subscriber, #5047) [Link] (1 responses) Too much syntax in Perl. Too many punctuation marks. I would much rather have things spelled out. I know what "CALL-NEXT-METHOD" means a lot more easily than .* or something. The Periodic table of Perl operators Posted Feb 19, 2009 9:03 UTC (Thu) by chromatic (guest, #26207) [Link] I have the opposite preference. I like being able to see the structure of a program -- its parts of speech, if you will. The use of symbols such as sigils and non-word operators gives subtle cues. When I read Lisp or Scheme, I feel like I have to keep a mental stack of operations and their order of execution to understand what's happening. I'm not sure if there's any way to measure this, but I feel like such a language taxes my short term memory more heavily, where an operator- and symbol-rich language such as Perl draws from long term memory and clumping of symbols. (I'm sure experience and preference have great effect here too.)
Posted Feb 19, 2009 3:05 UTC (Thu) by flewellyn (subscriber, #5047) [Link] (1 responses)
I would much rather have things spelled out. I know what "CALL-NEXT-METHOD" means a lot more easily than .* or something.
The Periodic table of Perl operators Posted Feb 19, 2009 9:03 UTC (Thu) by chromatic (guest, #26207) [Link] I have the opposite preference. I like being able to see the structure of a program -- its parts of speech, if you will. The use of symbols such as sigils and non-word operators gives subtle cues. When I read Lisp or Scheme, I feel like I have to keep a mental stack of operations and their order of execution to understand what's happening. I'm not sure if there's any way to measure this, but I feel like such a language taxes my short term memory more heavily, where an operator- and symbol-rich language such as Perl draws from long term memory and clumping of symbols. (I'm sure experience and preference have great effect here too.)
Posted Feb 19, 2009 9:03 UTC (Thu) by chromatic (guest, #26207) [Link]
I'm not sure if there's any way to measure this, but I feel like such a language taxes my short term memory more heavily, where an operator- and symbol-rich language such as Perl draws from long term memory and clumping of symbols. (I'm sure experience and preference have great effect here too.)
Copyright © 2009, Eklektix, Inc. Comments and public postings are copyrighted by their creators. Linux is a registered trademark of Linus Torvalds
LWN