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?
Python: Threat or Menace?
chip on 2000-04-10T21:04:11
I think Python has some things to teach us about language design, but mostly by negative example. (Whitespace-dependency: Bad. No equivalent of "use strict" or "my": Bad. Etc.)
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.
Abigail on 2000-04-10T22:47:28
I've never seen much point in the discussion "Perl or Python"? And unfortunally, most participants in the discussion know at least one of the languages not well enough to contribute something worthwhile. Many Pythoners don't come further than "too much punctuation", while many Perlers don't come further than "the mandatory white space". I don't know about others, but if all you can come up with against a language is "mandatory white space", I wouldn't program in any other language anymore.
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
chip on 2000-04-11T00:03:04
Abigail writes:
- 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.
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:
-
Rule: "Don't Try To Force People"
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:Don't Try To Force People
bfree on 2007-06-05T16:28:35
I agree with Abigail entirely - use the right tool for the right reason. If you choose to use Python because it enforces a particular coding style, or its syntax simply makes more sense to you - great.
My distaste for Python stems from the fact that it breaks with C/C++ syntax - without adding any new functionality that is not already supported by Perl, Java and JavaScript. If you are going to change paradigms and learn a new language, Ruby makes far more sense, as it actually offers new features not offered by these languages.
Another consideration regarding Perl vs Python: performance. Benchmarks show that Python has some serious issues dealing with arrays. To work around this problem, developers have introduced a ctypes module, and Python has recently introduced NumPy (Numerical Python) arrays - however, performance continues to lag in certain applications such as OpenGL.
I use Perl mainly for building LAMP-based online services - which relies heavily on string handling and templates (blocks of text with embedded variables/functions). Perl is designed/tuned for this.
Python automatically adds an EOL at the end of each print; if you disable this, it automatically adds a space at the end... you end up using write, instead - it feels like programming in BASIC. Python's print provides no way to enable unbuffered I/O - you need to flush each call. You need to convert lists to tuples before you can print. There's no easy way to embed variables within a multi-line text block (Perl's qq).
For all the positive things that one might say about Python, string handling and output is not one of them.
A personal nit is the lack of a way to ifdef out code for prototype/debugging purposes. In Perl you can just wrap your code block in an "if" - in Python, you have to reformat the entire code block, then reformat again once you remove the ifdef.
The one positive thing I would say about Python is that it forces all parameter passing to be by reference, rather than by value - which is a good thing in an interpretive language (that's not to say you can't do this in Perl, as well).
This is offset by the fact that there is no easy way to retrieve a key from a hash (dict) reference - you are forced to enumerate the dict - whereas in Perl, you can treat a single-element hashref as an arrayref to retrieve its key - and this becomes critical in Python since you can only pass by reference.
Re:Don’t Try To Force People
Aristotle on 2007-06-05T22:32:46
The one positive thing I would say about Python is that it forces all parameter passing to be by reference, rather than by value
Err, so does Perl. The common idiom is to copy the elements of @_ to lexical variables, but @_ contains aliases, not copies. (You could use Data::Alias to carry over the aliasing nature into the lexicals.)
there is no easy way to retrieve a key from a hash (dict) reference – you are forced to enumerate the dict – whereas in Perl, you can treat a single-element hashref as an arrayref to retrieve its key
I think I know what you’re trying to get at, but it doesn’t make sense the way you’re saying it. What is a single-element hashref and how do you treat one as an arrayref? To retrieve it’s key… what? You’re probably trying to say something about slices here, but I’m not sure.
Re:Don’t Try To Force People
bfree on 2007-06-05T23:41:22
What is a single-element hashref and how do you treat one as an arrayref? To retrieve it’s key… what?
I recently had to port a 3rd-party benchmark from Perl to Python... it was passing a list of arrayrefs to a routine that included a single element hashref (amongst other data) within each arrayref. The routine needed to retrieve the key of the hashref in order to determine which test to run.
While it's a valid question _why_ the benchmark code was doing this (during setup, not execution) - rewriting their benchmark code was not an option. Here's a distilled comparison:
PERL
$test = {test5=>50};
$key = [%$test]->[0];
PYTHON
test = {'test5': 50}
key = test.keys()[0]
In the case of Python, you need to enumerate the hashref via keys; with Perl, you just recast the ref, since Perl hashes are simply specialized arrays.
Yeh - I know, a pretty obscure case - but it's a realworld situation I had to deal with recently.
Re:Don’t Try To Force People
Aristotle on 2007-06-06T00:01:19
You’re doing no such thing. Treating a hash as a list enumerates it. In fact, the Python code is clearly better. The Perl equivalent would be:
$key = (keys %$test)[0];
This is also how it should be written. Whoever wrote the original code didn’t know Perl very well.
(Why any of this is relevant to pass-by-reference, I still don’t know.)
Re: Stupid Programmers Considered Harmful
jjohn on 2000-04-11T00:32:21
One of the reasons I posted this article is because I'm tired of the habitual Perl slander:
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)
chip on 2000-04-11T00:39:27
I sympathize with your frustration over the 'habitual slanders'.
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
ziggy on 2000-04-11T04:21:08
One of the best reasons I can think of for a Perl lifer to learn Python
is simply because it's Not Perl (tm). A good Perl programmer lives by
TMTOWTDI, and Python is simply another
WTDOI.
Among the recommendations in The Pragmatic Programmer (extracts
here) 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
chip on 2000-04-11T06:58:05
OK, you got me. There's more to Python than the language, and learning it is worthwhile. There, I said it. Now if I can just overcome my distaste long enough to actually _do_ it....
Re:Learning Python is worthwhile
duff on 2000-04-11T14:20:24
I decided several weeks ago to give python a hard look and I have to admit, once I got over the whitespace has semantics thing, it really became an enjoyable language to program in. Why should a perler learn python? I don't know. Python seems to fill much the same programming niche as perl, just fill it differently. I decided to learn python because 1) Everybody was talking about it 2) lots of tools I wanted to look at and use are written in python (sgmltools, Zope, etc) and 3) just because I love to program.
A (hopefully) unbiased opinion
weisserw on 2000-04-11T14:56:20
Let me start off by saying that I don't usually read this site. I was pointed here by a python programmer who wanted more python people to join this dicussion. However I'm not exactly a "python person." I'm most comfortable in C, with a smattering of Java, Perl, Asm, Lisp and Python (in no particular order). That being clarified, I'd like to say a few words.
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
duff on 2000-04-11T16:41:02
The implementation itself [of perl] is rather unfortunete; because of how it's built you can't really implement perl in terms of itself
I've always wondered why people place so much importance on this. How often does Joe Random User implement a compiler? I'd say that Perl helps solve a certain set of problems easily and that writing a compiler isn't one of them.
... 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
I don't know what you are trying to say by the first part as software written in
any language would need to be scrutinized by security experts to be considered secure.
And as for perl being re-implemented, I take it you are unfamiliar with chip's
Topaz project.
Re:Python: Threat or Menace?
duff on 2000-04-11T16:48:51
I don't think that python's semantic whitespace in and of itself is bad. It makes programs very readable and once you get used to it, you file away "Is the indentation proper?" in your list of things to look for when there are problems. Where semantic whitespace becomes burdensome is when error messages from the compiler are so cryptic as to be useless. Python's current error messages remind me of days long past when almost every error from a C compiler would simply be "syntax error" and you had to guess what the real error was.
Re:A (hopefully) unbiased opinion
Abigail on 2000-04-11T17:07:12
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).
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
sethg on 2000-04-11T17:12:04
Perl was designed as a language to help Unix system administrators scan through flat text files of arbitrary size, gather information from such files, and report on them. When it first appeared, it was conspicuously better for this kind of work than competing languages (awk, sed, C, and the various shell scripts); therefore it became very popular among Unix sysadmins. These early users had at least a passing familiarity with C and the Unix shell, so they wouldn't have considered Perl's syntax to be a barrier to learning the language.
As Perl became more popular, some people wanted to use it for applications that were outside its design "sweet spot", but where there was no conspicuously better alternative. The Perl implementors extended the language to make these applications easier to write. This made the language more popular, leading it to be used in more situations, etc., etc.
Perl is successful, in short, because it followed the
"worse is better" principle.
Re:A biased opinion
jjohn on 2000-04-11T17:19:40
W.W.
You claim that Perl is badly designed, but fail to give examples of where its faults lie. Perl was not "thrown together from
... odd scripting languages". It was certainly influenced by awk and sed. You are throwing FUD about the security hazards of Perl. Perl 5.004 was released without CERT advisories. Now, individual perl scripts may have problems, but don't blame Perl for that.
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
pudge on 2000-04-11T20:06:34
Unfortunately, and "I don't mean to offend anyone," your statements betray a vast ignorance about Perl. That in itself is not a problem. My wife knows less about Perl than you do. But you speak as though you know what you are talking about, and therein lies the danger. I don't need to make specific points showing your igorance, others already have.
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
Abigail on 2000-04-11T20:12:58
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?
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'
jjohn on 2000-04-11T21:54:10
Ah, Pudge! Flames are half the fun!
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'
pudge on 2000-04-11T22:45:16
It was not your article I have a problem with, it is someone posting authoritatively that which is blatantly false, seemingly for the purpose of stirring up trouble.
Re:A (hopefully) unbiased opinion
Abigail on 2000-04-11T23:25:24
As such, I've moderated the post down as flamebait.
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:Python: Threat or Menace?
chip on 2000-04-12T00:42:42
Well, I think the semantic whitespace
is bad in itself, because self-contained code structures no longer
look self-contained.
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: Nothing like a good arse kickin'
chip on 2000-04-12T00:44:56
I hope that flames will not become the norm here, because I'd rather stay than leave.
I find your behavior...
weisserw on 2000-04-12T01:37:06
...extremely disturbing, but I suppose it's only natural for people to abuse their power to further their own agendas. No, I really didn't mean to offend anyone, althought it's sometimes hard for me to tell because I don't get offended easily, especially not over a trivial thing like the strengths and weaknesses of a programming language. If you find yourself that upset because someone has said bad things about Perl, then you ought to examine yourself and what you consider important values.
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??
:-)), but if you want to just bask comfortably in the safety of your programming enclosure, you're welcome to do that as well. I'll just be elsewhere...
-W.W.
Insults can be calm.
chip on 2000-04-12T08:59:42
OK, here's an exercise. Compare:
- If we keep things civil and don't resort to slanderous methods, we can at least make the flaming dignified.
And contrast:
- I suppose it's only natural for people to abuse their power to further their own
agendas.
Here endeth the lesson.
Re:I find your behavior...
pudge on 2000-04-12T14:55:36
Sigh. You wrote
I don't think it's really fair for you to say "I don't need to make specific points showing your igorance", but that is not what I wrote. The entire sentence was
I don't need to make specific points showing your igorance, others already have. While that comma should have been a semicolon, I think the point was still clear: others showed how your post was ignorant, so for me to do it would be redundant. But because I am a nice guy, I will be redundant on request.
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
...
." This is patently false. Abigail already addressed this.
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...
duff on 2000-04-12T15:34:23
how come no [one] in this thread is defending python?
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'
melora2000 on 2000-04-13T17:45:03
I agree with that. I have just recently begun to learn Perl, after years spent with C, C++, Asm, and (of late) Java. I appreciate its power in coping with text data and files, and as a CGI scripting language. I don't know much about Python, and I would like someone to honestly answer the question "What is Python best used for? What are its strengths?" rather trying to bash Perl. I'd like a comparison which describes what each language is best used for (which would be helpful information) instead of a laundry list of complaints about one or the other (which is, for me, useless).
Thanks for setting up use.perl.org, and I hope it can take a more positive turn!
Re: Nothing like a good arse kickin'
dcarrera on 2002-07-12T22:17:38
I don't know much about Python, and I would like someone to honestly answer the question "What is Python best used for? What are its strengths?" rather trying to bash Perl.
I am a Perl lover, but I do have Python experience and I'll try to answer your question. This is all an opinion ofcourse.
Python has excellent OO. That's what I like most about the language. Python is not terribly fast. It's best used on projects that are not speed-critical (like most applications).
I think that it's an ideal language for GUI design. GUIs make more sense in OO and they are not speed-critical.
Python is very clean and easy to read. I find the language restrinctive. Some times simple things are made complicated. Ultimatelly, which ones those are will depend on personal preference.
I hope this helps,
Daniel.
Style and politeness
Just a couple of comments.
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
pudge on 2000-04-19T12:01:53
1. It is not obvious that people mean things as opinions in all cases. It was not obvious to me that he meant it as an opinion. I don't know him at all, and cannot even hazard a guess as to what he meant. And I think evidence suggests that it was not meant as merely an opinion, because he obviously doesn't know enough about Perl to hold to such an opinion.
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
Theory on 2000-04-19T16:41:49
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.
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
