Perl or Python ?
 

Whats its best to learn, Pear or Python ?

This topic is subjective and argumentative. The only solution to your problem, is to learn both and then find the one best suited for yourself.

Perl gives you a lot of ways of doing essentially the same thing. This is a feature that Perl users are proud of.

Python is deliberately more terse, requires a specific type of indentation, and has no way of indicating the end of a function.

If you want ultimate flexibility at the cost of having to spend more time choosing which method you want to use to solve a problem, use Perl.

If you are more interested in solving problems quickly and don't mind being forced to write your code in a specific style, use Python.

The difference is that Perl has in it much more from functional programming paradigm ( http://en.wikipedia.org/wiki/Functional_programming ). Python is slowly catching up (i.e. Python 3.* vs Python 2.*).

I find the functional features quite convenient.

This may sound odd, but in order to appreciate Perl read on Higher Order Perl: http://hop.perl.plover.com/ .

I'm learning both. I'd like to say "know", but as it is, there's so very much I don't master yet (in both languages) even though I do get results and have built up scripts/programs that are hundreds of lines long. The thing is, neither was very difficult to learn and neither took long to learn to use. Pros: I can now work with either of them, depending on which one I have available or want to use or suits better for the given situation. Cons: knowing only one would probably have been sufficient, so I've "thrown away" some time by learning both. Not a con really.

In short, learn both of them. You're not going to lose anything. Instead if you only learn either one, but not both, you very probably will be haunted by the thought "was this really the best choice?" for the rest of your life, or up to the point where you do learn the other as well.

Next question you're going to ask is "should I learn Python 2 or Python 3, or Perl 5 or Perl 6?". Answer: all of them :)

I am looking at Perl6, and my feelings are getting sadder and sadder, even though they've made a usable release. The sad feelings about Perl 6 are coming from its early testers' reports - it is slow and bloated, though it shouldn't necessarily be.

And the main developer wrote that strict typing, when used, makes the code slower though conceptually it should enable faster code.

So, my intent to learn OCaml instead of Perl 6 steadily grows; Perl 5 is still my favorite language at the moment.

Most programming languages are very similar. Make sure that you learn enough to be able to read both Perl and Python. Then read, read, ... read software learning coding styles and common patterns
of statements and expressions.

As with natural languages (English, Greek, Persian, etc), it is much harder to learn to speak and write the language than it is to hear and read that same language. As you read, you'll find that either Perl or Python suits your personal style.

Cheers,
~~~ 0;-Dan

there's more than one ways to do it. But some ways are not obvious and "beats around the bush" before solving the problem. There should be only just one obvious way to do it without beating about the bush.

Indentation to the first timer may seem irksome, but it all takes time to get used to. what do you mean by "doesn't know how to end a function"?

Do you have any specific problems with Ruby? It seems like a very good language to me, and it borrows ideas from Python, Perl, Smalltalk, etc. I've been having a hard time making a decision between Ruby and Python, but Python is used so much and for so many different things that it seems like a better language to learn as far as existing software being written in it or using it.

I am in the learn as much as you can group, although as pointed out in earlier posts this can make it difficult to become a guru in any language
quickly. I agree with Dan's post too that most languages use a commonish ground work (not trying to start a flame here) so to this end you can also look at it that
if you become accomplished in one language it will generally be less of an arduous task to learn another.

I am using Perl since 1993 or 1994. Until very recently Ruby used to be very slow.

What can Ruby do Perl can't ? I mean not only built-in functions, but things like closures, anonymity, scoping rules and the like.

...

I've been looking closely at Perl6 because I want a language which allows both loose and strict typing - Perl6 allows. It looks like I'll look for strict typing in OCaml, and will still be using Perl5 for loosely typed programs.

Because as a person who knows Perl I also know that a string can be split both using 'split' and regular expression, and because Python allows both these ways two, there is more than one way to it in Python too.

wrong. Python's split doesn't allow regular expression. It shows you don't know Python enough to fairly comment on this. If one wants to use regex, he has import the re module and then use re.split(). Python's design encourage one to produce consistent code.

An example out of the many, see this FAQ for Perl to count substrings. True to Perl's mantra, there are a few ways to do it as stated in the FAQ.
With Python, there is only one obvious way (note the word obvious),
Another example, you can open filehandles with 2 ways, one with brackets, one without
In Python, you only need to use one way.
These are examples of why Perl can encourage inconsistency in code programming.

you really have no reason to argue with me on this point of "more than one ways in Perl vs that in Python", if you have used Python long enough as you had used Perl.

I didn't mean that. I meant that using regular expressions (not in the 'split'' function) a string can be split - because matches in regular expression can be collected in buffers (what in Perl is called $1, $2, etc).

So, conceptually there is a 'split' way to split a string and a regular expression way to split a string - both way are present in both langauges.

So, as I said, there is more than one way to do it.

There's more than one way to do it, but sometimes consistency is not a bad thing either (TIMTOWTDIBSCINABTE). You can follow TIMTOWTDI mantra all you want, that's your business and i don't care.

When you read a book on OO, you read on multiple constructors and polymorphic functions - both these categories essentially promote "there is more than one way to do it".

I am too lazy, but if to dig deeper, I'm sure I'll find in Python "there is more than one way to do it" in many more places.

The key word is "obvious". Please do "import this" in Python interpreter for Python's zen. There's a difference between "obvious" and an all out "there is more than one way to do it."

tell me which one to you is obvious in these Perl statements (and don't try to evade this question as well).

How about the many different ways to write "if/else" construct?
which one is more obvious? In Python, there is only one (obvious and best) way to do it
And how about the many different ways to write for loops (including foreach etc etc) ? and the many different ways to ...... the list goes on


Sure you can find one of two Python's "more than one way to do it" , but when it comes to how many there are, Perl beats Python all the way.

I suggest learning both. I haven't really tried Ruby much, maybe it's good. You can learn it too if you like.

And I agree with Sergei Steshenko's comment that you should read "Higher Order Perl" to really understand what it's all about.

You contradict both my own personal experience, statements made to me by other Perl users over the years, and statements made by the original author of Perl.

You misquoted me. I said
If you don't understand the difference between your misquote and what I said, please do not comment any further.

The statement I wrote is not directed at you. Its just an additional comment with regard to the wiki you linked about TIMTOWTDI.

Maybe you are right. "no way of indicating" doesn't really mean "doesn't know how to" (or does it?)
don't give comments that are half truth and leave people guessing what it means next time.

Nevertheless, you still didn't explain the "no way of indicating end function" statement.

If I write a C function, the brackets indicate the start and end of the function body. The same goes for a Perl subroutine. Python functions have a clearly defined beginning, but no clearly defined ending. For example, the following code is one Python function:
That code produces
Supposedly, the indentation rules are all I need to understand Python code. However, I find that the lack of any function-end indicator makes it hard for me to read Python.

Python actually has an "end of function" indicator. That is the indentation stack containing value of 0.
I guess everybody is different. If you have used Python for years and still couldn't get used to its style, then its not for you.

Your criticism of Perl is obviously insufficient. There is more than one way to criticize Perl. In the context you forgot to mention Perl 'Switch' capability as yet another way to write 'if-then-else': http://perldoc.perl.org/Switch.html .

I actually like the indentation and whitespace being important in Python. To me, it makes it look very neat and doesn't make it hard to read.

That is all the same syntax.. one way of doing an if statement, infinite ways of formatting it.

that's why all these ways (TIMTOWTDI) of formatting lead to inconsistency. that's my point.

And Python indentation are seen as "wacky" by some folks:

http://utcc.utoronto.ca/~cks/space/b...honIndentation
.

At all, if I understand it correctly, the indentation may be whatever number of spaces, just returning to previous level of indentation must have the same number of spaces, i.e.

.

Here is a thread about an indentation error:

http://bytes.com/topic/python/answer...nt-comphrehend

- though the thread is not about 'break', I find the code unreadable because of the way 'break' (line #36, #39) is indented. And, if I understand it correctly, there is more than one way to select indentation of 'break'.

yes, that's right. It can be whatever number of spaces (standard is 4), but they must be aligned if not it will fail to run. Every Python programmer will have to align them properly to make their code run, which in turn the whole script will turn out nice and easy to read and maintain. And there is nothing really "wrong" in returning to the same number of spaces (indentation level). Example,

if you write it in Perl with good coding practice,

versus one that is written like this


Which one would you prefer ? A good Perl programmer would want to re-indent it nicely anyway.

Neither.

I indent this way:

.

Regarding "there is more than one way to do it" - just everything in programming after the Turing machine proves that there is more than one way to do it.

that's hell ugly, but that's your business and i don't care.

I did not say i don't agree there's more than 1 way to do it, turing machine or not. I am only saying some ways "beat around the bush" (not obvious) to get to the solution, while some is straight to the point (and the best way).
I can't help it you don't see it that way, because that's your business and i can't be bothered.

Indentation of 'break' in the URL above looks hell ugly to me.

People often ask questions in this forum not reading any documentation at all. I.e. the core problem is not obvious/non-obvious, it is not knowing any way at all.

the core problem is, you, actually, for not understanding the whole point of our "discussion". this is last post of mine having to deal with this topic in this thread.

TIMTOWTDI is good since you can have more choice, BUT will lead to inconsistencies and sometimes problems that can be solved in the most obvious way become messy and obfuscated. This will happen in any language that follows this philosophy, not just Perl.

But Python does have this philosophy too, for example:

http://www.ibiblio.org/g2swap/byteof.../for-loop.html
http://floppsie.comp.glam.ac.uk/Glam...ipting/19.html

- both 'for' and 'while' loops exist, though conceptually only 'while' loop is necessary.

yes and not just Python. Every other languages as well. However, Python philosophy encourages this:

There should be one-- and preferably only one --obvious way to do it..
Read it carefully. If you don't understand English, look up the dictionary or thesaurus.



That is true for every other languages that support these 2 kinds of loops. So what's really your argument here? Do you want to say that long time ago, the functions of these 2 loops should be merged? And that programming languages should remove all for loops and let programmers use while loops only ? for and while loops have been in existence for many generations and its not the argument here of whether or not we should do away with one and use just the other.

Let me fill you in if you are still clueless.
Can you please look at my argument again on why Perl encourages inconsistencies. See post #17. I can find you some more in perlsyn: different ways to write for loops in Perl

Now, in Python, the consistent(obvious) way to write a for loop has always been


My illustrations support my point that TIMTOWTDI is good sometimes, as you can see from the Perl's different for loop syntaxes that programmers can have choices. But because of this, code is inconsistent. Lastly, its not just Perl , but any other languages with TIMTOWTDI philosophy will encounter this "issue". You may disagree for all i care, but that's how it is


Its just one of my observation with regard to "TIMTOWTDI" after using Perl and Python for so many years. You don't have to really get so heat up with me about this.

Now, can we stop?

I hopefully understand English. I just know that the word "obvious" means different things to different people.
...
Look into C++ 'boost' library - IIRC they've implemented FOREACH a-la Perl - because people like it. I.e. people like to be able not to deal with numeric index while iterating over array.

At all, look at other than Perl/Python languages - and then you will see that Perl simply borrowed a lot of ideas from them. For example, 'maxima' has a notion of current expression/variable:

, so Perl's $_ and loops (not)based on it are so minor :). Or, let me put it another way - after 'maxima' (which in its term is heavily based on LISP and is implemented in it) what Perl does looks so obvious.