Weekly Edition
Return to the Development pageRecent Features
| |||||||||||||
Quotes of the week
I really urge people to think about openness and freedom, two
amazingly important concepts, beyond the boundaries of simple
software licensing. Licensing is important, and we take it pretty
damn seriously .. but we ought to look at bigger picture and really
think about how to make our digital tools open and free in all
sorts of ways.
-- Aaron
Seigo
But whereas I previously held for Java a cordial dislike borne of
having only a cursory notion of how it worked, now my dislike for
the language can no longer be called at all "cordial", for
familiarity has bred contempt.
-- Tom Christiansen(Log in to post comments)
Quotes of the week Posted Feb 2, 2012 2:15 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] The second quote omits critical context. The very next sentence readsAnd that's something that should really be suppressed, because it doesn't help anyone, and helping people is the whole point here. So he's saying that while he isn't a fan of Java, such an attitude shouldn't leak into a document that is intended to warn Java programmers who are learning Perl about traps for the unwary.
Quotes of the week Posted Feb 2, 2012 5:58 UTC (Thu) by ncm (subscriber, #165) [Link]
The word "contempt" is always a good place to end a juicy quote. But the context does add to its amusement value. It's one thing for a programmer to hold Java in (justified!) contempt, and quite another thing for a Perl programmer. Do Yugo owners sneer at Trabants? Yes, they do, and we mustn't begrudge them it.
Quotes of the week Posted Feb 5, 2012 8:17 UTC (Sun) by chip (subscriber, #8258) [Link]
Tom has never been the kind of person to let a lovely turn of phrase go unwritten just because it is off point.
That said ... Perl is not what it once was. Sneer with care.
Quotes of the week Posted Feb 2, 2012 19:34 UTC (Thu) by ballombe (subscriber, #9523) [Link]
Tom Christiansen deserves the Nobel prize of literature.
Whether you agree with his points or note, his prose is always worthy of Charles Dickens. Someone should collect them under the name 'the Perlwick papers'
Quotes of the week Posted Feb 5, 2012 4:50 UTC (Sun) by cmccabe (guest, #60281) [Link]
Java doesn't have function pointers, but it does have anonymous classes, which fill the same kind of role.
Perl just always rubbed me the wrong way. In Python, or Ruby, or any other reasonable language, you can print a list just by doing "print mylist" or similar. In Perl, you have to remember some magical mumbo jumbo or else it just prints out a number.
In any other high-level language, you don't have to worry about pointers any more. But in Perl, you have to worry about dereferencing "refs," creating refs, and all sort of syntactic garbage. I'm using a VM, everything is a pointer-- stop bothering me about your stupid implementation details.
I could write more here-- a lot more-- but... it would get kind of flamey. Suffice it to say, I feel this is a "stones, glass houses" type situation.
Quotes of the week Posted Feb 5, 2012 8:21 UTC (Sun) by chip (subscriber, #8258) [Link]
You should indeed take care in throwing stones. Consider:
"In any other high-level language, you don't have to worry about pointers any more.... I'm using a VM, everything is a pointer..."
You have somehow managed to write two contradictory statements that are both false.
Consider, just as existence proofs, the JVM distinction between native types and boxed types and the similar CLR distinction which includes even structs.
Quotes of the week Posted Feb 5, 2012 21:05 UTC (Sun) by cmccabe (guest, #60281) [Link] Yes, Java has primitives which don't have pass-by-reference semantics. You understood perfectly well what I meant, though.If you enjoy being pedantic, try figuring out what kind of argument passing semantics perl has. And what does this program print out?
#!/usr/bin/perl
use strict;
sub fn {
@_[0] = "go away\n";
}
sub fn2 {
my $var = @_[0];
$var = "hello\n";
}
my $foo="hi\n";
fn($foo);
fn2($foo);
print $foo;
Quotes of the week Posted Feb 6, 2012 3:07 UTC (Mon) by chip (subscriber, #8258) [Link]
One man's "pedantic" is another man's "actually correct."
Your example is trivial. Perl's parameter passing is by reference, assignment is scalar copy, and strings are scalar values (not references). Yawn.
I believe the phrase you're looking for is "Sorry, I was mistaken."
PS: Your use of @ for a single array element suggests you haven't actually learned Perl, just learned enough to make fun of it. Also a mistake.
PPS: Assignment can be more complex in the presence of overloading, which I know because I know Perl (you could too) and I happened to be the one who accepted that feature into the Perl code base (not you, sorry).
Quotes of the week Posted Feb 6, 2012 7:40 UTC (Mon) by cmccabe (guest, #60281) [Link]
I'm trying hard to phrase this well. I don't want to start a flamewar (language flamewars are pointless), but I also want you to know where I'm coming from.
I just... don't care for certain aspects of Perl. Maybe it's the way I was educated, maybe it's my background (mostly C, Java, a little bit of Python). Maybe it's something else. But the language just feels overly complicated to me in a way that Python and Ruby do not.
Like why do references exist at all? Python and Ruby don't have them and don't need them. And if @_ is really a reference, why isn't the syntax consistent with the other references in the language. And so on.
In a way, Perl kind of reminds me of Bash scripting. I can get a lot done in Bash, but there's always those moments when the utter perversity of the language just makes you want to punch the computer. I guess the name fits, no?
Quotes of the week Posted Feb 7, 2012 2:01 UTC (Tue) by chip (subscriber, #8258) [Link]
Well, you've covered a few points....
First, Perl's original form of referencing is _aliasing_, which is the form that @_ uses. In a subroutine, $_[0] is an _alias_ for whatever you passed as the first parameter. So modifying $_[0] modifies that thing (or dies trying).
Second, in Perl 5 a new kind of value actually called a "reference" was introduced to support nested data structures. Scalars are the only thing arrays and hashes can hold; so a special scalar, the Reference, was introduced to point to other things. So in the multidim array expression $a[0][1], $a[0] is (or should be!) a reference to the array where [1] is looked up.
This left scalars with a privileged place compared to all other kinds of values. This was not ideal, and Perl 6 loses the distinction so one assumes the designers learned their lesson, but it's not totally awful. Only mostly.
Meanwhile, aliasing and references can both be used to accomplish some of the same things, e.g. modifying a variable that isn't directly named. It's not surprising that they are confusing when you're first learning Perl. Evolving languages collect cruft.
Third, some peoples' brains just don't like Perl. That's fine, I wouldn't dream of berating anyone for that. As for me, I don't like Python even a little bit, so there you go. TMTOWTDI.
Quotes of the week Posted Mar 6, 2012 16:59 UTC (Tue) by shlomif (guest, #11299) [Link] Hi cmccabe, I'd like to comment on what you said:
First of all, Python and Ruby do have references, it's just that they decided to make every array, and hash variable a reference, instead of having aggregate data structure variables that get seamlessly converted to and from lists. Let's see a demonstration of these reference semantics in action: shlomif@telaviv1:~$ irb irb(main):001:0> x = [5,6,7] => [5, 6, 7] irb(main):002:0> y = [100,x] => [100, [5, 6, 7]] irb(main):003:0> y[1][0] = 300 => 300 irb(main):004:0> x => [300, 6, 7] By changing a referent to "x" contained in the "y" array, we've changed x. Similarly in Python: shlomif@telaviv1:~$ python Python 2.7.2 (default, Dec 5 2011, 16:10:45) [GCC 4.6.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> x = [5,6,7] >>> y = [100,x] >>> x [5, 6, 7] >>> y [100, [5, 6, 7]] >>> y[1][0] = 300 >>> x [300, 6, 7] >>> The fact that in Perl not every hash and array are references is in part a relic of its perl1→perl4 history, but it also allows for some nifty tricks:
# For initialising a hash from an array.
@a = (1,2,3, 'other');
my %h = (map { $_ => 1 } @a);
# For performing a flat-concatenation of a list of array references.
my @long_array = (map { @$_ } ([1,2],[3,4],[5,6,["Hello","There",],7]))
For more about the conference of references in programming, you may wish to consult the Wikipedia article (which I admit I have not read in full). Someone else answered regarding the behaviour of @_ with regards to aliasing.
Quotes of the week Posted Feb 7, 2012 5:28 UTC (Tue) by madscientist (subscriber, #16861) [Link]
> In Python, or Ruby, or any other reasonable language, you can print a list
> just by doing "print mylist" or similar. In Perl, you have to remember > some magical mumbo jumbo or else it just prints out a number.
"Some magical mumbo-jumbo" like putting it in a string :-)?
print "array contents = @myarray\n";
Writing in Perl5 is fun. To me it is an excellent blend of "do exactly this" and "just do what I want and don't bug me".
Quotes of the week Posted Feb 7, 2012 8:58 UTC (Tue) by khim (subscriber, #9252) [Link] Writing in Perl5 is fun. Perl is WORN (Write Once Read Never) language. Sure, it's fan to write perl. Not so fan to read and debug it. It has so many ways of doing things that when you read code written by someone else you regularly hit constructs which you just never use. Basically it's the only language where I've felt the need to write comments and even they don't always help. Perl is more convoluted then bash - and that's saying something!
Quotes of the week Posted Feb 8, 2012 5:32 UTC (Wed) by madscientist (subscriber, #16861) [Link]
This is not true. Perl is no more WORN than many other languages. Some people seem to think that because Perl has been around for a long time, or because it takes ideas from other, familiar tools, that Perl should not need to be learned. While it IS possible to just pick up and use Perl, and mostly you can get things to work, that's not going to give good results... and no reason why it should be expected to. Perl is a victim of its own attempts to be easy to use: if it was markedly different than more familiar languages then no one would expect people to be able to write maintainable code in Perl without learning anything first. But because it's considered the universal glue language, "just like the shell but with extra capabilities", you get a lot of people with no training using it. Similarly you get a lot of people with no experience with Perl trying to maintain it.
If you have two programmers of equivalent skill and they spent the same amount of time learning Perl and C++ respectively, the one using Perl would be able to get more done with less code and it would take less time, and the Perl code would be more maintainable in the end.
Quotes of the week Posted Feb 8, 2012 8:37 UTC (Wed) by anselm (subscriber, #2796) [Link] Perl isn't really a difficult language, but when you're learning Perl it does help a lot to understand the culture it comes from – C and Unix command-line tools like grep, sed, awk and so on. That was all right in the late 1980s when Perl was new and most Perl users were really Unix sysadmins, but today this is a background that most people no longer have. The other problem with Perl is Larry Wall's background as a linguist, which led to Perl including weird concepts such as »context« which are quite logical in a way but which stymie people coming to Perl from other languages. (For example, many Perl newbies tend to confuse »$array[…]« and »@array[…]«, as seen in the code example posted earlier in this discussion.) I have taught lots of Perl classes, and a central feature of those is usually a big table explaining the differences between the various »$@%« characters and what they do to different data types. In my experience, the people who diss Perl are usually the ones who have never learnt the language properly. On the other hand, I do most of my actual programming in Python now, while Perl is just for sysadmin stuff and throwaway scripts – but that has nothing to do with Perl as such, and more with Django being the web framework that I feel most comfortable with (having tried most of the Perl-based ones and a few others).
Quotes of the week Posted Feb 8, 2012 9:32 UTC (Wed) by khim (subscriber, #9252) [Link] Perl is no more WORN than many other languages. Yes, it is. WORN is the very core of Perl, it's definition, it's raison d'être. When your language have 10'000 ways of doing the same things it mean that if you want to use it you need to know it all before you'll even start. There are only two popular languages which have this disease: C++ and Perl. C++ is hard to replace because some things it does can not be efficiently done in any other popular language (and when you go in the direction of esoteric languages you get the very some problem simply because language is esoteric). And C++ people understand that this is huge problem - that's why there are detailed guides which try to mitigate the problem. Perl... well, it' proponents still try to paint this huge problem as something positive. If you have two programmers of equivalent skill and they spent the same amount of time learning Perl and C++ respectively, the one using Perl would be able to get more done with less code and it would take less time, and the Perl code would be more maintainable in the end. This is most definitely not true. On the "millions lines of code" end: as your program grow compiler-time checks become more and more valuable and at some point you just can not make you system work without them. C++ wins here hands down (C#/Java may even be slightly more productive, but not by much). On the "small glue script which is changed by dozens of persons and each introduced change about once per year". Perl is hopeless here: there are so many ways to write such script that more streamlined language (like Python) saves many, many hours (which can be spent doing something else). Now for the midlle end... Yes, perl can be used for projects of the "tightly knit team" style where there are small amount of code (so you don't need to change code which nobody touched for 5 years) and most developers are familiar with the style used in this team (so you don't need to learn different styles when you switch from one file to another), but for this kind of work any language will be suitable, so perl is not all that advantageous.
Quotes of the week Posted Feb 8, 2012 12:18 UTC (Wed) by anselm (subscriber, #2796) [Link] When your language have 10'000 ways of doing the same things it mean that if you want to use it you need to know it all before you'll even start. This is a feature Perl shares with languages like English. Yet, strangely enough, most people can converse perfectly well in English without knowing »it all«. The same applies to Perl. If that means you have to look at a dictionary every once in a while, then well, learning something new every so often has never hurt anybody yet.
Quotes of the week Posted Feb 8, 2012 12:42 UTC (Wed) by khim (subscriber, #9252) [Link] This is a feature Perl shares with languages like English. Yet, strangely enough, most people can converse perfectly well in English without knowing »it all«. Wow. Do you want to compare something which you pick with something which is thrust down the peoples throat? Really? Most people don't know English¹), the ones who do know it don't like it and tend to avoid it (as was already discussed in LWN) and the only reason they use English at all [ultimately] is because people who print money speak English. And even when people are forced to use English for communication they tend to avoid languages which "look just like English" (see Cobol). The same applies to Perl. Agree 100%. Just like with English you should never ever use Perl unless paid extra or unless you need to participate in project which already uses Perl for some reason. Or is not what you wanted to say? ───────────────────────── ¹) I'm not talking about native speakers here: they obviously have no choice.
Quotes of the week Posted Feb 8, 2012 14:01 UTC (Wed) by anselm (subscriber, #2796) [Link] Whatever. Feel free to replace the word »English« in my comment with »Mandarin« or »Swahili« or some other language you fancy; it doesn't change the nature of my argument, namely that speakers of language X seldom if ever know all of X but can still get along perfectly fine in X. Coming back to English just for the sake of the example, this means that – unless you are a scholar of modern literature – you don't need to be able to understand (let alone write) Ulysses to be able to go about your daily life without problems. Ask ten random Python programmers whether they know how metaclasses work, and you will find that this applies to most languages.
Quotes of the week Posted Feb 8, 2012 16:37 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Uhm.
"Ulysses" is a head case. If there were an International Obfuscated English Contest then James Joyce would be its winner.
Most native Russian speakers _understand_ all of Russian language (well, maybe except a few archaic but technically valid constructs). And it's quite non-trivial to write something like "Ulysses" in Russian because of rich morphology - a lot of meaning can be inferred from word forms alone, one can actually construct meaningful (in context) sentences using ONLY profane words see http://en.wikipedia.org/wiki/Mat_%28Russian_profanity%29#... (or http://en.wikipedia.org/wiki/Glokaya_kuzdra for a family-friendly variant).
Quotes of the week Posted Feb 8, 2012 21:04 UTC (Wed) by nix (subscriber, #2304) [Link]
I don't know, the vocabulary looks very much like English, sexual terms considered profane and all that (you can easily construct meaningful sentences in English using only profane terms and connectives too). Now Quebecois, *that* has an unusual vocabulary for profanity in modern terms, though it would have been considered unremarkable in England 500 years ago.
Quotes of the week Posted Feb 8, 2012 21:18 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
No, in Russian a whole sentence can be constructed from different inflected forms of just _one_ word. And it'll be perfectly understandable within its context.
Quotes of the week Posted Feb 9, 2012 20:43 UTC (Thu) by dwmw2 (subscriber, #2063) [Link]
In English you can construct a whole sentence from different forms of just one word too:
Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo.
I'm not sure I'd claim it was perfectly understandable though; it may take some explaining. ☺
Quotes of the week Posted Feb 8, 2012 18:11 UTC (Wed) by khim (subscriber, #9252) [Link] Whatever. Feel free to replace the word »English« in my comment with »Mandarin« or »Swahili« or some other language you fancy; Python explicitly proposes different paradigm: there should be one—and preferably only one —obvious way to do it. Uses of other programming languages use style guides to achieve the same property. it doesn't change the nature of my argument, namely that speakers of language X seldom if ever know all of X but can still get along perfectly fine in X. Sure. If you want to use Perl to write poems then your argument makes perfect sense. But if your argument is supposed to help Perl's stance as programming language then you fail utterly and totally: people don't ever use English to write programs. Heck, they don't even use English for formal documents (they use specialized subset). Perl is great thing: it can be great source of jokes and you can even use it for poetry as shown above. What you should not EVER do is to use it for programming. The very fact that you used English and not, for example, arithmetic says volumes about where one should put Perl. Hint: it's not in the line of programming languages, it's outside of it.
Quotes of the week Posted Feb 8, 2012 16:23 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Speaking as a non-native fluent English speaker :)
Written English is not hard. It's easy enough to start using it: no complex declensions, no pesky grammar cases, trivial plural/singular rules, etc.
It's almost like Python!
I also speak German, my native language is Russian, I speak Ukrainian well enough and I also know bits of Udmurt language.
Quotes of the week Posted Feb 8, 2012 17:42 UTC (Wed) by anselm (subscriber, #2796) [Link] Written English is not hard. It's easy enough to start using it: no complex declensions, no pesky grammar cases, trivial plural/singular rules, etc. It's almost like Python! I'd say that English is really more like Perl than Python, in that in English often »there is more than one way to do it«: Many words exist in both Germanic and Romance flavours (possibly with noticeable different meanings – think »cow« vs. »beef«), many words can be used interchangeably as verbs or nouns, and there is a big dependency on »context« to figure out what things actually mean. Just like Perl, English can be very difficult to parse. Look at www.crashblossoms.com for some choice examples. And English pronunciation can be … counterintuitive. In the end, a little more structure than what English provides can be a good thing (as long as we don't take this as far as Russian or Finnish). Look, for example, at Esperanto, which like English has a very simple grammar and very fluid word formation rules, but at least it is always clear whether a word is a noun, verb, adjective, or adverb, whether a noun is singular or plural, what tense a verb is in, and how words are pronounced. Which probably sort-of explains why many people prefer Python to Perl – fewer choices, hence less anarchy – while other people prefer Perl to Python – more choices, hence more room for subtlety. Just as with human languages, there is no general consensus as to which is better, and that's probably just as well, since so far all attempts to come up with one programming language to solve everybody's problems have tended to lead nowhere (much like most attempts to come up with better languages for humans).
Quotes of the week Posted Feb 8, 2012 18:03 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
>I'd say that English is really more like Perl than Python, in that in English often »there is more than one way to do it«: Many words exist in both Germanic and Romance flavours (possibly with noticeable different meanings – think »cow« vs. »beef«)
That's a staple of nearly all of the real natural languages, you can only stretch analogy so far (Russian also has this distinction between 'cow' and 'beef', btw).
>many words can be used interchangeably as verbs or nouns, and there is a big dependency on »context« to figure out what things actually mean. Just like Perl, English can be very difficult to parse. Look at www.crashblossoms.com for some choice examples.
One can learn to write grammatically correct (although very simplistic) English after a few months of studying it. It's not possible with inflected languages like Russian or (for example) Finnish where you have to learn nearly all the grammar to write something that won't cause fits of laughter from native speakers.
>And English pronunciation can be … counterintuitive.
Quotes of the week Posted Feb 8, 2012 18:27 UTC (Wed) by anselm (subscriber, #2796) [Link] (Russian also has this distinction between 'cow' and 'beef', btw). Just to make the point of the example clear: The English word »cow« comes basically from the German word for »bovine«, while the English world »beef« comes from the French word for »bovine«. In English, »cow« refers to the animal but »beef« refers to the animal's meat, so one of the two (formerly equivalent) words has shifted to mean something else. In modern German, the word for »beef«, while distinct, is much more closely related to the name of the actual animal than in English. I don't speak Russian, so I can't say anything about the linguistic relationship of the words there.
Quotes of the week Posted Feb 8, 2012 21:30 UTC (Wed) by viro (subscriber, #7872) [Link]
"корова" and "говядина" resp.
The former is at least Old Slavic (modulo trivial phonetic change) with more or less the same meaning; apparently the same root as in Eng. "horn".
The latter is derived from extinct "говядо", which was a cognate of "cow" actually. With (still productive) suffix meaning "meat of..." appended.
So no, in this case it wasn't pulled from another language - both roots had been there all along. So was the third one, actually - "бык" for male ones, same root as "bull". Still alive and well. I'm not sure if "говядо" had been a gender-neutral form - might have been, but...
Quotes of the week Posted Feb 9, 2012 11:51 UTC (Thu) by jubal (subscriber, #67202) [Link] Well, in Polish you also have ‘krowa’ (note the similarity to ‘корова’, the pronunciation differences are quite small) as a general name for cows – and used for the female; but the meat (i.e. beef), is called ‘wołowina’, from ‘wół’, i.e. a neutered bull. (The bull is called ‘byk’ in Polish, with exactly the same pronunciation as ‘бык’)
Quotes of the week Posted Feb 8, 2012 21:46 UTC (Wed) by nix (subscriber, #2304) [Link] But again, in real world English is easy enough to understand and write, even for relatively novice speakers.Except when it isn't. I defy you to figure out what on earth "Slough sausage choke baby death woman jailed" means unless you already know what the article is about. The 'jailed' is clear enough, but the rest of the sentence has so many alternative parses that it just seems like a jumble of words until you figure out the structure of the insane compound NP head in use. And this sort of thing is pretty common in contracted writing of all kinds, not only headlinese.
Quotes of the week Posted Feb 9, 2012 14:48 UTC (Thu) by gowen (guest, #23914) [Link] Funny choice of example, but I grokked that at the first read, without any familiarity with the case. I am, however, familiar with the peculiarly verbose grammar of the DSL used in local newspaper headlines. And I knew Slough was a place.
Quotes of the week Posted Feb 9, 2012 15:35 UTC (Thu) by nix (subscriber, #2304) [Link]
You are better at parsing than I am. I had to read it four times to parse it properly, and I *lived* in Slough for a while. :)
Quotes of the week Posted Feb 8, 2012 18:17 UTC (Wed) by khim (subscriber, #9252) [Link] Which probably sort-of explains why many people prefer Python to Perl – fewer choices, hence less anarchy – while other people prefer Perl to Python – more choices, hence more room for subtlety. s/subtlety/bugs/ Just as with human languages, there is no general consensus as to which is better, and that's probably just as well, since so far all attempts to come up with one programming language to solve everybody's problems have tended to lead nowhere (much like most attempts to come up with better languages for humans). Sorry, but there is. When we are talking about literature pieces then yes, there are no consensus. But when we need correctness (law, math, programming, etc) then we use specialized subset or formalized formulas. And Perl is obviously totally unsuitable for that. Perhaps you misunderstood me? I kind of assumed that we talk about suitability of Perl for programming, not prosody...
Quotes of the week Posted Feb 8, 2012 18:51 UTC (Wed) by anselm (subscriber, #2796) [Link] s/subtlety/bugs/ No. For example, Perl supports both »if (EXPRESSION) { COMMAND }« and »COMMAND if EXPRESSION«, with identical semantics. Using one or the other, one can put different emphasis on either the COMMAND or the EXPRESSION (much like one can use word order for emphasis in many natural languages), and that can actually make code easier to read on a subtle level. (Of course not everybody appreciates this.) Also, it must be said in the interest of fairness that over the years even Python has acquired its share of »there's more than one way to do it« features (although certainly not on Perl's scale). Think »list comprehensions vs. loops«, or »i += 1«, or »foo = bar if baz else quux«. This appears to indicate that, even in the Python world, convenience or efficiency are sometimes valued higher than intellectual purity. The »sweet spot« seems to be somewhere in the middle.Sorry, but there is [general consensus that Python is better than Perl]. If that was in fact the case, then why is there still new code (not just extensions to existing projects) being written in Perl, and why is Perl itself being developed further (including new features only useful to new code)? One would expect that, if there was general consensus that Python (or Ruby, or Java, or …) was better than Perl, all activities related to Perl would focus on keeping existing Perl code running on the existing Perl implementation (possibly with whatever indispensable bug fixes were needed) until it was either no longer required or else could be replaced by equivalent or better Python (or Ruby, or Java, or …) code. Hence no new development on the Perl side would be desirable or even necessary. However, this is not what is actually taking place. Possibly your definition of »general consensus« is different from mine ;^)
Quotes of the week Posted Feb 8, 2012 20:41 UTC (Wed) by khim (subscriber, #9252) [Link] For example, Perl supports both »if (EXPRESSION) { COMMAND }« and »COMMAND if EXPRESSION«, with identical semantics. Using one or the other, one can put different emphasis on either the COMMAND or the EXPRESSION (much like one can use word order for emphasis in many natural languages), and that can actually make code easier to read on a subtle level. Nope. One rarely need to merely read code (i've not ever seen people who like to read couple of perl files before going to bed). One reads programs to change them. And while these subtle differences may create better-looking code they hinder this activity: it's very easy to only look for “if (EXPRESSION)” and miss these “if EXPRESSION” cases. (Of course not everybody appreciates this.) I've seen people who appreciate the ability to write such code, but when faced with the need to read it… multitude of choices actively hurt. This may be good for a book (because it makes it possible to use for expressive purposes), but the same thing in real programs is usually source of frustration. If that was in fact the case, then why is there still new code (not just extensions to existing projects) being written in Perl, and why is Perl itself being developed further (including new features only useful to new code)? Quality of language is not the only reason to choose it. For example I'll be first to say that C++ is horrible language (may be even worse the Perl) but I'll recommend it in many cases because it's advantages outweight it's disadvatages. Perl may be disaster but CPAN is pretty nice, for example. This appears to indicate that, even in the Python world, convenience or efficiency are sometimes valued higher than intellectual purity. It's the same thing as with any choices: if all versions of doing something are actually pretty common then there are no problem since reader will be familiar with all them anyway. If one choice is overwhelmingly more popular (or if some people prefer one and other people prefer another) then it's better to have it as one and only choice.
Quotes of the week Posted Feb 8, 2012 22:30 UTC (Wed) by anselm (subscriber, #2796) [Link] One reads programs to change them. Yes, but it's not unusual to have to read a few hundred lines of code to find the correct place to change a few lines. So there is something to be said for code that is easy to read. Both forms of »if« are pretty common in Perl, and although other languages don't use it a lot, »COMMAND if EXPRESSION« is easy enough to understand even if you haven't come across the feature. You don't have to take a Perl class to figure out what it might mean. multitude of choices actively hurt. You know, I'd really like to see some hard evidence for this. So far we have nothing but you claiming that this is the case. I have 25 years' worth of Perl programs that suggest otherwise. if all versions of doing something are actually pretty common then there are no problem since reader will be familiar with all them anyway. It is fairly safe to say that in Perl, both »if (EXPRESSION) { COMMAND }« and »COMMAND if EXPRESSION« are »pretty common«, so I would agree that their simultaneous existence is no real problem. There may be other language features where this is not as obvious, but the same applies to other languages, such as Python. For example, in Python there are about half a dozen ways of iterating over the lines of an input file, and the officially recommended method has changed several times during the existence of the language. Readers of Python programs of different vintage are likely to encounter all of these methods and may have to educate themselves about them even if the official method is now different. There are various ways of opening and closing files, where the newly recommended method (using »with«) is quite a recent invention, and people are unlikely to go back and change all their old programs to suit. So, since very few programming languages are perfect from the very beginning, you will always have a coexistence of different ways to do the same thing, since due to backwards compatibility old methods of doing one thing can't safely be abolished when a new method comes around. This applies to Perl and Python, too, and extolling Python (which is a reasonably nice language to be sure) for its purity while at the same time calling Perl a »disaster« is, at the very least, shortsighted. A lot of important code has been written – and is being newly written – in Perl; people who pick Perl over Python etc. for new projects usually have their reasons; and nobody has appointed you (of all people) judge as to which programming language is best, so we might as well stop here and agree to disagree.
Quotes of the week Posted Feb 8, 2012 22:32 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
a side effect of the fact that arrays and hashes in perl are references is that it allows you to create very powerful data structures very easily
I have one program that has an array, where each element of the array is a string plus a variable length array of two element arrays, one element of which is a string and the other element is a number
This sort of thing is trivial to do in Perl, but much harder to do in most languages.
Quotes of the week Posted Feb 9, 2012 22:13 UTC (Thu) by HelloWorld (guest, #56129) [Link]
> Perl just always rubbed me the wrong way. In Python, or Ruby, or any other reasonable language, you can print a list just by doing "print mylist" or similar. In Perl, you have to remember some magical mumbo jumbo or else it just prints out a number.
I have no idea what you're talking about. my @x = (1,2,3); print "@x"; works just fine.
> But in Perl, you have to worry about dereferencing "refs," creating refs, and all sort of syntactic garbage. I'm using a VM, everything is a pointer-- stop bothering me about your stupid implementation details.
|
|||||||||||||