Do you develop on GitHub? You can keep using GitHub but automatically sync your GitHub releases to SourceForge quickly and easily with this tool so your projects have a backup location, and get your project in front of SourceForge's nearly 20 million monthly users. It takes less than a minute. Get new users downloading your project releases today!
Posted
by
michael
from the book-of-revelations dept.
rob_99 writes: "The third installment of the Apocalypse is out!" You may have missed the first or second Apocalypses. This one is roughly "all about operators".
This discussion has been archived.
No new comments can be posted.
What's funny is first, he overuses the $ sign like mad, and perl is so well known to be unreadable. I bet you're just bitter because you don't understand it.
Why don't you go read one of the numerous "learning perl" pages and come back when you understand the subject your talking about.
OT: Did you guys see the online petition to fire Jon Katz [petitiononline.com]? Somebody has brass.... Wow... 22 names! I guess you showed them!
I'd sugest if you care so much about katz you go disable him in your prefs. The option is there, you just need an account. Seems like you'd have an account since you care so much about/. you are making petitions about it, but whatever....
What the HELL is wrong with Katz? I'm so fucking tired of people bashing Katz even though they are probably only stinky didn't wash since 3weeks Diablo2 addicts who read slashdot between two 48hours non-stop games.
If you don't like it, DON'T FUCKING READ IT DAMNIT.
Trust me, if I wrote a nice readable program in all three languages, theres no doubt that it would look nice in the OO languages than perl (especially if I used OO in perl, which BLOWS).
It would look nicest in VB! Not much of a way to judge languages.
What's funny is first, he overuses the $ sign like mad, and perl is so well known to be unreadable.
I bet you're just bitter because you don't understand it.
Wow, touchy much, kilgore? In point of fact, when I read Larry's comment about functional languages overusing parentheses and OO languages overusing . I immediately thought, "Nu? So in Perl 6 we won't have to use $ in front of EVERY SINGLE VARIABLE?"
And as to perl's infamous illegibility, it's true that the code's readability has a lot to do with the author and only a bit to do with the language. But I'll tell you right now that most of the perl fanatics I've met and all of the perl coders with whom I've worked came to the language from little or no programming experience. This means that nearly all the code I (and they) encountered was written by someone who had, at the time of authorship, only the vaguest of notions about legibility.
Remember, dude, just because you like a particular thing doesn't mean it doesn't have flaws.
Most of the Perl coders you have experienced might have been bad, but that says nothing about whether Perl is good or bad. If whatever language you prefer suddenly gets an influx of really poor programmers, will you switch?
Perl makes it really easy to write hard to read code, and many of the people who love perl enjoy doing that - it's also that many fewer keystrokes. You CAN write clear, concise, well documented code in perl. It's not any harder than in C. As for all the $'s (I assume you know that the $ only goes in front of scalars, not arrays or hashes), I found that I like having a single, non-alpha character telling me what type of variable somethign is that I now use the technique in other languages - $one lets me know right away that it's a string. And so on.
Generally, operator overloading is just syntatical sugar and is not strictly an OO language feature. Heck, Perl even supports it.
I think Java did well to leave it alone with the exception of String class, but that was one of those peer presure things. One could even deal without it in the Strings class.
Actually, not all functional languages use parentheses;
that's just Lisp & friends. In modern functional languages
like Haskell [haskell.org], you
end up using fewer parentheses (and other punctuation)
than in C, Python, or Perl.
For example, Haskell parses f 0 + f 1 as: f(0) + f(1) (In a less obvious way, it also parses f g x as f(g, x), but that's another story...)
I confess that I don't understand this prejudice people seem that have against parentheses. I use them constantly, often whether I need them or not, to clarify expression order. Maybe it's a habit I got into in high school math, when I could never remember if you added first or multiplied first.... but f(0) + f(1) is way more readable to me than f 0 + f 1. I've read a bit about Haskell, and it looks like a really nice language, but why this hatred against parentheses?
I think the reason is that in Lisp and its derivatives -- such as Scheme -- the parentheses are thought of as the application operator: apply the first form to the succeeding forms.
Also, it goes naturally with the idea that code (and data) are lists; everything is a list. To overly simplify, when a form is being evaluated you operate on data as lists. When a macro is being evaluated you operate on the code as lists. So Lisp gets to be its own macro language. This oftern verbose syntax gives the language enormous flexibility and reflectiveness; I cannot think of a more reflective languages than Common Lisp, especially since you can control most of the compilation process by modifying various built-in forms.
If you do not like the parentheses, you can modify the "read" form to accept data that is not in list notation.
Now, if only it had the beauty and consistency of APL, but that is one of Lisp's best traits; you can make it look and do anything even things that suck. In a way its beauty comes from be able to make it look so ugly.
Sure, being able to manipulate code as data is wonderful,
it's just not needed all the time. Also, the fact that you can
use other syntaxes, if you want to, does not mean much
(I know there are versions of Lisp with a C-like syntax; not many followers!)
This is the default syntax, 99% of the people
will use it, so 99% of other people's code will use it,
and 99% of the people won't like your code if you use
something else.
It's not easy at all... Particularly when some of the data structures we're teached in intro programming courses
don't work so well in this context (e.g. hashtables)
Hugs [haskell.org] is an easy to setup interpreter, ghc [haskell.org] is a good compiler, with an accompanying interpreter.haskell.org [haskell.org] is a good place to start.
Now another difference between Haskell and usual
programming is that it's lazy, meaning that expressions
are only evaluated only as needed to produce the result
(think the behavior of && in C, applied to the whole
language). This is a rather cool feature, but it makes wrapping your head around haskell even more difficult,
because it's not easy to tell how a Haskell
program executes.You can also try a more traditional
strict functional language like Ocaml, for size!
How long will it be before every possible program will be encoded into Perl's executable? Hmmm. Perl and Emacs, together at last! That's an intriguing idea - why not send a proposal to Wall & Stallman?:-)
"Breaking out of your culture is also important, because that is how we understand other cultures. As an explicitly multicultural language, Perl has generally done OK in this area, though we can always do better. Examples of cross-cultural exchange among computer cultures include XML and Unicode. (Not surprisingly, these features also enable better cross-cultural exchange among human cultures -- we sincerely hope.)"
It is for statements like this, that I am drawn into studying and using Perl. Many designers try to design a langauge which develops its own internal culture; it becomes static and internally consistent, but not very adventurous. Larry Wall seeks to develop a language which has built-in the fact that we like to explore, making his task more difficult, but a language which moves and flows with the evolution of our culture readily.
Larry Wall seeks to develop a language which has built-in the fact that we like to explore, making his task more difficult, but a language which moves and flows with the evolution of our culture readily.
On the contrary... what I think is the greatest advantage of Perl's flexibility is the fact that I can programm like I want. I don't want a language for exploring new ways of coding, I want it for creating code in the very particular way that satisfies me.
Well, gee... in what part of the world do we find camels? Makes perfect sense to me. OK, that's silly, but it almost had me too, because you tend to notice the title before the icon.
Perl gets around some of these problems by keeping track of whether it is expecting an operator or a term. As it happens, a unary operator is simply one that occurs when Perl is expecting a term. So Perl could keep track of a unary = operator, even if the human programmer might be confused.
This seems to be a seriously smart way to do sytax checking. Is this drawn from an existing implementation in a different language or is it a new development that he thought up?
Speaking from my own experience as a non-developer coder, I'd love to see more of this kind of "artificial" intelligence in programming languages. I really love the power of languages such as c/c++ but keeping track of every possible way I can fsk stuff up is just impossible. I definately think having more checks in place (within reasonable limits) would certainly make for better code all around.
Well, there's not really anything novel in what he's talking about. Almost all languages do the same thing. Consider these two expressions:
5 - 3
5 + - 3
The first "-" relates to subtraction. The second one relates to negating a number. Those are two different kinds of operations, and those are considered two different operators. You can tell the two apart, because in the first one when you encounter "-" you are looking to extend the expression; while in the second when you encounter "-" you are looking for a second term to go after "+".
You could do the same thing with "=", but that sort of thing can get confusing. Imagine an expression $x = =$y (quite different from $x == $y !)
...I'd love to see more of this kind of "artificial" intelligence in programming languages.
If you're interested in how computers can help bring languages together, check out BlueBox [dloo.org] -- they're writing "words" which define behavior, and are working on writing syntaxes/grammars for most common languages.
The cool part about this? You can write a program in Perl, feed it into BlueBox, and have it output your program in C++. Or Python. Or Shell script. Or ASM.
Even better is the reverse: feed EXPLORER.EXE in and have it spit out Perl! 'Course it won't be commented, but -- humans know how to comment, perhaps humans can teach computers how to comment?
To be topical: BlueBox could also help convert from Perl 5 to Perl 6 (and vice versa!), once both grammars have been written.
He stresses the importance of good huffman coding, then goes on to change the string concatenation operator "." to a three character sequence " _ "
...instead of:
$a . $b . $c
you'll say:
$a _ $b _ $c
String concatenation is such a commonly used perl feature that it deserves a single character operator. Discriminating between operators by the existence of white space before/after the character is an incredibly ugly kludge. Larry seems to admit it, too: This is to be construed as a feature
At least we don't have to use "+", like in JavaScript!
No, the results of this should rely on the type of the operands, as it does with numerical values in C and C++ and most C++ classes. Keep in mind that single quotes denote a character (really an 8-bit ASCII value), and double quotes indicate a string (usually zero-terminated):
'a' + 'b' = 'Ã'
(char and char results in another char by adding their ASCII values)
"a" + 'b' = "ab"
(string and char results in a string by concatenation)
'a' + "b" = "ab"
(char and string -- order does not matter, so see string and char above)
"a" + "b" = "ab"
(string and string results in a string by concatenation)
To summarize, if a string is involved, then the char(s) is (are) promoted up to string(s) and the result depends on concatenation. If all operands are chars, then no promotion occurs and they are added by ASCII value.
This is similar to the numerical addition rules of C, C++, and a number of similar languages. One simple example: If an int and a float are added, the int is promoted to be a float and the result is a float. If an int and an int are added, the result is an int and must by cast (either explicitly or implicitly) in order to be a float value.
I'm not too familiar with Perl, but this seems to be the most sensible behavior. If I'm missing something and there's a valid reason not to use an addition sign for concatenation, please reply and let me know.
Well, first of all, there are no "character quotes" in perl (unlike C). The single quote indicates no interpolation of the string, while double quotes indicates interpolation (think Bourne shell). You have to use ord (or unpack) to get the binary value of the first char of a string.
Strictly speaking, only two characters are required for the underscore operator in many cases, because disambiguation between the operator and a trailing underscore is more of an issue:
$c = $a _$b;
Should be ok, I guess. But not a good idiom.
Of course, this is based on my knowledge of Perl 5. I havn't been able to keep track of the proposed changes to Perl 6 - there is some very wierd stuff going on there. I suspect there will be a large learning curve to transition to it when it is finished and released.
No, the results of this should rely on the type of the operands, as it does with numerical values in C and C++ and most C++ classes.
They do, but the rather essential point that your missing is that in Perl both 1 and "1" are scalar -- they have the same type (in an obviously broader sense of the word). "1" + "1" produces "2" (or 2), as does 1 + "1", "1" + 1, and 1 + 1; and, as you might expect, "1" . "1" and 1 . 1 (note the whitespace) produces "11". Thus the need for distinct syntax, which is already present in the equality operators, where you have == vs eq, > vs gt, etc.
Keep in mind that single quotes denote a character (really an 8-bit ASCII value), and double quotes indicate a string (usually zero-terminated)
As has already been stated, single and double quoting controls variable interpolation in Perl; there are no character constants as such. And since we're playing lanaguage lawyer, (non-wide-)character constants in C are actually int's, and are not required to be ASCII (which only uses 7 bits, anyway), and strings are by definition null-terminated.
I'm not too familiar with Perl
Which begs the question of why you posted in the first place.
The problem (esp in Perl, but also Javascript and others) is that the context mostly determines whether a number is interpreted as a string or a real number.
The most obvious problems occur when concatenating numbers, like
$phonenumber = $areacode + $phonenumber;
In Javascript, I think you have to do something like
phonenumber = areacode + '' + $phonenumber
to make it understand that you want concatenation, not addition.
Perl currently makes good use of all the symbols
on the keyboard, even tilde and backtick. I always thought the dot was a very elegant way to represent concatenation. Still, I'd give it up for real perl structs:)
one of the nice things about the dot is that it's a single keystroke. the underscore may be a single character, but (at least on English) keyboards it requires two keystrokes.
of course perl has such extensive string interpolation and other capabilities that this doesn't strike me as a humongous problem.
I, too, hate the whitespace kludge, but then i've always put whitespace around my dots too because print $this . $that just seems more readable to me than print $this.$that, which looks disturbingly like some kind of slightly funky method call.
'He stresses the importance of good huffman coding, then goes on to change the string concatenation operator "." to a three character sequence " _ "'
Actually, I'd be surprised to see that stick around once Unicode support is rock-solid on the popular platforms. Larry mentions using non-ASCII operators, and I'm almost sure string concatenation will use one of these.
For my part, though, I actually like spaces around most binary operators, and wouldn't be upset to see it enforced in the language. That way, people would write unreadable code in my style of unreadable coding.;)
I'm looking forward to non-ASCII operators. I understand they were much loved on the Lisp machines, and much hated in APL. Different ways of handling things in the two languages, though, so it might be a contextual thing. It will be interesting to see how they are received after twenty years or so of disuse.
I never really thought about how valuable perl really is. I use it constantly. I use it based on the syntactic rules set fourth in the cammel book. I never considered evaluating changes to the language (well, not to any great degree anyway. While I find Larry Wall's series of articles interesting, I just can't get excited about changing the language in it's next incarnation. It works. It's an effective tool. That's good enough to me. I'm not saying don't change it, so much as in it's role as a tool I find it valuable, but when given the opportunity to provide feedback on how to change it I'm at a loss.
Now, I consider my job to be 'Intranet Systems Arhitect' as distinct from 'Programmer'. Perhaps that's why I can't get excited about changing a tool I've come to depend on in it's current form. Perhaps true programmers might find the prospect fascinating. perhaps you could liken it to the difference between an army officer and a gunsmith. While both make use of guns at various times, only the gunsmith is inclined to take the gun apart, examine it and make a better one.
Or perhaps I'm just not showing the proper community spirit, and I should dive in and offer my two cents on how to make the language better. Maybe I'm just lazy (then again, isn't that why perl is such a great language...)
In responding to the previous poster my first inclination was to defend my perl programming prowess but instead of descending into such a ridiculous debate of an issue that would only be of interest to my clients and myself, I'll just clarify my point which was more that I have never found anything that I wasn't able to do in perl more easily than I could have done in C and that I wasn't able to find any specific single item in Larry's article that would make my use of perl significantly more convenient or effective. That's not to say that I'm against making changes to perl. If it can be improved, so much the better.
Regardless of your opinion of perl, I find Larry's writings to be consistently insightful and although the humor os a bit corny, somewhat amusing.
How perl 6 will fare is another issue. The language is going to change radically - will developers follow Larry into perl 6, just use perl 5 compatibility mode, or move on altogether?
Does anyone see the irony in having a third Apocalypse, let alone a second:)
Not if you understand that apocalypse means 'revelation' (from the greek apokalypto, to reveal) and that the only reason its connoted with the end of the world is because of the similarly-titled last book of the bible...
Let's face it, perl is absolutely great for its original intention - fast, easy, write-and-forget scripting. But as I see the plans for Perl 6 [perl.org] unfold, one thought comes to my mind - Yuck. The language they propose is bloated and convoluted beyond words; it's clearly evident that Wall and his fellow "designers" are struggling vainly to make Perl "grow up" -- something that it has absolutely no need to do. There [sun.com] are [ioccc.org] other [python.org] languages [microsoft.com] out there to fill the other niches; languages which try to do everything [att.com] doom themselves to failure. Ambition kills.
Let's face it, perl is absolutely great for its original intention - fast, easy, write-and-forget scripting..... Wall and his fellow "designers" are struggling vainly to make Perl "grow up" -- something that it has absolutely no need to do.
Perl is already used by many people not just as fast, easy, write-and-forget scripting lanuguage. Java, Python are good languages but they don't have something that is missing in Perl. Perl have everything anyone needs to build complex web application for example(mod_perl, AxKit, HTML::Mason, etc).
Hey, I was just thinking yesterday that there really oughtta be something like ?= - though I was working with php at the time (which is slowly getting replaced with eperl).
There once was a hacker named Wall
To maintain his own scripts, his downfall
He released to the world
A wonder named Perl
You can write code, but never recall!
I've never heard of "The Apocalypse" before, and I'm sure it was a pretty good title for an article a month ago...
But today, when I see "Apocalypse 3" in a link from a previous story... I wasn't sure whether to click to read the story, or get up to check for mushroom clouds outside the window.
Apocalypse \A*poc"a*lypse\, n. [L. apocalypsis, Gr. ?, fr. ? to
uncover, to disclose; ? from + ? to cover, conceal: cf. F.
apocalypse.]
1. The revelation delivered to St. John, in the isle of
Patmos, near the close of the first century, forming the
last book of the New Testament.
2. Anything viewed as a revelation; a disclosure.
People get scared when they hear the word Apocalypse, but here I mean it in the good sense: a Revealing. An Apocalypse is supposed to reveal good news to good people. (And if it also happens to reveal bad news to bad people, so be it. Just don't be bad.)
I think it sounds annoying as heck, because I tend to use a lot of _ in my variable names. Things like $foo_bar are a lot more readable than $fooBar, imho-- and allows me to save caps for other purposes like constants and the occasional global.
I really dislike having a concatenation operator that's a valid identifier character. There's just no reason for it.
And I don't completely buy the excuse that we're running out of punctuation characters. If you're going to jumble some of them up and talk about the "Huffman" reason for picking multi-character operators for some and not for others: let's do a little more housecleaning. Get rid of the bit operators as punctuation characters and make them named operators. That frees up some punctuaction for something that's not used very often anyway.
BTW, if you're under the impression that they're used frequently try:
for i in `find/usr/local/lib/perl5 -name *.pm`; do if perl -wc $i >/dev/null 2> then perl -MO=Terse $i | grep 'bit_'; fi done >> bitops
Sure it doesn't pick up everyhing (late compilation), but in the 1056 files I have there I had exactly 7 occurances of bit operators. This does not impress me enough to use valuable punctuation.
Before I begin, I know that Perl is Larry's baby and he can do with it what he likes. But I wouldn't be so vocal about this if I didn't care.;-) That said...
Maybe it is just me, but the more and more I see what is going on in the perl world, the less and less I want to have anything do with it. The whole
hyper-operator conecpt is a good example. My thoughs? Just use a fscking for loop. That is what they were designed to do. Larry seems to be going through *great* pains to include as many bizzare syntactic short cuts as you can reasonably string characters on the keyboard to represent. This is not terribly innovative.
It's starting to diverge from "Practical extraction and report(ing) language"
and towards "pathetically Eclectic rubbish lister". Personally, I aim a little more towards practical. That was what made it so popular to begin with. Make difficult things easy and hard thing possible was a nice concept. Perl 5 did that well. IMNSHO, Perl 6 seems to be making 100 ways to do the same simple thing all so the developer can opt to use the method with the verbosity level he/she desire, and not making the hard things any easier.
Convenience. Certain problems are easier to express with a different paradigm (oo vs imperative vs functional, etc). Even concepts within a language class have benefit (e.g. polymorphisim and overloading in oo languages). What I see Larry spending a lot of his time on does nothing to change this. It just gives programmers multiple ways to say (a > 10 && a 20). I say BFD to that. Pick a reasonable syntax and go with it, unless there is a compelling reason to change (so far I haven't seen any reasons more compelling than I'm lazy, let me type it this way instead).
Well, hyperoperators seem to be a very convenient way to deal with operations on matrices and tables, no? Makes vector math much more succinct.
I will agree, alot of the proposed changes don't seem to have alot of immediate application to what I do personally, but I admit their utility.
But here's an idea in which we can both be happy: Don't use Perl 6. Continue on with 5. Considering the immense amount of v5 code, I doubt highly that it will all suddenly disappear. In fact, I recall from a previous Apocalypse that Larry mentioned the idea of allowing all existing Perl5 syntax, until you use a piece of new syntax.
Yeah, it's not the greatest of solutions. Perhaps what will happen will resemble C/C++, with many continuing to use the old for quite a while yet.
Why, then, does Perl include a 'foreach' operator when a 'for' loop will do just fine? Efficiency. By giving the language a hint as to what you are going to do, it can iterate through the list faster and with fewer resources. I expect that when the implementation arrives, we will find the hyper operators offer a not-insignificant efficiency gain over a simple for loop.
The point of Perl is not necessarily to provide more than one way to do things, but to make certain types of programming much easier than with other languages. There are things I do in Perl in an hour that would be a week undertaking in C or C++. If enough users are calling for these seemingly esoteric features, add them. The more expressive the language, the more useful.
The `foreach' keyword is actually a synonym for the `for' keyword, so you can use `foreach' for readability or `for' for brevity.
I do agree on your point though, you just choose a bad example and topic, since 'Efficiency' for perl *normally* means coding better and faster, not running faster.
Yes, I know you can use for as an abbreviation of foreach, but I was not referring such syntactic sugar. I was referring to the difference between the statement for(;;) and the foreach scalar, array.
For example:
for (my $j = 0; $j != @ary2; $j++) {
#do something with $ary2[$j]
}
and a foreach loop:
for my $jet (@ary2) {
#do something with $jet
}
The Perl Manual [perldoc.com] has this to say on the matter.
It's [foreach] cleaner, safer, and faster. It's cleaner because it's less noisy. It's safer because if code gets added between the inner and outer loops later on, the new code won't be accidentally executed. The next explicitly iterates the other loop rather than merely terminating the inner one. And it's faster because Perl executes a foreach statement more rapidly than it would the equivalent for loop.
The example has merit and is quite pertinent to the discussion. The foreach construction allows Perl to better understand your intention. It takes advantage of that knowledge to increase its efficiency. Hence my original point.
The foreach construction allows Perl to better understand your intention. It takes advantage of that knowledge to increase its efficiency.
Although if your're _that_ pressed for run-time efficiency, then you shouldn't be programming in an interpreted language in the first place. Sure, "for" is slower than "foreach" but replace all occurrences of the latter with the former is any application and what do you get? Certainly not a perceptible difference.
What matters in this case is that foreach style loops are easier for humans to parse.
Yes, you can get a very perceptible difference in performance with well-coded Perl. And yes, Perl is used for quite a few large scale applications where such efficiency is needed (Slashcode itself comes to mind). Run time efficiency is quite important and you should not dismiss a tool out-of-hand for a minor drawback such as its compilation system.
by Anonymous Coward writes:
on Wednesday October 03, 2001 @10:03PM (#2386673)
For all of those people who want to jump ship from perl6, all I can say is I'd give it some time. I've been playing around with the syntax in perl6, and I think people are giving it way too much short shrift, without thinking no less. Here, for example, are a couple of equivalent programs in perl6 and perl5:
Concatenating two arrays together:
perl5
my $biggest_index = (@array1 > @array2)? @array1:
@array2;
Comparing all of the elements in an array to one another for equality:
perl5:
for ($xx = 0; $xx @array1; $xx++)
{
($notequal = 1, last) if ($array1[$xx] ne $array2[$xx]);
}
if (@array1 != @array2)
{
$notequal = 1;
}
else
{
$notequal = 0;
}
Perl6:
$notequal = (@array1 ^!= @array2);
Perl5: setting an element to the first defined item:
my $element = (defined($a))? $a : (defined($b))? $b: 'default';
perl6:
my $element = $a// $b// 'default';
etc, etc. I could go on, but I'll leave it to damien && his exegesis...
Now, you could argue that things like the above don't belong in the language proper, and that it would be better to write functions to do them, but believe me, there are a hell of a lot of different low level functions that you can write, all with a little wrinkle here or there that makes them *slightly* different from the functions that you've written before - like doing cmp instead of ==, and so on.
So don't bolt before you see the final result.. I think its going to be really cool, especially being built on top of parrot....
Ed
(ps - as for the OO, I'd *also* hold my tongue if I were you. I've used the OO features of perl5 extensively, and its exceedingly flexible. There are aspects that I don't like (like no type checking of attributes as they are in a hash) but even this can be used to your advantage in programming.
so its definitely *not* worthless, and definitely something worth checking into. 50,000 line APIs don't just spring up overnight...
It'll be so great to be able to use expressions like "x y". Of course, you'll have to define for yourself what an eight teardrop-spoked propeller asterisk does...
Hmm... slashdot doesn't seem to like my character. Gonna make it hard to ask about my programs...
Ah, right. Yes, if I do the right thing, *then* slashdot doesn't like my character. Of course (❊) seems to work (maybe), but it's a pain to type decimal character values for unicode characters.
Well Hallelujah! (Score:1)
Thanks, Larry Wall. Now for some fun reading...
Re:Heh... (Score:1)
I bet you're just bitter because you don't understand it.
Why don't you go read one of the numerous "learning perl" pages and come back when you understand the subject your talking about.
OT: Did you guys see the online petition to fire Jon Katz [petitiononline.com]? Somebody has brass....
Wow... 22 names! I guess you showed them!
I'd sugest if you care so much about katz you go disable him in your prefs. The option is there, you just need an account. Seems like you'd have an account since you care so much about
Re:Heh... (Score:1)
Re:Heh... (Score:1)
Re:Heh... (Score:1)
It would look nicest in VB! Not much of a way to judge languages.
Re:Heh... (Score:2)
And as to perl's infamous illegibility, it's true that the code's readability has a lot to do with the author and only a bit to do with the language. But I'll tell you right now that most of the perl fanatics I've met and all of the perl coders with whom I've worked came to the language from little or no programming experience. This means that nearly all the code I (and they) encountered was written by someone who had, at the time of authorship, only the vaguest of notions about legibility.
Remember, dude, just because you like a particular thing doesn't mean it doesn't have flaws.
Re:Heh... (Score:2)
Re:Heh... (Score:1)
Re:Heh... (Score:1)
Re:Heh... (Score:1)
I think Java did well to leave it alone with the exception of String class, but that was one of those peer presure things. One could even deal without it in the Strings class.
Functional languages and parentheses (Score:2, Informative)
For example, Haskell parses f 0 + f 1 as: f(0) + f(1) (In a less obvious way, it also parses f g x as f(g, x), but that's another story...)
Re:Functional languages and parentheses (Score:1)
Re:Functional languages and parentheses (Score:1)
(+ (f 0) (f 1)) which is what you have to do in most versions of Lisp (I think)
Re:Functional languages and parentheses (Score:1)
Also, it goes naturally with the idea that code (and data) are lists; everything is a list. To overly simplify, when a form is being evaluated you operate on data as lists. When a macro is being evaluated you operate on the code as lists. So Lisp gets to be its own macro language. This oftern verbose syntax gives the language enormous flexibility and reflectiveness; I cannot think of a more reflective languages than Common Lisp, especially since you can control most of the compilation process by modifying various built-in forms.
If you do not like the parentheses, you can modify the "read" form to accept data that is not in list notation.
Now, if only it had the beauty and consistency of APL, but that is one of Lisp's best traits; you can make it look and do anything even things that suck. In a way its beauty comes from be able to make it look so ugly.
-j
Re:Functional languages and parentheses (Score:1)
This is the default syntax, 99% of the people will use it, so 99% of other people's code will use it, and 99% of the people won't like your code if you use something else.
Re:Functional languages and parentheses (Score:1)
Hugs [haskell.org] is an easy to setup interpreter, ghc [haskell.org] is a good compiler, with an accompanying interpreter.haskell.org [haskell.org] is a good place to start.
Now another difference between Haskell and usual programming is that it's lazy, meaning that expressions are only evaluated only as needed to produce the result (think the behavior of && in C, applied to the whole language). This is a rather cool feature, but it makes wrapping your head around haskell even more difficult, because it's not easy to tell how a Haskell program executes.You can also try a more traditional strict functional language like Ocaml, for size!
Re:How I long for this function (Score:1)
Hmmm. Perl and Emacs, together at last! That's an intriguing idea - why not send a proposal to Wall & Stallman?
Re:what a waste of time reading that.. (Score:1, Offtopic)
Breaking out of your own culture (Score:4, Interesting)
It is for statements like this, that I am drawn into studying and using Perl. Many designers try to design a langauge which develops its own internal culture; it becomes static and internally consistent, but not very adventurous. Larry Wall seeks to develop a language which has built-in the fact that we like to explore, making his task more difficult, but a language which moves and flows with the evolution of our culture readily.
Keep up the great work!
Re:Breaking out of your own culture (Score:1)
Whew... (Score:1, Troll)
Re:Whew... (Score:1)
It was the camel that fooled you?
Re:Whew... (Score:1)
keeping track of ops..? (Score:2)
This seems to be a seriously smart way to do sytax checking. Is this drawn from an existing implementation in a different language or is it a new development that he thought up?
Speaking from my own experience as a non-developer coder, I'd love to see more of this kind of "artificial" intelligence in programming languages. I really love the power of languages such as c/c++ but keeping track of every possible way I can fsk stuff up is just impossible. I definately think having more checks in place (within reasonable limits) would certainly make for better code all around.
Re:keeping track of ops..? (Score:3, Interesting)
5 - 3
5 + - 3
The first "-" relates to subtraction. The second one relates to negating a number. Those are two different kinds of operations, and those are considered two different operators. You can tell the two apart, because in the first one when you encounter "-" you are looking to extend the expression; while in the second when you encounter "-" you are looking for a second term to go after "+".
You could do the same thing with "=", but that sort of thing can get confusing. Imagine an expression $x = =$y (quite different from $x == $y !)
Re:keeping track of ops..? (Score:1)
If you're interested in how computers can help bring languages together, check out BlueBox [dloo.org] -- they're writing "words" which define behavior, and are working on writing syntaxes/grammars for most common languages.
The cool part about this? You can write a program in Perl, feed it into BlueBox, and have it output your program in C++. Or Python. Or Shell script. Or ASM.
Even better is the reverse: feed EXPLORER.EXE in and have it spit out Perl! 'Course it won't be commented, but -- humans know how to comment, perhaps humans can teach computers how to comment?
To be topical: BlueBox could also help convert from Perl 5 to Perl 6 (and vice versa!), once both grammars have been written.
Concatenating strings (Score:4, Insightful)
$a . $b . $c
you'll say:
$a _ $b _ $c
String concatenation is such a commonly used perl feature that it deserves a single character operator. Discriminating between operators by the existence of white space before/after the character is an incredibly ugly kludge. Larry seems to admit it, too: This is to be construed as a feature
At least we don't have to use "+", like in JavaScript!
Re:Concatenating strings (Score:2)
No, result should depend on types of operands (Score:3, Informative)
'a' + 'b' = 'Ã'
(char and char results in another char by adding their ASCII values)
"a" + 'b' = "ab"
(string and char results in a string by concatenation)
'a' + "b" = "ab"
(char and string -- order does not matter, so see string and char above)
"a" + "b" = "ab"
(string and string results in a string by concatenation)
To summarize, if a string is involved, then the char(s) is (are) promoted up to string(s) and the result depends on concatenation. If all operands are chars, then no promotion occurs and they are added by ASCII value.
This is similar to the numerical addition rules of C, C++, and a number of similar languages. One simple example: If an int and a float are added, the int is promoted to be a float and the result is a float. If an int and an int are added, the result is an int and must by cast (either explicitly or implicitly) in order to be a float value.
I'm not too familiar with Perl, but this seems to be the most sensible behavior. If I'm missing something and there's a valid reason not to use an addition sign for concatenation, please reply and let me know.
Re:No, result should depend on types of operands (Score:1)
Strictly speaking, only two characters are required for the underscore operator in many cases, because disambiguation between the operator and a trailing underscore is more of an issue:
Should be ok, I guess. But not a good idiom.Of course, this is based on my knowledge of Perl 5. I havn't been able to keep track of the proposed changes to Perl 6 - there is some very wierd stuff going on there. I suspect there will be a large learning curve to transition to it when it is finished and released.
Re:No, result should depend on types of operands (Score:3, Informative)
They do, but the rather essential point that your missing is that in Perl both 1 and "1" are scalar -- they have the same type (in an obviously broader sense of the word). "1" + "1" produces "2" (or 2), as does 1 + "1", "1" + 1, and 1 + 1; and, as you might expect, "1" . "1" and 1 . 1 (note the whitespace) produces "11". Thus the need for distinct syntax, which is already present in the equality operators, where you have == vs eq, > vs gt, etc.
As has already been stated, single and double quoting controls variable interpolation in Perl; there are no character constants as such. And since we're playing lanaguage lawyer, (non-wide-)character constants in C are actually int's, and are not required to be ASCII (which only uses 7 bits, anyway), and strings are by definition null-terminated.
Which begs the question of why you posted in the first place.
Re:Concatenating strings (Score:1)
The most obvious problems occur when concatenating numbers, like
$phonenumber = $areacode + $phonenumber;
In Javascript, I think you have to do something like
phonenumber = areacode + '' + $phonenumber
to make it understand that you want concatenation, not addition.
Perl currently makes good use of all the symbols
on the keyboard, even tilde and backtick. I always thought the dot was a very elegant way to represent concatenation. Still, I'd give it up for real perl structs
also too bad underscore requires pressing shift (Score:2)
of course perl has such extensive string interpolation and other capabilities that this doesn't strike me as a humongous problem.
I, too, hate the whitespace kludge, but then i've always put whitespace around my dots too because print $this . $that just seems more readable to me than print $this.$that, which looks disturbingly like some kind of slightly funky method call.
Re:Concatenating strings (Score:1)
$d = "$a$b$c";
Re:Concatenating strings (Score:1)
For appending:
$a.=$b;
For expressions:
print '$'.(int($amount/100)).($amount%100)."\n";
Re:Concatenating strings (Score:2, Informative)
Actually, I'd be surprised to see that stick around once Unicode support is rock-solid on the popular platforms. Larry mentions using non-ASCII operators, and I'm almost sure string concatenation will use one of these.
For my part, though, I actually like spaces around most binary operators, and wouldn't be upset to see it enforced in the language. That way, people would write unreadable code in my style of unreadable coding. ;)
I'm looking forward to non-ASCII operators. I understand they were much loved on the Lisp machines, and much hated in APL. Different ways of handling things in the two languages, though, so it might be a contextual thing. It will be interesting to see how they are received after twenty years or so of disuse.
As I sheepishly back away... (Score:4, Interesting)
Now, I consider my job to be 'Intranet Systems Arhitect' as distinct from 'Programmer'. Perhaps that's why I can't get excited about changing a tool I've come to depend on in it's current form. Perhaps true programmers might find the prospect fascinating. perhaps you could liken it to the difference between an army officer and a gunsmith. While both make use of guns at various times, only the gunsmith is inclined to take the gun apart, examine it and make a better one.
Or perhaps I'm just not showing the proper community spirit, and I should dive in and offer my two cents on how to make the language better. Maybe I'm just lazy (then again, isn't that why perl is such a great language...)
--CTH
Re:Change is good (Score:3, Insightful)
--CTH
Larry is always interesting (Score:3, Interesting)
How perl 6 will fare is another issue. The language is going to change radically - will developers follow Larry into perl 6, just use perl 5 compatibility mode, or move on altogether?
Re:Larry is always interesting (Score:2)
Jeremy
Re:Larry is always interesting (Score:1)
If I could I would mod this up to Funny.
Re:Larry is always interesting (Score:1)
Okay I know its corny but it just seemed to fit... rr ee dd uu nn dd aa nn tt can be funny some days
Jeremy
Re:Larry is always interesting (Score:3, Funny)
Is this the same -Wall whose name scrolls past so many times when you recompile your kernel?
The Apocalypse after the Apocalypse after the... (Score:1, Redundant)
Re:The Apocalypse after the Apocalypse after the.. (Score:1)
domc
Re:The Apocalypse after the Apocalypse after the.. (Score:1, Funny)
Re:The Apocalypse after the Apocalypse after the.. (Score:1)
Not if you understand that apocalypse means 'revelation' (from the greek apokalypto, to reveal) and that the only reason its connoted with the end of the world is because of the similarly-titled last book of the bible...
Perl trying to outgrow its niche (Score:3, Interesting)
Re:Perl trying to outgrow its niche (Score:1)
Let's face it, perl is absolutely great for its original intention - fast, easy, write-and-forget scripting. .... Wall and his fellow "designers" are struggling vainly to make Perl "grow up" -- something that it has absolutely no need to do.
Perl is already used by many people not just as fast, easy, write-and-forget scripting lanuguage. Java, Python are good languages but they don't have something that is missing in Perl. Perl have everything anyone needs to build complex web application for example(mod_perl, AxKit, HTML::Mason, etc).
operators (Score:1, Interesting)
Re:operators (Score:2)
Limerick (Score:2, Funny)
To maintain his own scripts, his downfall
He released to the world
A wonder named Perl
You can write code, but never recall!
Not a good title (Score:1, Troll)
But today, when I see "Apocalypse 3" in a link from a previous story... I wasn't sure whether to click to read the story, or get up to check for mushroom clouds outside the window.
I'm such a nerd... I didn't get up.
Re:Not a good title (Score:3, Informative)
Those Bums know everything... (Score:1)
Sweet! Hyperoperators! (Score:2, Interesting)
$a = $b.$c;
print "Hello: ".$you."\n";
becomes
$a = $b _ $c;
print "Hello: " _ $you _ "\n";
It is definitely more readable, but I dislike significant whitespace. shrug
But as to the rest of the proposed changes, I can't wait.
Re:Sweet! Hyperoperators! (Score:2, Informative)
> print "Hello: ".$you."\n";
>
> becomes
>
> $a = $b _ $c;
> print "Hello: " _ $you _ "\n";
Or just
$a = "$b$c";
print "Hello: $you\n";
like you can do right now.
I can't tell yet whether "$a:b" will change, but presumably the Perl5 clarification "${a}:b" would still work.
Re:Sweet! Hyperoperators! (Score:2)
Re:Sweet! Hyperoperators! (Score:1)
And I don't completely buy the excuse that we're running out of punctuation characters. If you're going to jumble some of them up and talk about the "Huffman" reason for picking multi-character operators for some and not for others: let's do a little more housecleaning. Get rid of the bit operators as punctuation characters and make them named operators. That frees up some punctuaction for something that's not used very often anyway.
BTW, if you're under the impression that they're used frequently try: Sure it doesn't pick up everyhing (late compilation), but in the 1056 files I have there I had exactly 7 occurances of bit operators. This does not impress me enough to use valuable punctuation.
More eclectic, less practical... (Score:3, Interesting)
Maybe it is just me, but the more and more I see what is going on in the perl world, the less and less I want to have anything do with it. The whole
hyper-operator conecpt is a good example. My thoughs? Just use a fscking for loop. That is what they were designed to do. Larry seems to be going through *great* pains to include as many bizzare syntactic short cuts as you can reasonably string characters on the keyboard to represent. This is not terribly innovative.
It's starting to diverge from "Practical extraction and report(ing) language"
and towards "pathetically Eclectic rubbish lister". Personally, I aim a little more towards practical. That was what made it so popular to begin with. Make difficult things easy and hard thing possible was a nice concept. Perl 5 did that well. IMNSHO, Perl 6 seems to be making 100 ways to do the same simple thing all so the developer can opt to use the method with the verbosity level he/she desire, and not making the hard things any easier.
</rant>
Re:More eclectic, less practical... (Score:3, Informative)
Re:More eclectic, less practical... (Score:1)
Re:More eclectic, less practical... (Score:1)
I will agree, alot of the proposed changes don't seem to have alot of immediate application to what I do personally, but I admit their utility.
But here's an idea in which we can both be happy: Don't use Perl 6. Continue on with 5. Considering the immense amount of v5 code, I doubt highly that it will all suddenly disappear. In fact, I recall from a previous Apocalypse that Larry mentioned the idea of allowing all existing Perl5 syntax, until you use a piece of new syntax.
Yeah, it's not the greatest of solutions. Perhaps what will happen will resemble C/C++, with many continuing to use the old for quite a while yet.
Re:More eclectic, less practical... (Score:3, Insightful)
The point of Perl is not necessarily to provide more than one way to do things, but to make certain types of programming much easier than with other languages. There are things I do in Perl in an hour that would be a week undertaking in C or C++. If enough users are calling for these seemingly esoteric features, add them. The more expressive the language, the more useful.
Re:More eclectic, less practical... (Score:2, Informative)
ripped from perlsyn (man perlsyn):
The `foreach' keyword is actually a synonym for the `for' keyword, so you can use `foreach' for readability or `for' for brevity.
I do agree on your point though, you just choose a bad example and topic, since 'Efficiency' for perl *normally* means coding better and faster, not running faster.
Re:More eclectic, less practical... (Score:1)
For example:
and a foreach loop:
The Perl Manual [perldoc.com] has this to say on the matter.
It's [foreach] cleaner, safer, and faster. It's cleaner because it's less noisy. It's safer because if code gets added between the inner and outer loops later on, the new code won't be accidentally executed. The next explicitly iterates the other loop rather than merely terminating the inner one. And it's faster because Perl executes a foreach statement more rapidly than it would the equivalent for loop.
The example has merit and is quite pertinent to the discussion. The foreach construction allows Perl to better understand your intention. It takes advantage of that knowledge to increase its efficiency. Hence my original point.
Re:More eclectic, less practical... (Score:2)
Although if your're _that_ pressed for run-time efficiency, then you shouldn't be programming in an interpreted language in the first place. Sure, "for" is slower than "foreach" but replace all occurrences of the latter with the former is any application and what do you get? Certainly not a perceptible difference.
What matters in this case is that foreach style loops are easier for humans to parse.
Re:More eclectic, less practical... (Score:1)
don't jump to conclusions: (Score:4, Insightful)
Concatenating two arrays together:
perl5
my $biggest_index = (@array1 > @array2)? @array1:
@array2;
for ($index = 0; $index $biggest_index; $index++)
{
$array1[$index] += $array2[$index];
}
perl6:
@array1 ^+= @array2;
Comparing all of the elements in an array to one another for equality:
perl5:
for ($xx = 0; $xx @array1; $xx++)
{
($notequal = 1, last) if ($array1[$xx] ne $array2[$xx]);
}
if (@array1 != @array2)
{
$notequal = 1;
}
else
{
$notequal = 0;
}
Perl6:
$notequal = (@array1 ^!= @array2);
Perl5: setting an element to the first defined item:
my $element = (defined($a))? $a : (defined($b))? $b: 'default';
perl6:
my $element = $a
etc, etc. I could go on, but I'll leave it to damien && his exegesis...
Now, you could argue that things like the above don't belong in the language proper, and that it would be better to write functions to do them, but believe me, there are a hell of a lot of different low level functions that you can write, all with a little wrinkle here or there that makes them *slightly* different from the functions that you've written before - like doing cmp instead of ==, and so on.
So don't bolt before you see the final result.. I think its going to be really cool, especially being built on top of parrot....
Ed
(ps - as for the OO, I'd *also* hold my tongue if I were you. I've used the OO features of perl5 extensively, and its exceedingly flexible. There are aspects that I don't like (like no type checking of attributes as they are in a hash) but even this can be used to your advantage in programming.
so its definitely *not* worthless, and definitely something worth checking into. 50,000 line APIs don't just spring up overnight...
Re:don't jump to conclusions: (Score:1)
Concatenating two arrays together:
@array1 = (@array1, @array2);
Setting an element to the first defined item:
$element = (grep defined, ($a, $b))[0] || 'default';
note that this last example is also generalizable to lists of arbitrary length...
Unicode operators? (Score:3, Funny)
Hmm... slashdot doesn't seem to like my character. Gonna make it hard to ask about my programs...
Re:Unicode operators? (slightly OT...) (Score:2)
Re:Imagine (Score:1, Offtopic)