use Perl Log In
Perl v. Python: Can't we all just get along?
Without the heat of some other sites, I'd love to read a discussion on why a Perl lifer should give Python a whirl. There seems to be much rivalry between these languages, and I for one would like to see more cross-talk and integration. What do you all think about this?
Perl v. Python: Can't we all just get along?
|
Log In/Create an Account
| Top
| 34 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Python: Threat or Menace?
(Score:1, Interesting)( Last Journal: 2006.07.27 20:51 )
More significantly, I think, the (d)evolution of the Python community's vaunted politeness teaches us, again, that: The Center Cannot Hold; Things Fall Apart. Perl's community being as fractious as it is (as we are!) is evidently inevitable, simply because it has grown too big to remain tight-knit.
I think it's worth noting that Guido has recently stated that he's going to rewrite Python from the ground up, a project he's calling "Python 3000". I'm sincerely flattered.
Python is a nice language.
(Score:1, Interesting)( Last Journal: 2007.01.03 9:20 )
I don't have much against Python. It's a nice language. If I wouldn't already know Perl, I'd certainly code a lot in Python. Main reason I hardly code in Python is that it doesn't offer me much that Perl hasn't, and it just isn't worthwhile to become as fluent in Python as I'm currently in Perl. Two big plusses for Perl compared to Python: better error messages and warning (personally, I find Pythons errors cryptic and less suitable for beginners, although it by default gives a trace where Perl doesn't), and Perl has better documentation. Python 1.5.1 doesn't even come with any documentation by default; you have to install that separately. This is specially important since "core Python" is much smaller than "core Perl", even for simple things, you'd need to pull in a module. And unless you know your modules very well, you need to consult the documentation to find out which module to pull in. (Recently, I wanted to use sleep. It wasn't in os, or sys, or even in posix, but in timer (IIRC), which took me half an hour to find out.)
Big wins for Python: a much, much cleaner OO system. While Perl took Python's OO system as a basis, in its implementation it took every wrong turn possible. Also, Python has less of "it is this way because it's the way of the C API" as Perl has. Python is probably easier to learn than Perl, certainly for people without a Unix background. For a coding project that consists of a group of relative novice programmers, from a varying background, I'd prefer to use Python than Perl. But then, because Python doesn't have something like use strict; (as mentioned by Chip), other options like Ada or Eiffel should be looked into as well.
For individual programmers, I do not think the question "which is better Python or Perl?" is a reasonable question. To be a good coder in Perl, you need a specific mindset. Perl is a rich language, full of special cases and shortcuts. It's great for large groups of people. But that isn't good for an even larger group of people. Many people are much better of with a language that forces you to do things in a specific way, that has stricter rules on doing things. For those people, Python is much better. Frankly, I think that many of the people currently struggling with Perl are much better of coding in Python. The Python community should do more advocacy. (And of a different kind than "Perl sucks")
-- Abigail
Don't Try To Force People
(Score:1, Interesting)( Last Journal: 2006.07.27 20:51 )
If this choice is based on personal preference, that's OK with me. But if this choice is based on a misguided notion of Python being somehow intrinsically better because of its being simpler, more regular, etc., then it is wrongheaded and sets a dangerous precedent. I think Stroustrup said it best:
Programmers are smart people. They are engaged in challenging tasks and need all the help they can get from a programming language as well as from other supporting tools and techniques. Trying to seriously constrain programmers to do "only what is right" is inherently wrongheaded and will fail. Programmers will find a way around rules and restrictions they find unacceptable. The language should support a range of reasonable design and programming styles rather than try to force people into adopting a single notion.
This does not imply that all ways of programming are equally good or that C++ should try to support every kind of programming style. [...] However, moralizing over how to use the features is kept to a minimum, language mechanisms are as far as possible kept policy free, and no feature is added to or subtracted from C++ exclusively to prevent a coherent style of programming.
I am well aware that not everyone appreciates choice and variety. However, people who prefer a more restrictive environment can impose one through style rules in C++ or choose a language designed to provide the programmer with a smaller set of alternatives.
-- "The Design and Evolution of C++", page 113
So, sure, if someone wants to use Python, I say: More power to you. But if someone else wants to evangelize Python by specifically claiming that it takes the programming equivalent of the moral high ground, well, then I get out my axe and start grinding away. With no apologies.
Re: Stupid Programmers Considered Harmful
(Score:1, Interesting)( http://taskboy.com/ | Last Journal: 2005.08.06 19:34 )
1) No one can write maintainable Perl code
2) Perl has (awful syntax|wonderful line noise)
3) Perl is too much like (C|AWK|BASIC)
4) Perl's OO is sloppy, therefore useless
Now, if Python really was Fred Brooke's silver bullet to slay the software engineering beast, I'd be shouting the word from the roof-tops. Python is does not significantly reduce the complexity of software development. "Cleaner" or more restrictive syntax may aid newbies, but it more likely hinders experienced programmers. Bad habits aside, there are usually more ways to express a solution correctly than a traditionally orthogonal language may lend itself to. B&D style tools like Java, which have an amazing paranoid class protection system, seem to implicitly doubt the ability of its users. Although there are probably good uses for it, "finalizing" a class to me is the height of arrogance. Better to say "none can improve on this fabled code!".
I come from a traditional Pascal/C procedural programming background. Although I was shown how
to implement hash tables and topological sorts in these languages, I didn't really *understand* them until I saw them in Perl. Perl hide the accidents of a particular language and underscored the purpose of algorithms/data structures.
Maintainable code is not the responsibility of the compiler. Just as grammar should not be the province of word processors. The human behind the machine needs understanding.
I like Perl's OO. A lot. Conway's OO Perl book demostrates that Perl is no second class OO language. I realize this seems like a bold statement, but I want to encapsulate data structures and move on. Let's leave policy decisions to users. Isn't that the Perl way?
Adopt a Python (Advocate)
(Score:1, Interesting)( Last Journal: 2006.07.27 20:51 )
Perhaps you could adopt a Python advocate. I've adopted one. I got him to agree that he would never write anything negative about Perl unless he fact-checked it with me first. So far, I haven't seen him write anything new that's negative about Perl.
Learning Python is worthwhile
(Score:1, Interesting)( Last Journal: 2006.11.01 18:21 )
Among the recommendations in The Pragmatic Programmer (extracts here) [pragmaticprogrammer.com] was "Learn a new programming language every year." (p14) I do not interpret this to mean start writing a C compiler in Scheme just because this is the year to learn Scheme; rather, examine new approaches to solve the same old problems. Over time, exposure to languages like Scheme (or Python, or Eiffel) should help your everyday work in Perl (or C++ or Java). After all, how many of us started using closures in Perl without seeing them first in something lisp-like?
Of course, there are many things a Perl programmer-for-life will find disturbing about Python. (The converse is all too true.) My expectation would be that there are good things about Python that are applicable outside Python. Determining what they are and adopting them (perhaps in a more Perlish fashion) should make a Perl programmer better over time.
Repeat this exercise with C++, Eiffel, etc. Of course, a Python programmer who takes this recommendation to heart should eventually learn Perl to seek out the good bits about Perl for the same reason.
Chip pointed out that Python serves as a negative example in programming language design (at least, to the Perl programmer's eye). Making a determination like this is a valid [personal] conclusion to this exercise, but not the only one. Python is more than a syntax, and passing judgement exclusively on the syntax would be short-sighted. What about the documentation? What about the standard library? What about the community?
If nothing else, this recent Python Advocacy episode has reminded me to be an even-handed Perl advocate and not promote Perl at the expense of another Open Source project.
Re:Learning Python is worthwhile
(Score:1, Interesting)( Last Journal: 2006.07.27 20:51 )
Re:Learning Python is worthwhile
(Score:1, Interesting)( http://www.pobox.com/~duff | Last Journal: 2006.06.09 10:10 )
A (hopefully) unbiased opinion
(Score:1, Interesting)First of all, I don't want to offend anyone, but Perl really is an example of the most horrible way to design a language. I say "design" with tongue-in-cheek, because the language wasn't really designed so much as thrown together from pieces of odd scripting languages (many of which should have been put to rest long ago). The implementation itself is rather unfortunete; because of how it's built you can't really implement perl in terms of itself (well I suppose you could, but not with a slight measure of self-respect), the entire system needs to be scrutinized by security experts before any program written in Perl can be considered secure, and it is doubtful that Perl will ever be re-implemented ever again.
That being said, Perl is at least useful for many things ("practical," I believe it's called). People always tell me how they use it for system-administration tasks (for some reason I don't seem to engage in enough adminitration tasks to require perl's help, or if I do they're all suitibly mundane), and it does have an impressive ability to cope with string data (not something I'd base a language on, but at least it stopped people from using SNOBOL).
Now Python on the other hand is almost completely a different story. It's supremely orthagonal and elegant in its design, with support for functions as first-class types, an enforcement of clean coding standards through whitespace sensitivity (most Perl coders object vehemently to this because it infringes on their ability to write really ugly code), etc.
But the problem is that Python suffers from a lot of Perl's problems and adds a few of its own: you can't implement it in itself, it has no strong typing (even Perl's use strict is ridiculously better), an OO system with no support for data hiding, etc. etc. And that brings me to the biggest problem: Python doesn't really have a niche to fill. The CGI space has been seemingly co-opted completely by Perl (at least until people start using PHP), and it's too dog-slow to be used for real CS applications. As a beginner's language it's ideal, but that's not going to help it be taken seriously when it comes to real computing tasks.
If the python developers made some tweaks to the type system and added a real compiler, then I would advocate that most software engineering be moved there. As it stands it's an original language which is a lot of fun to program in, and still has lots of unmapped potential to it.
So where does that leave us, now that I've managed to piss EVERYBODY off? Well, I guess I conclude by saying that if you read this and got a sudden urge to throw a molotov cocktail through my window, then you're really taking one language too seriously. If you blind yourself so much that you can't see the faults in Perl or , then you're really no use to anyone in your community, in particular the users who depend on you to build solid, well-rounded applications. Don't be a Python zealot or a Perl zealot; be a programming zealot, learn as many languages as possible, and which one to use in a given situation. That's all I have to say.
-W.W.
Re:A (hopefully) unbiased opinion
(Score:1, Interesting)( http://www.pobox.com/~duff | Last Journal: 2006.06.09 10:10 )
Re:Python: Threat or Menace?
(Score:1, Interesting)( http://www.pobox.com/~duff | Last Journal: 2006.06.09 10:10 )
Re:A (hopefully) unbiased opinion
(Score:1, Interesting)( Last Journal: 2007.01.03 9:20 )
I disagree. Perl was certainly designed. However, it was designed by someone (Larry Wall) who was first of all not a typical computer scientist, but someone with a very strong background in linguistics, and second, he wasn't to pride to borrow many ideas from other languages. Perl wasn't thrown together; pieces were carefully selected and gathered. And Larry also spend time to details I've never heard other language designers did. The fact that the three loop control keywords, next, last and redo are all the same length isn't a coincidence. Perl was designed with the idea that the language (and compiler) should adapt to the mindset of a human. A mindset that isn't regular. That is used to context sensitivety. A mindset for which there is more than one way to do it isn't an alien concept.
The entire system needs to be scrutinized by security experts before any program written in Perl can be considered secure
Now, that's a bold statement and it doesn't do Perl justice. Sure, one can argue that a program written in any language needs to be scrutinezed before it can be considered secure. But there are features about Perl that aren't found elsewhere. Most (Unix) security holes come from buffer overflows. You *cannot* have a buffer overflow in a Perl program, and the last time a buffer overflow was reported in perl (the program) dates from years ago. And which other language does have the concept of tainted data, that requires you to scrutineze it before you can use it in a possible harmful way? Which other language automatically does extra checks when it determines it's being run as the superuser? Or has a build in guard against exploiting a race condition?
Now Python on the other hand is almost completely a different story. It's supremely orthagonal and elegant in its design, with support for functions as first-class types, an enforcement of clean coding standards through whitespace sensitivity (most Perl coders object vehemently to this because it infringes on their ability to write really ugly code)
Which is pure bullshit, as I can write ugly code in Python as well. One doesn't have to use newlines to terminate statements in Python. If Python really, really wanted to enforce "clean" code with mandatory whitespace, it would have made whitespace really mandatory, and not have colons and semicolons.
I've never found the white space rules in Python horrible. I can live with it, and 95% of my Perl code uses white space in the same way Python finds acceptable. However, sometimes I find a program becomes clearer if you aren't as strict about whitespace. I find that lining up things vertically can make things stand out more; but that can mean the left margin isn't a straight line.
-- Abigail
understanding Perl's design, or lack thereof
(Score:1, Interesting)Re:A biased opinion
(Score:1, Interesting)( http://taskboy.com/ | Last Journal: 2005.08.06 19:34 )
You claim that Perl is badly designed, but fail to give examples of where its faults lie. Perl was not "thrown together from
You seemed to equate the ability for a language to implement its own compiler as the acid test for a 'real' language. There are other reasons to use a language. My own criteria for the superiority of a language is development speed. I rather get a job done quickly than fuss over the accidents of the implementation language.
People do get hung up on 'data hiding'. I often wonder how valuable this is for the compiler/interpreter to enforce. Isn't simply documenting the API enough? Programs that use internal, non-published interfaces deserve all the trouble they get.
Perl is compiled. Python is compiled. Java is compiled. This should not concern the user of the language. Do these create OS specific binaries? No. Do you need OS specific binaries? Sometimes, yes. Many times, no.
BTW, the perl is being re-constructed in C++. Ten years of a 'real language' like C have taken their toll.
I agree with your admonishment about zeoltry. When all you have is a hammer, every problem looks like a nail.
Re:A (hopefully) unbiased opinion
(Score:1, Interesting)( http://pudge.net/ | Last Journal: 2007.06.05 18:22 )
Sigh. I really don't want this to turn into a place of flames, and I commend those who haven't engaged in flames. But I would be much happier if people did not speak authoritatively, derogatorily and ignorantly all at once. Because these types of posts are what almost all flamewars are built on.
As such, I've moderated the post down as flamebait. Please, fellow users, tell me if you think this is wrong way to handle it. We are still in beta and feeling our way out here.
Re:A biased opinion
(Score:1, Interesting)( Last Journal: 2007.01.03 9:20 )
You want data, and more importantly implementation hiding because you do not want to publish those things in the API, and force yourself to never ever be able to change your implementation because someone using your stuff depends on it.
Unfortunally, with Perls (and to a lesser extend with Pythons) OO, this is not possible. In Perl, you need to know how an object is implemented before you can subclass succesfully; if you inherit an object that's implemented as a hashref, you then as well use the hashref, and then the implementation of the inherited object changes (but not the API) that it uses a arrayref, you're screwed. And you need a thick book like Damian's to do something simple as data-hiding. Data hiding is important, not to prevent someone from reading your data, but to prevent yourself from overwriting someone elses data. One of Perls slogans is "making easy things easy, and hard things possible", but when it comes to Perl OO, I prefer the phrase "making trivial things hard".
-- Abigail
Re: Nothing like a good arse kickin'
(Score:1, Interesting)( http://taskboy.com/ | Last Journal: 2005.08.06 19:34 )
In any event, I posted the article in good faith. I was hoping some Pythoners would rationally explain the benefits to the language, or what problems Python excels in solving. I still hope this comes out.
Re: Nothing like a good arse kickin'
(Score:1, Interesting)( http://pudge.net/ | Last Journal: 2007.06.05 18:22 )
Re:Python: Threat or Menace?
(Score:1, Interesting)( Last Journal: 2006.07.27 20:51 )
But I know some people aren't as hung up on graphical appearance of code as I am, so I don't make a huge point of it in most discussions.
Re:A (hopefully) unbiased opinion
(Score:1, Interesting)( Last Journal: 2007.01.03 9:20 )
All articles have score 1 in this thread, although some are marked "interesting" or something else. Also, my User info page has conflicting information about the score of some articles.
-- Abigail
Re: Nothing like a good arse kickin'
(Score:1, Interesting)( Last Journal: 2006.07.27 20:51 )
I find your behavior...
(Score:1, Interesting)I don't think it's really fair for you to say "I don't need to make specific points showing your igorance". I'm willing to back up my opinions, even if you aren't. I haven't seen any worthwhile rebuttles on this thread so far; I have seen some supportive comments as well as a couple remarks on the security issue which I think missed the point (the problem is not buffer overflows in perl code, it's that afaik, the perl interpreter itself has never been audited). In any case, simply saying that I am ignorant is not very convincing to me that I needed to be moderated down.
The line between a flame and constructive criticizm is thin -- maybe even nonexistent. But if we keep things civil and don't resort to slanderous methods, we can at least make the flaming dignified. I posted here originally because I thought to you perl guys wanted some honest feedback on your language (and python too -- how come no in this thread is defending python??
-W.W.
Insults can be calm.
(Score:1, Interesting)( Last Journal: 2006.07.27 20:51 )
And contrast:
Here endeth the lesson.
Re:I find your behavior...
(Score:1, Interesting)( http://pudge.net/ | Last Journal: 2007.06.05 18:22 )
1. You say "Perl really is an example of the most horrible way to design a language". This is either flamebait or an ill-conceived attempt to deceive, as you are framing it not as an opinion, which it is, but as fact, which it clearly is not. Many people a hell of a lot smarter than either one of us think it is very well-designed. You don't like it. So what? Just because you don't like it, it is horrible? This is typical of a Python advocate in my experience. Take what you do not like and say it is wrong, instead of chalking it up to a difference of point of view or preference.
2. You say, "I say 'design' with tongue-in-cheek, because the language wasn't really designed so much as thrown together from pieces of odd scripting languages
3. You say, "the entire system needs to be scrutinized by security experts before any program written in Perl can be considered secure." Abigail and duff addressed this.
4. You say, "it is doubtful that Perl will ever be re-implemented ever again." duff addressed this.
So, there is my proof that you don't know what you are talking about and that your post is flamebait. I personally do not think this post is necessary, because I think all of the above is pretty self-evident.
This site is in beta and has been online for less than a week, I think, and we are trying to feel our way through how to deal with posts to keep the level of discourse at a certain level. And I asked everyone here to tell me if they think the moderation was out of line. I don't think those are the actions of someone who is abusing power.
The only agenda I am furthering here is to have a calm place to discuss Perl, a place devoid of untruths and flamebait like what you posted. Criticism is fine. Abigail is full of criticism for Perl, its community, its users, its modules, etc. And I love seeing her criticism, even when I disagree vehemently. But her criticism is not full of untruths as yours was. Yes, we want honest feedback, but that has little to do with what you wrote. Your post was either flamebait or "authoritatively" ignorant, and either way, such posts are not appreciated, in my view.
__END__
Re:I find your behavior...
(Score:1, Interesting)( http://www.pobox.com/~duff | Last Journal: 2006.06.09 10:10 )
Because python doesn't need defending. Nor does perl. This isn't a contest for supremacy on the grand totem pole of programming languages. Perl has merits. Python has merits. Perl has ickiness. Python has ickiness. I believe this thread started with "why would a perler use python?" To answer that, we have to highlight the good and bad in both languages. Because after all, TMTOWTDI, including not using Perl.
As an aside, I notice that many of the python evangelists that I run into seem to have this same sort of "contest" mentality. I wonder why? Is it just because Perl has a dominant position in terms of widespread use (particularly for CGI) and they are trying to knock Perl out of a niche?
Re: Nothing like a good arse kickin'
(Score:1, Interesting)Style and politeness
(Score:1, Interesting)Later in this thread Pudge points out that W.W. stated opinions as facts.
I actually get irked by people telling me to precede all my opinions with an explicit identifier. If I say 'Monet is bland' it is pretty obvious that it's my opinion that Monet is bland and that I'm not attempting to state as a fact that Monet is in fact bland. This is obvious because in intelligent conversation we accept that everyone knows subjective responses to art are always opinions, not facts.
I run into this at work where I say 'we should buy x, it's better that y' and people reply 'that's just your opinion'. I mean Geez, of course its my opinion that's what I'm paid for.
My second point is that politeness can and should be used to hide a multitude of sins. I personally have no problem with posts that make outrageous statements and untruths, since they can be replied to with a counter opinion, thus enlightening innocent parties travelling the thread.
What I fail to understand is why people have to be rude while they are at it. I cannot see a reason to ever call any poster anything at all. If a poster posts something wrong, then post the right thing, but for Gods sake don't post "you're ignorant" as a coda.
Re:Style and politeness
(Score:1, Interesting)( http://pudge.net/ | Last Journal: 2007.06.05 18:22 )
2. I do have a problem with posts that make outrageous statements and untruths, because they waste our time. And sometimes the truth comes to late; some people see the first posts and not the followups.
3. I don't think I was rude. I called him ignorant, but I don't see how that is rude. I am ignorant about PHP and Python, and someone saying that of me would not be necessarily rude to say so.
Re:Style and politeness
(Score:1, Interesting)( http://www.justatheory.com/ | Last Journal: 2005.07.19 12:05 )
Yes, but there are more diplomatic ways of saying it. Most people don't like to be told that they're ignorant (it does have a negative connotation, after all), but most of us don't mind being told that we misunderstand or that we have been given misinformation or that we may not have heard about some other important information - and here it is!
I realize that diplomacy is a four-letter word to some people, but it really can go a long way toward good communication. And we need to be especially careful online where other communicative cues (body movement, facial expression, etc.) can be missed.
David