|
Re: Perl fan being tempted with Python
by merlyn (Sage) on Jun 16, 2005 at 17:25 UTC
|
Perl is suited for some people, Python for others.
Just like some people get more done with a really clean desk, and others require a messy desk.
Neither is more "right".
| [reply] |
|
|
| [reply] |
|
|
Can you think better about what you're doing when you have no written materials on your desk to support your thoughts? My thought would be Perl (and other) programmers do not rarely have clean desks... But that's just from looking at mine and my colleagues' desks...
--------------------------------
An idea is not responsible for the people who believe in it...
| [reply] |
|
|
|
|
Re: Perl fan being tempted with Python
by Fletch (Bishop) on Jun 16, 2005 at 17:34 UTC
|
Python is more OOPy, but its warts(*) make it too much of a putoff for me (IMHO). If you want a more "pure" OO language, I'd look at Ruby. I'm playing with it now (specifically Ruby on Rails) and I'm liking it much more than when I toyed with Python.
Either way you should try and pick up at least one of the two; it never hurts to be at least conversant in another language (more resumé fodder :) and it'll help you improve as a programmer to be familiar with another way of looking at problems.
(*) Things that specifically bugged me were:
- the whole whitespace has semantic meaning depending on how much of it there is thing; yes, with a good editor it's more transparent, but it renders python -e "..." type stuff useless and that's something I use Perl for frequently
- up until the recent 2.x branch namespaces and scoping were horrible; I haven't looked recently but this has improved somewhat (so I've heard)
- trailing commas have different meanings in different contexts (append/don't append newline on print statements, vs list/tuple in assignments)
- lambda doesn't produce a real closure; something like Ruby's blocks is going in sometime, but given the infamous (possibly apocryphal) statement by Guido that he didn't see what anyone would use closures for I don't hold out much hope
I know that some of these have been addressed, but on the whole Python's still . . . *shudder*. Ruby's much more yummy.
--
We're looking for people in ATL
| [reply]
[d/l] |
|
|
Is that really true, closures will be removed from python (can you provide a link to Guido's statement?) If so, I would strongly advise against learning such a crippled language. To me it sounds stupid to remove such a important and basic high-level feature (that I use a lot (in lisp and perl), I might add).
| [reply] |
|
|
No, they're actually being added in a form inspired by Ruby's block mechanism (but with a wonky (IMHO) syntax, go figure). And I can't find an actual quote, but I'm in good company recalling that's how he felt (see this interview with MJD where he recounts something similar; last paragraph of his first response). My point was that I'm not hopeful for whatever implementation gets shoehorned on given the past view he's expressed towards the concept.
--
We're looking for people in ATL
| [reply] |
|
|
| [reply] |
|
|
Python only has semantic initial whitespace - most people find that it stops being painful after an hour or so. Unlike Ruby (at least it did the last time I looked) it doesn't have semantic whitespace in the middle of lines... If you don't want to pass spaces in on the command line, use "\t" instead.
2.1 (with nested scopes) has been out since 2001.
Your complaint about trailing commas being context dependent is just... silly. If you've a one element tuple, most people will wrap it in brackets for clarity.
Except in a few specific cases, named functions are preferred to lambdas. You can have perfectly good named closures, just not perfectly good anonymous ones (you can do anything using lambdas, but the end result is pretty disgustingly unreadable).
Blocks won't exactly be rubyish - they're to simplify resource allocation and release, and won't be used everywhere the way that ruby's blocks are.
That said, I think it's fair to say that more Perl programmers will prefer Ruby to Python.
| [reply] |
|
|
Python only has semantic initial whitespace - most people find that it stops being painful after an hour or so.
Indeed.
Unlike Ruby (at least it did the last time I looked) it doesn't have semantic whitespace in the middle of lines...
Where does Ruby have this? Never noticed it myself (which may be more of a comment on my observational skills ;-)
Your complaint about trailing commas being context dependent is just... silly. If you've a one element tuple, most people will wrap it in brackets for clarity.
Well, not silly exactly. While much Python is laudably clear, I also find the trailing comma convention for print/tuples vexing. Most languages train you to treat trailing commas as semantically insignificant. It took a long time to persuade my eyes to notice them in Python.
No more annoying than many things in Perl though.
It also illustrates one of the major differences between Python and Perl. In Python "tuple-ness" comes from the comma operator. In Perl "list-ness" comes from the list context of the expression. If you come to one language from the other it can be confusing either way. Python folk stare at the right hand side of the expression when they should be looking at the left in Perl. Perl folk stare at the left side and wonder where their @ symbols have gone :-)
Except in a few specific cases, named functions are preferred to lambdas.
True. But is that because named functions are better, or because the implementation of lambda sucks? The expression/statement distinction that applies to lambda and not named functions seems complicated and evil to me.
Even if true removing anonymous functions just because they're not often appropriate doesn't seem like a good decision to me, and can lead to some pointless redundant naming of functions.
That said, I think it's fair to say that more Perl programmers will prefer Ruby to Python.
Yeah, that seems to be true in my experience.
| [reply] |
|
|
|
|
Re: Perl fan being tempted with Python
by kirbyk (Friar) on Jun 16, 2005 at 17:29 UTC
|
The bulk of the differences in OO Support are illusory. In Perl 5, there's very little you can't do that you can in OO-only languages. The main legitimate complaints are that it's extra work to really encapsulate objects - you absolutely can do it as well in Perl as in other languages, but it's a bit more involved than just using a keyword.
Perl 6 should fix even those complaints, but as it's not actually here yet, that's of somewhat limited use.
I don't think this is a very good reason to not use Perl. We're running a top-50 traffic website off of OO Perl (and real object oriented, not just functions grouped together) at WhitePages.com and get great performance.
Ultimately, I think the Perl vs. Python question comes down to: Do you think it'd be a great world if everyone HAD to format their code exactly the same way or it wouldn't compile? If you say yes, go ahead and try Python. If you don't want your style in the compiler, stay with Perl. This is a more substantial test than any actual OO implementation differences.
| [reply] |
Re: Perl fan being tempted with Python
by jeffa (Bishop) on Jun 16, 2005 at 17:33 UTC
|
I didn't really understand OO until i learned Perl's way of handling OO. I wouldn't jump ship to Python merely for OO, because quite frankly i think Ruby is far better than Python when it comes to clean OO design. But who says you can't stick with Perl and study Design Patterns? In fact, if those folks who suggest something other than Perl have not read that book, i wouldn't even listen to them. :)
| [reply] |
|
|
Yes! Actually encapsulation made objects completely obscure to me, until I started OOPerl I really didn't get it at all (Java is the worse), simply because perl shows you object guts, instead of hiding them away as much as possible...
| [reply] |
Re: Perl fan being tempted with Python
by shemp (Deacon) on Jun 16, 2005 at 17:34 UTC
|
I have chosen not to learn python mainly because perl already suits my needs, like what merlyn said. OTOH, my new roommate is a python developer, and he and i have had numerous friendly perl vs. python discussions which usually end up trying to find little nit-picky things that one language or the other is better at dealing with.
This has definitely led me to an interest in python, but i still have not learned the language, even while surrounded by the roommates extensive python reference library.
I will definitely say that there are issues with OOPerl, but they have not been enough to get me to change languages after 11 years of programming perl.
I would wager that with just about any language, if you get to know it well enough, you'll be able to find things that are truly problematic, but as with everything in life you work around them.
So i must agree with merlyn, use what suits you. | [reply] |
Re: Perl fan being tempted with Python
by revdiablo (Prior) on Jun 16, 2005 at 18:33 UTC
|
Since your direct question -- about Perl's vs Python's OO -- seems to have been addressed a few times, I'd like to talk about the languages more generally. You can safely ignore this post if you want to concentrate entirely on the OO issue.
After knowing Perl for upwards of 7 years, I've been using Python for a few months now, and I think it's a fine language. (For those that wonder, I still use Perl at home, but at work we're doing Python.) The oft-discussed differences -- such as semantic whitespace and lack of messy syntax characters -- are just superficial. In my experience, those "features" become unimportant fairly quickly. They don't impact my feeling on the language one way or the other, they are just the way things are.
There are other differences in the languages that I think are more important for actual work. The scoping rules, assignment rules, and typing system are probably the biggest I've run into. There aren't as many differences as one might think, but these things matter for real code, and the issues are sometimes subtle. Frankly, I don't know Python well enough to enumerate all the differences, but I have had problems with my Perl-think not translating directly. Obviously I feel more comfortable with the Perl frame of mind, but the Python way doesn't seem inherently inferior, just different.
Language differences aside, there is also the question of the community. I don't think there's anything for Python quite like Perl's CPAN. I also don't know of a Python site anything like Perlmonks. These things may exist, and I just don't know about them, but I don't think they do. I have, however, had good experiences with the #python IRC channel on Freenode (which is actually split up into two separate channels that you get sent to randomly). So again, I'm not entirely convinced that either community is better or worse overall, but there are undoubtedly some important differences.
In short, there are differences. The differences are both real and superficial, but in the end, both languages are plenty capable. I would definitely advise learning Python. I think it's a good idea to learn as many languages as you can. Even if you decide to continue using Perl, seeing things from a slightly different perspective will be a really good experience.
| [reply]
[d/l] |
|
|
| [reply] |
|
|
| [reply] |
|
|
The online Python Cookbook may be helpful
There's also PLEAC, which is a reasonably comprehensive translation of the most common bits of the Perl Cookbook's code (Python and Ruby have ~65% each).
The best online resource, though, is comp.lang.python
| [reply] |
|
|
| [reply] |
Re: Perl fan being tempted with Python
by coreolyn (Parson) on Jun 16, 2005 at 18:17 UTC
|
| [reply] |
Re: Perl fan being tempted with Python
by ikegami (Patriarch) on Jun 16, 2005 at 18:04 UTC
|
What's not native about Perl's OO?
It supports object creation natively:
bless({}, $class);
It supports inheritance natively:
$child->parent_method()
It supports method calling natively:
class->method(); # Static
$obj->method(); # Virtual
$obj->class::method(); # Non-virtual, Inherits
class::method($obj); # Non-virtual, Doesn't inherit
As a derict result of the above, encapsulation and polymorphism is natively supported. Perl doesn't support security divisions, but that's just a luxury (or a curse).
| [reply]
[d/l]
[select] |
|
|
#!/usr/local/bin/ruby
class Numeric
def secs_to_minutes
self / 60
end
def minutes_to_hours
self / 60
end
end
puts 86400.secs_to_minutes.minutes_to_hours
Usually what's meant by "pure OO" (which is what I presume the OP meant by "native") is that everything is an object. In Perl (and Java, and C++) there are underlying primitive data types which aren't first class objects in their own right (granted Ruby cheats with small integers under the hood :).
Update: Tidied up wording
--
We're looking for people in ATL
| [reply]
[d/l] |
|
|
What's not native about Perl's OO?
Answer:
bless({}, $class);
The fact that you have to build your own objects reusing other bricks, and some spit named bless gives a strong impression that OO is bolted on to Perl, and not native. A Larry has said, OOP was an experiment in how minimalist one could design OO.
The syntactical sugar for calling methods doesn't make objects "native". There's no object type in Perl, I can't subclass integers or arrays (unless you call the 'tie' mechanism 'subclassing').
I'd call OO in Perl workable. But not native.
| [reply]
[d/l] |
|
|
The fact that you have to build your own objects reusing other bricks, and some spit named bless gives a strong impression that OO is bolted on to Perl, and not native.
Impression? maybe. I'm not sure how that matters. Besides,
bless({...}, $class); looks just like new class(...) (C++'s syntax) to me.
A Larry has said, OOP was an experiment in how minimalist one could design OO.
True, but this has no bearing on whether objects are native or not.
The syntactical sugar for calling methods doesn't make objects "native".
That's an odd statement. Something which is part of the language's syntax is sugar, and not built-in? Acknowkleding it's part of the syntax makes it builtin!
There's no object type in Perl
Then how come ref says it's an object?
I can't subclass integers or arrays (unless you call the 'tie' mechanism 'subclassing').
You can't do that in C++ or Java either.
| [reply]
[d/l]
[select] |
|
|
Re: Perl fan being tempted with Python
by dragonchild (Archbishop) on Jun 16, 2005 at 22:04 UTC
|
I write in Perl because I can get what I need to do done faster and better than in any other language I have used or been exposed to. In essence, the stuff I do for a living could be construed as a poster boy for when to use Perl. So, I have no reason to use any other language.
That said, if you can do what you need to do faster and better in <insert language here>, then use it! I use Perl, but that shouldn't sway you one way or the other. You use the right tool for the job.
Real-world analogy: I recently put up a fence. I ended up using 5 different tools, just for one project. I think there's a lesson to be learned there.
- In general, if you think something isn't in Perl, try it out, because it usually is. :-)
- "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"
| [reply] |
|
|
I recently put up a fence. I ended up using 5 different tools, just for one project. I think there's a lesson to be learned there.
That it's really hard to put up a fence? {grin}
| [reply] |
|
|
| [reply] |
Re: Perl fan being tempted with Python
by johnnywang (Priest) on Jun 16, 2005 at 19:58 UTC
|
I've also only started coding in Python recently. I haven't run into anything that really bothers me. Contrary to other people's feelings about the whitespaces, I actually like it.
Besides my desire to learn another language, my main reasons were:
- Jython: since I do enough java programming, jython is sometimes useful.
- Twisted: I want a event-driven framework, although I've used POE, Twisted seems to be more advanced and provides more for what I want.
- GUI: Perl/TK is nice, but I simply can't live without such widgets as browser, the fact that Open Source Application foundation is building its Chandler with python and wxWidgets gave me more confidence (although Chandler hang on me.) I know there is a perl binding to wxWidgets too, just haven't tried it.
| [reply] |
Re: Perl fan being tempted with Python
by halley (Prior) on Jun 17, 2005 at 12:33 UTC
|
I get a kick out of all the people who gripe about Python's "context sensitive whitespace" rigid structure. Have they never edited a .conf file which depends on line-by-line organization? Have they never seen a Makefile? Shell script? How about Prolog? FORTRAN? COBOL?
FORTRAN and COBOL are line-oriented languages because data used to be stored on punchcards. One punchcard is one line of text. FORTRAN reserves the first 6 columns of each line (card) for continuation markers, comment markers, and line labels. Everything has to be indented to the 7th column, unless you're using a modern loose derivative of FORTRAN. COBOL took that even one step farther, demanding certain indentation levels for nested conditions, and on some statements, a redundant NUMBERING which indicated how much indentation the line had.
It's not better or worse, it's just different. After so many token-stream languages like C, C++, PostScript, Java, Perl, SGML, you might get to think that that's the only normal way to code. No, it's just the current "in" thing to do with the current "in" parser tools. There are many other languages and file formats where the most natural way to read is line by line.
--
[ e d @ h a l l e y . c c ]
| [reply]
[d/l]
[select] |
|
|
I wrote a really witty rejoinder to this on a punchcard, but I can't seem to find a reader for it on any of my machines . . .
The problem is not that it uses whitespace, it's that the amount of whitespace has semantic meaning. Yes a Makefile uses whitespace, but so long as there's one initial tab it doesn't make any difference what amount of additional whitespace precedes the command. And I can't think of any shell where the amount of whitespace makes a syntactic difference.
No one's saying you can't use the amount of whitespace as a semantically significant portion of your programming language, but the fact that pretty much no one does any more might mean something.
Update: OOOOH, you caught me AM. Thanks for showing the one corner case that proves that Perl is just as guilty. I'll have to go delete the part where I said Perl was completely wartless itself.
--
We're looking for people in ATL
| [reply] |
|
|
The problem is not that it uses whitespace, it's that the amount of whitespace has semantic meaning.
It doesn't quite change the semantic meaning, but Perl thinks the programmer uses the amount of whitespace to have different semantic meaning:
$ perl -wcle 'print("foo")' # 0 spaces
-e syntax OK
$ perl -wcle 'print ("foo")' # 1 space
print (...) interpreted as function at -e line 1.
-e syntax OK
$ perl -wcle 'print ("foo")' # 2 spaces
-e syntax OK
| [reply]
[d/l] |
|
|
Re: Perl fan being tempted with Python
by Skarn (Beadle) on Jun 17, 2005 at 03:13 UTC
|
I hate to say it but python seems to be 'winning'.
My palm pilot which I am never far from runs python.
New cell phones run python.
Google uses python a lot, and they have many more really smart people than most web companies.
Perl's there is more than one way to do it is good for many things, but for some packages like wx it is nice if most everyone does things the same way. I think python is easier to do guis because there is less ways to do it.
Of course context sensitive white space is insane, reminds me of BASIC.
| [reply] |
|
|
It's the 6 vs half dozen argument.
I think what makes perl powerful in many situations is the many ways to do it. It makes things possible. The just one way to do thing method in some languages make doing certain tasks near impossible. This makes it easy to learn a one way to do it language, easy to implement, easy to debug and a pain to do anything outside of its box. Perl is flexible, and that means you can do alot with it.
As for winning or losing this is why I am a huge supporter of the concepts in Parrot. If Parrot gets off the ground everyone wins, which means for people who have invested time in different languages they have a common interpreter to use. And for people that need to migrate from one their applications from one language to another they have a platform from which to do the changes by function, object, subroutine without losing the whole thing.
And to me that is where the perl community wins, it sees a need for change and starts out to create a tool for everyone not just the perl community. Because the perl community in general sees perl as one of many tools.
Now I am not a code guru or even big on Parrot or Pugs at all. But this is what the talk in the mailing lists and news groups are selling me, and my play with parrot is beginning to tell me that the perl community has the right idea on this. But time will tell if the right idea will become the right reality.
"No matter where you go, there you are." BB
| [reply] |
|
|
but for some packages like wx it is nice if most everyone does things the same way
Between python and perl, the gui situation is practically the same.
The python wx interface is not as stable as the perl wx interface.
| [reply] |
Re: Perl fan being tempted with Python
by tlm (Prior) on Jun 17, 2005 at 16:50 UTC
|
Here's an informal critique of Python that I found interesting.
Last time I looked at Python it couldn't handle closures. Maybe this has changed (I don't know) but at the time that was a deal-breaker for me. More generally, from what I remember, Python's support for scoping and namespaces sucked compared to Perl's.
(Also, I vaguely remember that, at the time at least, the Python and Perl culture's were markedly different. For instance, TMTWOTDI wasn't highly valued (and obfu or golf even less) among Pythonheads, IIRC.)
None of this is meant to discourage you from learning Python. On the contrary, I encourage you to. The purpose of posting this is to alert you to the things to be looking out for as you learn the language. I think that being aware of a language's shortcomings from the beginning is one way to optimize one's learning of it.
| [reply] |
