Slashdot Mirror
Perl vs. Python: A Culture Comparison
davemabe writes "Every programmer has a favorite scripting language. Here is a well written article by Jon Udell from byte.com detailing the differences between Perl and Python, their cultures, OOP, database access, philosophies, and which one will gain the most converts in the future. Very interesting reading on an almost religious debate. "
One annoying thing about Python is that indentation is parsed for statement-grouping purposes. Just like makefiles. It's a bad idea for languages meant to be written by humans.
If Python uses whitespace to separate code blocks, does it treat tabs and spaces the same? Must you indent exactly N spaces? What if I tab-indent one line and then space-indent the next?
cpeterso
Perl Monger: Python bites!
Python Hacker: BS! Perl sucks!
Repeat ad nauseum ...
Eric
How long will it take for this thread to dissolve into mindless zealotry? I suggest 10 posts max.
In the article, the author notes that: "As much as I admire Perl, I would never recommend it to a beginner". I'm just not certain this is valid.
Yes, Perl is a very complex language, but its high level abstractions allow the student to focus on the way algorithms work without getting too boggled by implementation. Python also allows for these while providing a "cleaner" OO interface.
Please, lets use these two great OSS tools in peace and harmony. There is rivalry here simply because the languages are more similar than not.
Check out Circuit Cellar Ink , and Embedded Systems Programming. Both of these are pretty decent techie print rags. Good stuff, by and for hackers.
make world, not war
The areticle does talk a lot about Perl and Python but in the end ends up talking about the Python Killer App, Zope http://www.zope.org If nothing else everyone should give Zope a once over. It as some really powerful features that should be making waves and M$ ASP, IIS and Vignette sites. BZ
I am more versed in Java than anything else... so bear with me. Why does he classify Python under the scripting languages?
I *am* looking for a script language but was evaluating Perl, JScript for a prototype. Is Python really a scripting language? do these features transpire in JPython?
any info appreciated.
The real mnf999 always posts as anonymous coward
UnrealScript RULEZ!
I've worked with Python a little before and this is one of the first things that bit me. AFAIK, it parses tab-indents and space-indents differently and thus Python won't parse code with mixed tabs and spaces as indents.
[Seoman] "A conclusion is simply the place where you got tired of thinking."
nothing will ever replace QBasic in my heart. Its not the size of your compiler, its what you do with it. i used mine to reverse engineer windows.
macgeyver could have saved the world from certain destruction at the hands of an evil terrorist with it.
I think the difference between python and perl can
simply be explained that perl is about getting
something done, no matter about how messy or
incorrect the method used may be, while python is
about doing things correctly 1st time, for later
use. Its the difference between grafting OOP into
a text processing language or including it from
the start.
Theres more than one way to do it, but theres
usually one correct and proper way. Python tends
to the second part of that, imho. Its also got a
more readable and less misused syntax, albeit
its use of whitespace is at the other extreme from
perl's fit it all into one line with no carraige
returns in sight. (if its not like that, your
likely not using perl to its tersest extent.)
From someone who has dabbled in both and used
neither significantly.
George Russell
in another amazing cultural comparison, it has been shown that perl users are three times more likely to pour bowls of hot grits down their pants than python users. thank you.
Tcl/Tk is so wonderful, I don't see why anyone would bother using another scripting-type interpreted language.
Gotta quick question -
I use Microsoft's DAO to move my data from program to program. Would Python or Perl allow me quick access to this data, sorta like VB, but better?
At least Python has a better namesake.
Ok, if Microsoft was going to start making something that didn't suck, then why would they make vacuum cleaners? Vacuum cleaners DO suck. I think your sig is incorrect. Please refrain from ever using it again. Thank you.
While the thought of java for desktop applications is enough to make by intestines clench, server-side java is quite nice.
You get to throw away the heavy, over-wrought, and redundant AWT/Swing classes and stick to the core classes. Most are very well architected and if sun were to fix the numeric and collection classes, as well as define a standard subset of the Java platform for server apps, the battle would be over today.
Sun isn't that smart a company and it will be a few years before someone like IBM wakes up and defines a new standard without sun's intervention.
TCl/TK 8.0 is fantastic. Why doesn't it get the respect it so rightfully deserves. I can integrate all kinds of functional code with quick gui widgets that stand up. All scripters need to buy a TCl/TK book and code for a month. You'll see. Oh, it runs MUCH better on Unix, particularly Linux, where it is part of the distribution. Winbloze! Hey, when is somebody going to burn a huge M$ flag on TV. I'm still waiting for that to happen. Maybe I should do it myself 8}
if there was a poll, python or perl, i would vote perl, but if the poll was python,perl, or tcl/tk, tcl forever!
no.
Python does treat them differently. A tab is arbitrarily set equal to 8 spaces. However, it is hard to screw this up since compilation to bytecode will fail if it is inconsistent. Also, there are tools like tabnanny to watch out for things like this.
I picked a book on programming python last year almost on a whim and I'm sure glad I did. As a person familar with c programming at the time with no where near a mastery of it I found learning pythong extremely easy and very enjoyable. The thing that I like most about python is the ease at which you can protype a program (quickly) and then convert your python modules over to c if you feel the need for more proformance. After just a skim of the tutorials just about anyone can be pumping out scripts in no time. Python is a combo of ABC, modula-3 and C. The ABC aspect can be seen in the way in which you need to format the program leading to a clean looking/readable code (every time). I recommend the language highly to anyone (not just the technically inclined)
$world_opinion = ~s/(python )rules/$1sucks/ig;
$world_opinion = ~s/(perl )sucks/$1rules/ig;
What is this news posting going to accomplish, other than encouraging flamefests?
I'm not familiar with the Perl newsgroup, but I read the Python one regularly. It has been a friendly, open and sharing community... but over the past few months has experienced trolls that seem intent on disrupting the newsgroup.
Python is good. Perl is good. Different strokes for different folks. Python is based on some hard research into reducing errors and increasing maintainability; Perl seems to be based on accomplishing as much as possible using as few keystrokes as possible.
Both have their application. Both have their strengths and weaknesses.
And neither is going to benefit from the childish flamefests that seem to be popping up with increasing frequency. It would be better if Slashdot were to NOT contribute to this problem.
--
--
Don't like it? Respond with words, not karma.
Um, actually, why are you using tabs alternated with spaces in the first place?
But no, I don't think tabs are treated the same as spaces(unless your editor automagically converts tabs to spaces...)
-AS
-AS
*Pikachu*
I'd just like to throw in my two cents about Python's indentation. I know that this has been endlessly discussed and flamed, but I just can't help myself. Let me start by saying that I like Python and I think the language is well-designed. I really like writing quick GUI apps with pygtk and having lists, dictionaries, WWW libraries and the like available.
With that said, I don't think I would ever write a large project in Python because of the extreme syntactic significance of whitespace. Python boosters always say that it avoids "indentation bugs" (as you can get in Perl, where the indentation of a block doesn't match the actual block boundaries). They also claim that with a good editor it's a non-issue. I don't buy these arguments.
For one thing, if you want to move code from one place in your program, you run into trouble. I use emacs, and with perl-mode (or cc-mode) I can just cut, paste, and then do an indent-region. With python, I have to figure out how much the code needs to be indented in its new place and make sure I line it up correctly for things to work.
Second, my more minor quibble is that it's substantially more painful to split long lines in Python. If you have a long subroutine call in perl with lots of parameters and a long subroutine name, you can split it across multiple lines however you like without thinking about it. In Python, you have to take care about how you put newlines into long lines.
I really believe that the significance of whitespace in Python cuts down on my productivity when coding Python. If someone came up with a Python preprocessor that let me use {}'s and made whitespace not count, I'd be the first to sign up.
Last night, I was trying to suffocate my girlfriend with a perl necklace. All it really did was get sticky and make a big mess.
But when I wrapped a Python around her neck, she turned blue much more quickly and efficiently.
Thanks to the the object oriented programming techniques of Python, my girlfriend is nice and blue today.
Thanks Python!
Indentation for statement-grouping has quite some defenders, and does sometimes make sense.
For example, you usually use both curly brackets and indentation in your C/C++/Java/etc code to group statements. Brackets are intended for the compiler, while indentation are for the humans. Python simply uses indentation for both, and spares you those extra key strokes (no more Alt-9 and Alt-0 finger stretching on those non-qwerty keyboards!).
Secondly, this technique sets once and for all the layout coding practice. No more fight about where you should open the righ curly bracket.
In the end all this makes Python code easier to read, something you will appreciate the first time you must hack someone else's code.
Does Python implement closures properly yet? If not, I'll stick to my favourite language Objective CAML: http://caml.inria.fr/
Basically, it's a bad idea to mix tab and space indentation. I prefer 1 tab == 1 indent, but the official dogma on the matter is that one tab is equivalent to eight spaces. (Hence, if your editor displays a tab as 4 spaces, as mine does, it's REALLY bad to mix tabs and spaces.) Regardless of this limitation, python is my favorite language, and I've only discovred it recently.
Glyph Lefkowitz - Project leader, Twisted Matrix Labs
Writer, Programmer - Not a member of the TSU
Wow, I had no idea.
Perl is something most females wouldn't mind having....try that with a Python....
Seriously, PERL wasn't meant to have a killer app...just meant to fill all those gaps in the supposedly killer apps you already bought.
I need a TiVo for my car. Pause live traffic now.
I was a longtime fan of REXX (One of the great benefits that OS/2 provided). When I finally abandoned OS/2 in favour of Windows I needed a new scripting tools and went in search. I couldn't find a free version of REXX for Win, so I looked elsewhere, I had heard about this Perl thing, so spent some time investigating it. It certainly seemed powerful, flexible, and useful.
One day while reading Dr. Dobbs they did a small sidebar on Python and I went and investigated it. It too seemed powerful, flexible and useful, but the thing that really attracted me to it was its readability.
I find well written Perl code to be very readable, but poorly written Perl code is almost unreadable. Python code is almost always readable to me, and even when I don't do the documenting job that I should, I can usually figure out what is going on in code I wrote two years ago. I can't do that with Perl code.
Stand Fast,
Stand Fast,
tjg.
According to the thread on this topic on c.l.python, python treats all tabs as 8 spaces. Use the '-tt' command line option to give a warning that tabs & spaces are used inconsistently.
And yes, mixing tabs and spaces is evil.
dook, dook, dook!
Right, off the ropes, reversed, back elbow, elbowdrop, off the ropes with a kneedrop to the chin - 2 count. In the corner, right, right, into the opposite corner, follow lariat. Fisherman suplex coming up - 1, 2, shoulder up! That move NEVER works! Wall scoops him up for a bodyslam again - and now Wall is ready to try the Money Shot - Guido manages to bounce off the top rope, crotching Wall. REVERSE FIREMAN'S CARRY! Cover, referee "Blind" Jim Korderas in position - 1, 2, 3!!! Ladies and gentlemen, we have a NEW Champion!!!!!
Do we have a new champion in the scripting language areana? Does it matter if they're both well made products?
More race stuff in one place,
than any one place on the net.
Re: Jon Udell's: "A Perl Hacker in the Land of Python" (http://www.byte.com/feature/BYT20000201S0001)
Well, since someone else mentined it, here's a reaction I had to an
email conversation where the Udell URL was cited. Take it or leave
it... but I finally pinned down what I think is wrong with Wall's
initially rather intriguing 'philosophy':
You know in Perl the motto is "there is more than one way to do it".
Larry Wall takes this by way of a linguistics background, and wants
to make Perl resemble a natural language. In contrast--at least at a
syntactic level--Python has fairly clear rules about what something
*has* to look like, and there tends to be a high degree of
orthogonality (which Wall vehemently eschews). There were some
remarks like this in the article. (Obviously, in terms of semantics,
large-scale design, and algorithms, there are many ways to do a thing
in any language).
I think Perl succeeds in what it is trying to do. For that reason,
it really does often look like a "write-only" language. You can
easily express your own "thoughts" fluidly and naturally... the
problem is that they are then as difficult to unpack later as a poem
or a complex philosophical sentence (good uses of natural language).
The thing that Wall &gang seem to miss is the distinct registers of
natural language. The whole thing is very rich in expressivity, and
highly non-orthogonal. But that is absolutely *NOT* the case when it
comes to specialized areas of natural language where clarity and
precision are at a premium. I *WANT* air-traffic controllers to
speak in a highly structured, syntactically and lexically limited,
and stereotypical fashion! I really *DO NOT* want them to use free
verse! To a somewhat lesser extent, I also want programming specs or
technical documentation to follow a rather rigid pattern. When I
look in the help file, it makes my life a lot easier if the list of
parameters to a function are always described under the same heading,
with a consistent and fairly small subset of English words, and with
an attention to consistent whitespace, layout and special characters.
The moral is that Perl is a great language for *implementing*
haiku... but Python is rather better at implementing functional
specs.
Yours, Lulu...
Buy Text Processing in Python
I feel like a freebsd user who finally read an article that talked about freebsd rather then linux. :-)
As you can tell I am a huge fan of python. I am currently learning perl but it can be real cryptic sometimes. This is especially true if you use perl at work and you are trying to read someone elses code. Yeuck!
I have always prefered basic over c (yes basic is as powerfull as c. Just because you used it to first learn programming for basic stuff like "hello World" doesn't mean thats all it can do. My father wrote a optical recogntion program that reads bar codes written tottaly in basic), c over lisp by far, and python over perl because I prefer something thats powerfull but is clean, logically and concise.
When I I first wrote programs with perl, I learned how to write things in a certian way but some of the other guys at work prefer to write parts of the same program in a totally different way and its nearly impossible to learn every possible way to code in every situation.
I love python because I can read a co-workers code and he or she can read mine. One of the things I like about linux is that the OS is more simplier and consistant then NT. Clean, simple and consistant is what I prefer in my computer environment. Something huge and powerfull doesn't bother me, as long as its not overly complex like Windows win32 api/MFC. I believe complexity is the reason the TCO of pc's keep going up and up. WIndows is full of bugs because of the programming environment.
I know a few perl users will love the idea of several different ways to solve problems and may even use linux as an example as "..There is more then one way to solve a problem with unix" which makes this idea neat in programming as well. I can see this view point as well.
I guess its like a scale. Over simplistic things liek vb script lacks power but something like MFC, Dlls and the whole win32 environment has too much complexity that leads to bugs.
This is just my take. Try python out. Its really cool and fun!
Zope sounded interesting, but I'm also checking out Mason, a Perl-based system that is tied into mod_perl. mod_perl was perl's six or seventh killer application (and I mean application as in applying a tool to a job, not as in a packaged program). First came the power of Perl regex for text processing. Then CGI (remember CGI was pretty much born in Perl). Then came LWP, and a splash was heard round the world. How many robots and spiders are written in anything else?
Perl is slowing, though. There is a consolidation and honing of features that needs to take place, and perl resists that. In some ways, this makes me long for something like Python, but I've actually been thinking of writing a Perl variant that accomplishes some of the same goals, but aimed more at large-scale programming in performance-oriented environments. I see the main benefits of a new language design being:
I dunno. I'll probably spend a couple of months scoping other languages before making any real investment of time.
As for whitespace and style issues, I dislike Python's way so much that I've put off learning the language for years. It's just so... FORTRAN. Why, of all things would you, in this day and age, subject people to a DEFINITION of TABS?! Why not enforce variable-naming at the same time?
Actually it took a bit longer than 10 posts, looks like #12 was the first thought free post by an advocate for either side. It's a calm day here on /. today I guess.
:-)
I would have to agree that the rivalry actually comes from their similarities (like all good rivalries it would seem). It's weird how I would think that such OSS tools while being OSS in nature would promote diversity, and mostly I believe they really have. OSS has always seemed something that is intended to (among other things) bring us new options and choices where there really were none before. However without fail being similar causes some infighting between fans of either side that resembles a fight for dominance over the other (thus eliminating an option). I wonder if that says something about humanity and it's relationship with OSS.
Oh and I almost forgot PERL RULES!!!! DOWN WITH PYTHON!!!!
Actually I've never used either, but the debate has me very curious
One major point the article makes is the philosophical differences between the languages. This is best illustrated by the simple "There's More Than One Way To Do It" (TIMTOWTDI) approach of PERL versus the "Keep It Simple Stupid" (KISS)design of Python. I think this is not only valid, but possibly the most fundamental difference between the languages. Outweighing even the Object Oriented aspects.
As a programmer I am very attracted to Python's clean syntax and deceptively simple low level data structures. Within this simplicity lurks some very impressive thinking about how programming languages should be used. For example Tuples are first order objects in Python! The only other languages I know of with Tuples as first order data structures are declarative languages like SQL. (Someone is sure to tell me how I am wrong in a reply...)
What this simplicity means is that I can build arbitrarily complex structures from those simple elements and the next programmer to look at my code will be able to follow my code without too much effort. Building complex structures from simple ones is the very essense of Object Oriented design, look at Smalltalk for another example of this approach -- although Python has an arguably better syntax than Smalltalk.
On the other hand, providing multiple ways to accomplish the same action means that the programmer can choose the method best suited to the current need, both in parsimonious code and optimal execution time. In this PERL is rather like C++ which often provides 15 different ways of doing the same thing, each optimized for a different purpose. The downside of this is that you need to know every one of those 15 possible ways to get the job done and understand the reasons why any one is best suited for a particular need...
My, long winded, point is this: TIMTOWTDI can potentially provide shorter programs and better execution times, but will always result in more difficult to understand code. Moreover, many programs will not be optimally coded because the programmer who writes them will only understand 10 or 11 of the 15 ways to do things, resulting in the old "When you have a hammer, everything looks like a nail." problem. However the KISS approach ends up with more total lines of code and, perhaps, slower execution times, but the code will be more accessable and (therefore) more maintainable.
And this is why I prefer Python. Processing cycles are cheap, but programmers are expensive. I am always willing to trade one for the other. If I have to choose between a language that promotes code clarity and simplifies maintenance over another that tends to shroud the algolrithms in terse bits of bizarre sytax then I will always go with the former...
Jack
- -
Are you an SF Fan? Are you a Tru-Fan?
My bad; I followed-up the wrong message; it was directed at "possible", not you!
--
--
Don't like it? Respond with words, not karma.
If you setup you editor so that it automatically replaces tabs with spaces, you're safe.
.emacs,
For example, Emacs' users could do one of the following:
(setq indent-tabs-mode nil) in
or
M-x untabify in the mini-buffer.
And I have to agree with the author's overall general assessment. It's kind of annoying that indentation matters, but since I've always been scrupulous about that in the past, it doesn't really affect me much. At least, not until I have a line longer than fits on the editor window. :-)
As for Python's consistency... I find that to be very nice. I find perl's utter lack thereof to be highly annoying. I don't care what Larry Wall says about the problem domain, computer languages are supposed to be very precise and clean because, ultimately, what they do is describe a very precise and detailed set of tiny instructions for doing something. Of course, I'm something of a hyprocrite because I use (and sort of like) C++ regularily, but hey... :-)
Also, Python was designed with introspection and reflection in mind. This makes the whole mechanism by which scopes and identifiers are actually handled much more transparent and easier to work with than perl's. I'm designing something that sets up execution environments (complete with special namespaces) for things to operate in. I don't know how I'd even think about going about this with perl. From hints I've gotten, I suspect it's possible, but I'm betting it's a huge pain.
Need a Python, C++, Unix, Linux develop
All in all, the white space issue is one of the only things I dislike about Python, but not because it's a pain to keep track of white space (Emacs, and, I presume, 'vim' or [chuckle]vigor, do that for me). Rather, it is because it makes Python hard to embed in web pages the way you can do with PHP3 or 'eperl' or similar tools. The Python zealots say that this is a feature, that you should not mix program and display in the same file, you should instead use an approach similar to ZOPE's 'DTML' (which uses SHTML-like commands to embed the results of a Python object's execution into a web page). Personally, I believe they are too quick to deprecate the advantages of sometimes embedding short little server-side scripts into web pages.
Final comment: Despite my reference to "Python zealots", I personally avoid Perl like the plague. I will use PHP3 before I use Perl. Not because PHP3 is a great language (it isn't), but because Perl is a bloated, cryptic, messy language and proud of it. Perl is a language for dog people, i.e., people who like big, shaggy, messy critters that slobber all over the place, chew on everything, etc. and that require a lot of work to maintain. Python is a language for cat people, people who like neat, independent, self-contained critters that don't require a lot of maintenance. As you can tell from my .sig, I'm one of the latter :-).
_E
Send mail here if you want to reach me.
What about when you're editing someone else's code? Yes, automatic tab conversion is nice, but can confuse CVS since every line may be seen as changed (depending on your CVS tool.)
I've been writing a lot of Python the last couple of months and I find I cannot cope with the indentation issue without having emacs take care of it for me. It forces correct indentation and consistency with other programmers' code. Otherwise I would spend half my time twiddling the space bar!
The two monks stand side by side, facing the altar, behind which a graven image of the Great and Benevolent Tux stands with wings half spread as he contemplates the GNU/Path to True Enlightenment Through Open Source. One monk wears a single pearl upon his forehead, glimmering in the flickering light of the altar candles. The other sports a torc in the form of a serpent entwined around his upper arm. The gaze upon the image of Tux placidly, each at inner peace.
The monk with the pearl breaks the silence: "Good brother, I see your movement grow by leaps and bounds. How is this so?"
The monk with the serpent replies: "It is our more disciplined coding, brother, which more quickly leads down the One True Path of Enlightenment. Discipline of code leads to discipline of mind and body."
Pearl: "But what of tailoring the Quest to the individual? Be flexible like water, and in time, even stone will fall before it."
Serpent: "Be structured like iron, and the stone will fall faster."
Pearl: "But each mind is different, and should be allowed to find their own path."
Serpent: "There is but one Path, brother, just many ways to find it. Ours is the quickest and most sure."
The candles on the altar continue to flicker as the two monks fall into a few moments silent contemplation.
Pearl: "I am afraid I must disagree."
Serpent: "So you say, but you know the truth in your heart. Did not your order adopt the doctrine of OOP despite the conflicts with your order's earlier, strictly procedural ways?"
Pearl: "OOP is just one path of many."
Serpent: "It is the soul of the Way."
Pearl: "And so you seek to challenge the longstanding authority of the Order of the Pearl? We have existed longer, and are closer to the Truth!"
Serpent: "You wander blind in the mists, poor deluded souls, while the True Way beckons! You can yet change your $PATH."
Pearl: "You speak heresy! Leave the Holy Temple before the Great and Benevolent Tux smites you!"
Serpent: "I speak Truth, and you are but too mad to see it! I curse you and your Order! The Way of the Serpent will triumph!"
And the monk with the serpent turns and stalks out of the Temple, growling, "We will be back, and in numbers! The Temple will be ours!"
The monk with the pearl watches his counterpart leave, turning back to the altar and shaking his head. "We will be waiting, and the Great and Benevolent Tux is on our side!"
-- WhiskeyJack, on serious caffeine withdrawal.
By way of introduction, I work with Perl daily. My 'ork-place uses it extensively as part of our product (yep, we ship a complete perl5 tree with every copy) and in the test group we use Perl as glue to write all sort of automated tests.
This summer I went out and bought a copy of Learning Perl and I begen my trek down the road of Perl enlightenment. Now, since then I've written .. probably a few thousand lines of Perl code. I bought the Perl Cookbook and Programming Perl. I read comp.lang.perl.moderated, and generally and starting to really get into the Perl way of thinking. I enjoy thinking in Perl . . .
But now, I look at my scripts, and think "six months ago, I would never have been able to read this." I wouldn't have a clue how my code works. I have comments about the general flow and intent my programs, so that one could at least identify where things happen. But I've always ahered to the idea that one should not write comments like:
in C. But I feel the desire to write things like: in my Perl.What's a concientious coder to do? Comment for the newbie and end up with over-commented code? Comment for someone who has read Programming Perl? Comment for the "Just another Perl hacker" crowd?
-- Have you ever imagined a world with no hypothetical situations?
Funny, Udell and I had an e-mail conversation similar to this a couple of weeks ago. While I disagree with him on the appropriateness of Perl as a beginning language (after reading Elements of Programming With Perl), I think he's right on the money about Zope being Python's killer app. Real programming ought to be more about getting stuff done than arguing over whitespace.
Now the Everything engine is very flexible, and Slash lets you get a lot done, there's really nothing out there like Zope for Perl.
At the risk of a shameless plug, let me just say that that's why i started Jellybean.
--
how to invest, a novice's guide
I think Rexx is pretty nice. Written by humans for humans, nicely readable 6 months after you wrote it, nice string handling, etc. etc.
Oh, it's free for Linux (from IBM even). It can be found here:
http://www-4.ibm.com/software/ad/obj-rexx/
...bringing you cynical quips since 1998
I use Perl a lot; while I've read the book Learning Python, I haven't really used the language, so please correct me if I'm wrong:
It seems that the essential structure of Perl and Python is pretty similar most of the time. Okay, Python doesn't have function closures and other funky features, but most programs and libraries don't use them. Similarly, the two OO paradigms are a little different, but the basics - creating an object, simple inheritance - are the same, and this is often all you use anyway. Applying the 80/20 rule, you could say that they are pretty similar.
What would be cool is a way to call Perl libraries from Python, and vice versa. For example, Perl's DBI is said to be better than Python's database drivers (which tend to be specific to a particular DBMS). Since most DBI methods are just creating an object, performing an action, or returning a list as a result, it would be easy to write Python wrappers for them. Similarly, some cool things like wxWindows have Python bindings and no Perl bindings, but the features they use aren't particularly Python-specific. (wxWindows is written in C++.)
So how about a general interface for Python that wraps any Perl module? Then Python programmers could take advantage of the world's largest archive of reusable software, CPAN. It would be a fairly simple matter (I suppose) to load in libperl.so, tell it to load the Perl module, and then whenever a call is made to the module, marshal the arguments from Python dictionaries to Perl hashes, Python strings to Perl strings and so on. Of course many modules which depend on Perl intricacies wouldn't work here, but most modules would.
The opposite interface would be fairly similar. Since Perl's lists and hashes do not nest, you'd need to convert a Python function or method returning a list to a Perl one returning a list reference. But apart from that things should be just the same.
I'm a keen Perl programmer, and the one thing that's stopping me from trying Python out for real work is that I'd have to wave goodbye to all those lovely CPAN libraries. So could someone with more knowledge say whether a scheme like the above is possible?
-- Ed Avis ed@membled.com
Anyone who knows anything about Python knows PySol is the true killer app! http://wildsau.idv.uni-linz.ac.at/mfx/pysol.html
She said "PyTHoN iZ FoR HoBBiT MoFoZZZZ!!!!"
Yup. She had some big tits too!
in my experience this sort of thing crops up a lot in group development projects, an area where python would do well. I'm all right with language-imposed formatting restrictions since it saves developers' time of understanding and reformatting each others' code.
Anyone ever read that joke interview with Stroustrup regarding the invention of C++, and how it was actually just a ploy to raise the salaries of programmers? I doubt that's what the inventors intended, but the fact that most of the denouncements of the "features" of the language in that interview are perfectly supportable is very interesting... (not only that, but C++ is single-handedly responsible for the entire Windows community ;).
Ok, so I'm joking a little bit, but mostly not. I still think OOP isn't very useful. And as far as the Perl vs. Python article goes, use whatever gets the job done better, but non-enforced OOP is IMO definitely a good thing.
TTFN
The more things change, the more they stay insane...
I'm kinda in the same boat as the author. I've played around with Python a little, but I know a lot more about Perl.
Like the author, the forced indentation in Python isn't bothersome at all because I do it anyway with Perl. My brain would melt if I tried to read any of my code and it wasn't indented properly. Also I agree with the author about CPAN. It's unbelievably easy to grab a module, compile, and install it. If you have the cpan program installed on your computer it's often as easy as typing "install Module" -- it'll download it from one of the mirrors, compile it, and install it, often with no required user interaction. I love that.
There's something that bugs me about Python, but it's not exactly a good reason not to use it. The code just looks kinda bland to me. Almost like BASIC or something. Maybe I just have a thing for using braces or something. I dunno.
At any rate, I was still very impressed with Python. I might make the switch someday, but at this point it hasn't been able to drag me away from Perl. Python is supposed to be especially good for rapidly developing software. The software can be written in Python, then pieces can be easily replaced with faster C or C++ code later--from what I've been told at least.
One open source project that is using a lot of Python code for development is Worldforge. Worldforge is going to be a massively-multiplayer online game. Neat stuff.
numb
But I can't stand cats. Give my a well-behaved, predictable, loyal and non-shedding dog any day :) (there really are such beasts...the house stays clean as can be) Now if you really want to start a flame war, forget this Perl/Python stuff and start a cat/dog debate :)
Ita erat quando hic adveni.
Sorry, but this is bullshit. JPython is written in Java and runs the same speed (and on some benchmarks faster) than CPython. How can JPython run Python as fast as CPython, yet Java be *slower* than Python? I don't think so.
Perl's PP-bytecode execution speed is about 100 times slower than a JIT'ed Java App, just try writing a straight numerical app like a Fast Fourier Transform, or a JPEG-decoder in *pure* perl, with no XS modules that escape to C.
If you look at caucho.com, they have proof that Java servlets are faster than mod_perl.
Perhaps you are refering to the GUI widgets being slow, but the GUI widgets are just a module, like Tk/wxWindows and are just an add-on to the VM, not part of the language. Not only that, but there are numerous third-party replacements for the standard Swing/AWT widgets that run very fast.
The fact remains that Python/Perl are interpreted, and Java, while being bytecoded, is compiled on the fly to native instructions.
There are plenty of code libraries out there that demonstrate Java's relative speed vis-a-vis other interpreted languages.
Java's JMF multimedia framework demonstrates realtime MP3 decoding, and MPEG/AVI decoding in pure Java. http://java.sun.com/products/java-media
www.jcraft.com demonstrates an *XSERVER*, yes, an X11 display server, ESound server, and true-type font server written in Java.
At www.komplex.org you can see real-time "megademos" doing 3D transformations, lighting, texture, and bump mapping. With Java2, some of these run fullscreen (640x480) at 20fps.
Java Cryptography libraries demonstrate very fast encoding performance. Try writing a Pure Perl/Python RSA/DES/RC-4 library, and an SSL stack that can perform.
Yes, we know Java isn't as fast as optimized C. But Perl/Python can't beat Java unless you write a program that is almost entirely made up of calls to Perl's native facilities (perlfunc functions, regex, and hashtables). Anything that has to process a large amount of data, *and* isn't related to parsing/manipulating text, will run slow.
If you created a native-library hashtable for java, and native library string and regex libs, Java would exceed at text processing too.
Byte was a magazine that everyone from the manager who never coded (or one whose technologies they mastered are obsolete) to the low level hacker. But it seems this range of audience is what caused its advertiser base to dry up as explained here.
If someone would make a python preprocessor that sets correct python indentations according to code blocks delimited with {}'s and ;'s, this would eleminate all the complaints from the "other" side without having to rewrite the parser.
THe formatted code going in would always look the same to the compiler but the coder can look at and write the program which ever way that suites their style. With braces or no braces.
Anyone interested in making something like this?
Or If there's something out there... plz point me in the right direction!!!
#############################################
# exoduz : escape while you can.
#############################################
--
# I have no brain
Having different editor settings is something which different authors often have, this is hardly the first instance where magic white space has caused problems, make being an obvious previous example.
I really don't know why Python programmers reject the concept of bracket characters (or words as in languages like Pascal). In my exprience, when reviewing code it's useful to know what the original author was intending to program, as well as what she actually programmed.
Having syntax markers as well as indentation provides a valuable redundant check which indicates when the thoughts are not matching the code.
If a program has
Then I know that there is something wrong with the program. I don't know if the programmer wanted the else to go with the first if or the second, but I do know that he was confused about this section of code.By removing the {}, you loose that redundant check on the code, and the poor maintence programmer has no clue that this is a suspect portion of code.
In the past I've heard the claim that you could use magic comments in python to indicate your desired indentation. Unfortunatly, almost every production program I've ever seen has had correct indentation, while I've never ever seen a python program with magic comments.
> Um, actually, why are you using tabs alternated with spaces in the first place?
Why is my code failing to parse because I do?
I've finally had it: until slashdot gets article moderation, I am not coming back.
The problem with the one true way is that generally everyone else does it the wrong way. And this is not insignificant.
What happens when you are forced to do something the way you don't want to? You are less likely to do it. I am more reluctant to code parts of programs when I don't like how I have to code them. As a result, I have to force myself to do them and to do them properly.
What's the result? Sometimes they don't get done properly. When I was doing java just about every catch block had nothing in it, because it was such a damn pain to do. The result: my code didn't handle error conditions properly - the very result of what what supposed to handle error conditions.
There isn't one true way to do things. When you get down to it, scripting languages themselves are the wrong way to do things. Sure, they save one programmer some hours, but they cost millions of people CPU time. The right way to code is in C, where you are intimiately aware of execution time. Or maybe it isn't. It's great that the python crowd agrees on what the one true way is. I don't agree with them.
There was a language back when that used whitespace to enforce coding - it was called FORTRAN. That language really, really sucks. I've had to work in it. It sucks. Badly. Well, to me. I've heard that there are people who will program in nothing but fortran. Each to his own. But to me, fortran programs were no easier to read. COBOL is supposed to be a nightmare, and it uses whitespace to make things look better.
The point? That not everyone believes that the same way is the right way. Your method may optimize for one thing that I don't think is worth optimizing for. Mine may optimize for something that you don't think worth optimizing for. Other people code out certain functions in assembly just to get some extra speed from their CPUs, and they're optimizing differently from both of us. Which is right? I don't really know. If I had to program in a language which enforced whitespace, I'd probably rip apart the interpreter and rewrite it to use {} the way that most normal programming languages do. There are places where whitespace makes life harder to read. Like a function with lots of arguments, for example. Or an assignment with lots of text. It's a lot better to make exceptions for them in indenting style because they make things more readable.
In the end, any time anyone claims that they know what the one true way is with only negligible amounts of doubt, I start to wonder. You have plenty of very infamous company and just a tiny bit of famous company. And the famous ones all had or claimed to have divine inspiration. Are you going to claim that python was dictaed to guido directly from God or some angel?
They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- C. Sagan
That's half true. And more-than-strongly hints at what I consider Python's biggest flaw to be: lack of block-structure and variable declarations. You can fake it by using default arguments to functions, but it's not all that pleasant.
Python has variable "undeclarations", namely the global statement (basically used to say "I'm not declaring this variable"). In my opinion, an unfortunate feature in an otherwise great language.
I just saw this article over @ IBM's developerWorks, and I think It's going to change the "market saturation" of perl & maybe eliminate python.
I have only tinkered around with this a little, and I'm impressed so far. The language was developed to be object oriented, which eliminates the "added on" feel of OO programming in Perl and Python.
For those who aren't about to wade throught the 12 whopping pages on this amazing new japanese phenomenon (kind of like those electric pets a while back; gigapets I think they were called), I've included the most basic description based on exceprts from the article below. (you can get it here by the way.
There are several different implementations of Python, but the most notable are CPython (Original Python) and JPython. JPython is an implementation of Python in 100% pure Java. Python scripts run anywhere there is a JVM (though you need the JPython jar and probably the Python class library). Furthermore you get complete access to Java from within Python. You can instantate and send messages to any Java class. You can even subclass Java classes in Python. You can use the Python interactive mode to interactively manipulate Java classes. It's way cool! In my opinion, it is the best way to deal with Java. Python becomes a higher level langauge on top of Java.
Anyone who is forced to use Java (which is becoming more and more politically correct every day) would be wise to check out JPython.
Many people complain about Python's use of relative indentation but those people typically don't use python. It really is a complete non-issue for people that use Python. Let's face it, cutting and pasting code when using an Object Oriented language is Bad Form.
Note that it is indeed possible to defeat the indentation if necessary. Check out this implementation of a CBC (Cipher Block Chaining) mode Karn cipher in Python (using MD5 for the hash function). The key and IV are crunched with MD5 before usage, so they can be of arbitrary length and density.
Usage: karn -e "key" "initialization-vector" | karn -d "key" "initialization-vector"
from md5 import *;from sys import *;from string import *;M=md5;il=ir=M(argv[3]\ ).digest();ki=M(argv[2]).digest();K,k=ki[:8],ki[8: ];p=stdin.read(32);c={'-e':'\ l=x(l,il);r=x(r,ir);R=x(M(l+K).digest(),r);L=x(M(R +k).digest(),l);il=L;ir=R','\ -d':'L=x(M(r+k).digest(),l);R=x(M(L+K).digest(),r) ;L=x(L,il);R=x(R,ir);ir=r;il\ 1 6],p[16:\ ];exec(c[argv[1]]);stdout.write(L+R);p=stdin.read( 32)";exec(main)
=l'};main="def x(a,b):return joinfields(map(lambda m,n:chr(m^n),map(lambda m:o\
rd(m),a),map(lambda m:ord(m),b)),'');\nwhile(p):p=ljust(p,32);l,r=p[:
Try giving a female the python? Would I have to buy her dinner first?
Udell's perspective seems rather limited. For example: "power tools like Perl's amazing map function, which applies a function to every element of a list." Simply amazing? This sort of thing is SOP in Lisp and other functional languages. And Scheme, for example, is available as a Unix scripting language in scsh and guile.
You're trolling, aren't you? Nobody could say so many wrong things and not be trolling.
I especially like, "C++ is single-handedly responsible for the entire Windows community." comment. It was almost as goofy as your "most Linux developers use C, so OOP is a failure" argument.
I'll have to work hard to match your trolling abilities, my friend. In the meantime, I'll enjoy watching the angry ASCII that will flow as result of your post. Thanks!
--What if I really DON'T want to be on index.pl right now?
There is an alternative to both Perl and Python. Ruby. There is a description at IBM It's a real object oriented scripting language that owes a lot to Smalltalk. It handles strings and regexps as easily as Perl and yet it is a real programming language with a simple (compared to Perl) grammar. Check it out. Look out for the iterator objects which allow you to define new control flow structures easily and the way *everything* is treated uniformly as an object - including blocks of code.
-- SIGFPE
I've several times run into problems like:
:)
if (case1)
if (case2)
print "case2";
else
print "Neither case1 nor case 2";
There the indentation is rather misleading, in a non-obvious way. (The else gets grouped with the inner if, not the outer)
It's pretty frustrating spending a long time tracking down a "That's not what I meant!" bug, just because it reads just like what you meant. (in C/C++ and many derived languages {&,&&} and {=,==} are good at helping this kind of thing along)
For the record, I programme in neither Perl nor Python, so I'm relatively "unbiased".
Trees can't go dancing
So do them a big favor
Pretend dancing stinks!
The article seems to conclude that Python will explode because it has a "killer app" in the Zope application server and that perl lacks such a killer app. I don't think this is correct. mod_perl (the Apache perl module) is certainly an equivalent.
as long as you are consistent about the amount of whitespace in a given block, it doesn't matter if you use a tab, three spaces, or any combination. Python cares if you are consistent about it within the block. it does not have to be a tab.
for example, run "python" and type these in:
def myFunction():
print "two spaces"
def yourFunction():
print "eight spaces"
no problem. just use the same spaces in a given block.
Daniel
Forth .org's website
Bigforth (Has its own GUI)
What's going on around here? A Perl vs. Python thread on Slashdot, and instead of a flamewar, there's a reasonable and even pleasant discussion going on? (At least when I browse at +2.) What's the world coming to?
:-)
Well, all right then, I'll try to write a level-headed post as well. This article is very well done, a welcome departure from the usual vitriol. I strongly believe that not only this particular religious conflict, but also many of the other ones such as Mac vs. Windows and Linux vs. BSD and vi vs. emacs, are based much more in habit than in reason. We like what we've learned to use well; everything else seems unintuitive and vaguley threatening.
I myself am very much steeped in Perl programming and simply have not yet gotten around to learning Python, just a lot of other people. I've had a few episodes in the past when I've been much more defensive about Perl than was appropriate. If someone else wants to get all bent out of shape about a programming language, then they have a problem I don't need to compound. See how hard I'm working on bettering myself?
Always keep a sapphire in your mind
I didn't know Python.
At my old job, I was told to learn it because we were going to use it as our scripting language for a text animation system we were working on. At the time it wasn't a priority, and my internship ended before I got around to it.
I know Perl, and I always cringe whenever I have to code in it. It's something about all the excess punctuation that is required to do anything.. It's a hemorrhoid to read anyone else's code.. I think Perl code in itself is a good fingerprint of the psyche of the programmer. You can see little hints of anarchy/anal retentiveness in it. WTF - why can't the code be cleaner? Why can't it represent the true nature of what the programmer is trying to get across?
And then I started working for this VFX company in Austin, TX (I'm an anonymous coward, remember?) We were in desperate need of a robust distributed work queue for rendering, compositing, compiling..etc. I still had the Python books, so I decided to check it out, making this my little project that I would use Python for.
In one week I knew everything about the language there was to know. Easy - direct - clean - beautiful. By the second week I was writing C modules to interface with NT and SGI (the two architectures we use) system libraries. Serious cake.. The OOP structure of Python is very free and easy to understand and code.
...
Now that the project is done, I can't imagine using Perl, or any other language to do something like this.
Some of the joys I found while learning Python and coding this thing were (no I'm not into abusing buzzwords) ease in RPC communication and data marshalling, thread control, bidirectional pipes, code-reuse, architecture independence, exception handling, and the easy ability of going back into what I wrote and being able to read my own code - not to mention a great debugging environment.
It's sort of like a really clean C++ with the convenience of Perl.
I would HIGHLY recommend Python as being something you need to learn and start using! I mean, Perl is good for hacking stuff together because you know how to do it in Perl. Even Bash is good for that.. But Python really gives you a good feeling that you are architecting something that is made to work, made to last, and made to be maintainable. And Python is extremely good for quick Perl-ish hack jobs.
Maybe Perl (in reference to an above post) is for artists, but I think Python is for designers. Know which one you are, before you do anything else.
Sean
If you look at caucho.com, they have proof that Java servlets are faster than mod_perl.
;-)
No. They have a poorly done benchmark comparing to Apache::Registry which is effectively just a hack to get legacy CGI scripts to work under mod_perl. For an explanation as well as more accurate benchmarks check out this thread in the mod_perl mailing list archive
For the lazy, here are some of the relevant results:
> These tests used httperf with persistent connections, making either
> 1000 or 100 requests per connection, depending on the test. The results
> on "hello" are astounding:
> Test: "hello" -- displays "Hello, World"
> Size: 450 bytes
> httperf: 40 concurrent connections, 1000 requests/connection
> Results:
> mod_perl+Apache: 1600 req/sec
> Resin+Apache: 500 req/sec
> Resin httpd: 4600 req/sec
>
> Test: "bighello" -- lots of HTML + "Hello World"
> Size: 23888 bytes
> httperf: 40 concurrent connections, 100 requests/connection
> Results:
> mod_perl+Apache: 480 req/sec
> Resin+Apache: 300 req/sec
> Resin httpd: 280 req/sec
>
> Test: "database" -- query: "select NAME from DIVISION", returns 11
> rows
> Size: 460 bytes
> httperf: 40 concurrent connections, 100 requests/connection
> Results:
> mod_perl+Apache: 570 req/sec
> Resin+Apache: 300 req/sec
> Resin httpd: 450 req/sec
> I also tested the "file.jsp", which I renamed "fortune" in the perl
> tests. With http_load, the results again show mod_perl ahead:
> Resin:
> 1584 fetches, 10 max parallel, 489610 bytes, in 10 seconds
> 309.097 mean bytes/connection
> 158.4 fetches/sec, 48961 bytes/sec
>
> mod_perl:
> 6190 fetches, 10 max parallel, 1.98814e+06 bytes, in 10 seconds
> 321.186 mean bytes/connection
> 619 fetches/sec, 198814 bytes/sec
Of course, as with all benchmarks, these should be taken with a grain of salt; I'm just pointing out that for the benchmarks on the caucho homepage you'd better keep the salt shaker handy
Chris
San Francisco values: compassion, tolerance, respect, intelligence
The amusing thing about Java is how broken the language and implementation are to this day. Java2 addresses some issues, but Java is at least two years or more away from being as useful for big and small problems as its competition.
If Sun wasn't pouring millions of dollars into hyping Java, it wouldn't even be an issue - Java would have vanished long ago. Only Sun's PR budget keeps it alive now...and let me add that even this is changing - Java is falling off the radar of most developers who are sick of waiting it to become a half decent development tool.
Java code is compiled to bytecode, not native code.
Perl is also compiled to a bytecode format before execution.
But Perl/Python can't beat Java unless you write a program that is almost entirely made up of calls to Perl's native facilities (perlfunc functions, regex, and hashtables).
Which is almost every perl program. Perl has everything and the kitchen sink built in....most userland programs are executing compiled functions...this is why perl typically executes much faster than Java.
I think it's important as to what language you speak. If you naturally speak in a very gutteral language, Klingon for instance, then Perl is definitely your choice language. Lots of gutteral punctuation stuff in there for many endless hours of happy oration. Perl is also the choice language for code obfuscation contests and plain old hard-core showing off with Perl one-liners that hack and slash text files into important bits, save it to a database after consulting an LDAP directory tree, heat up a burrito in the microwave two offices down, and print out a banner message pronouncing your coolness in hex on your friend's terminal.
And Python is great for writing stuff that you want to be able to read later on without endless comments and your secret decoder ring.
/will
When you open a magazine, and the first page of content is on page 200, you're not going to read pages 1-199. All those advertisers soon realized that, and stopped wasting their money.
I'm working in education and have been gathering feedback for awhile on which programming language to introduce to middle school students. I lean towards python only because it *is* more readable and clean looking, which naturally makes it less time consuming for me to spot errors in student code. And with student friendly internet apps like Alice (alice.org), Python lets kids create interactive worlds as they pick up OO principles. Speed is important too. Since Python is definitely syntax friendly-- I think it should attract students who might be otherwise put off by difficult PERL code. Not that Perl is bad for kids-- just difficult to digest at first. Now, if we could only get everybody together in pushing a *free* standard programming language at Middle/High Schools in the US, we wouldn't need to dump so much money in tech education.
There is no doubt that OO is the biggest bit of snake oil to come out of the programming "gurus" in ages. Think about it folks, OO has been pushed down our throats in one form or another for over twenty years. If it hasn't worked by now, it ain't working.
Work on any sufficiently large real project and you'll find it easier said than done to decompose your project into a whiz-bang hierarchy that actually works...and once it does, look out for the bloat on your object files, and the horror that ensues when you realize you made a mistake somewhere back there in a base class and you have to tear the thing to shreds.
I admit it has advantages for parsing by humans. However, I can't help but wonder why we (programmers) have to spend so much time messing with text files. The simple act of editing a text file introduces several issues to your development process, most notably:
- does everyone's editors use tabs or spaces?
- are tabs 8 characters? or 5? or 4? or 3?
- are end-of-line markers LF? or CRLF?
- are filesystems case sensitive? insensitive?
- c/c++ coding style consistency? yeah, right.
When we started porting The Product (tm) to WinNT from a unix codebase, each of these issues caused
problems in some way. The IRIX compiler won't accept an end-of-line that's a CRLF, as the CR kills the compiler. Case insensitive filesystems are one more thing I could cheerfully throttle Uncle Bill for. At any rate, these are matters that programmers shouldn't have to mess with.
It beats the hell out of punching cards, but it's still a waste of our time.
With the advent of UML, there is now a rich, common graphical language for exchange of program design (at least for OO languages). My dream programming environment consists of manipulating graphical representations of the code in UML, perhaps flow charts for individual methods, and clicking the Generate Code button. The backend would handle all the trivialities of generating a workable code base, in my choice of implementation language(s). Generate IDL for interprocess method invokations as required by your model. Much the same as modelling a 3D environment, and clicking the Render button. Render the 3D model as png, jpeg, gif, whatever. Same with the code. "Render" the code in C/C++, Tcl, Perl, Python, Eiffel, whatever. Rational Rose is a good step, but that particular program's interface is far too complex for human usage.
There are projects out there attempting to specify XML standards for program design. Support them. Support the automated toolsets to generate them. Then start using them, avoid sweating the minutia and be even more productive.
How's my programming? Call 1-800-DEV-NULL
Just about every set of coding standards that I've ever seen (including the GNU standards) specify not only brace style, but indentation (2,4,8 spaces) and how that indentation should be done (usually, all spaces, or "you must convert tabs to spaces", etc.)
<RANT>
So what's the big deal? You're either (a) doing it anyways, or (b) your code is so freaking sloppy that any amount of structure is anathema to you.
"It confuses CVS" is about the lamest excuse I've ever heard of. Since when do you base your choice of language around which source code control system you use? Sheesh.
</RANT>
"Great men are not always wise: neither do the aged understand judgement." Job 32:9
Having said in an earlier post that I like the article, here's two things I disagree with.
For one thing, the claim about a "Killer App" is not terribly persuasive. Perl may not be able to point to an application that is as impressive as Zope, but there is a multitude of Perl software components that have proven themselves as killers -- such as the CGI, DBI and LWP modules and Apache's mod_perl, to name just as a few. A great deal of software running on the Internet constitutes Perl's "killer".
More importantly, I don't at all believe in a distinction between Perl and Python, or for that matter any other language, concerning TMTOWTDI -- as if Python's motto is "There's only one way to do it", or TOOWTDI (pronounced "tooty").
People act as if TMTOWTDI is a special feature of Perl, but I don't buy it. TMTOWTDI is an essential truth about the way computers work, regardless of any programming language. Show me any problem, and I'll show you more than one substantially different Way To Do It, using any language.
TMTOWTDI is often misunderstood as a free-for-all, a ticket to do whatever you want. Not so. The motto should always be continued with, "... But Some Ways Are Sometimes Better Than Others". Some solutions to a problem will run very fast. Others won't run as fast, but will use less memory or I/O. Yet other Ways To Do It lend themselves to being written in more easily maintainable code. If you read the Camel and other Perl docs carefully, you'll notice that the authors are always at pains to make these differences clear.
Suppose your program needs the value of a complex function. You could compute the function on the fly, which may take some time but saves space. Or you may pre-compute it for a large number of values, which will take up a lot more space but will run much more quickly. Your choice of a solution will probably not be influenced at all by the programming language you've chosen to use, but rather by the resources you have available.
I don't know Python, but I flat-out disbelieve that it allows only one way to solve any particular problem.
Always keep a sapphire in your mind
?
Because tab-whitespace is different than space-whitespace?
Again, unless tab = 8 spaces and you always uses 8 space indents...
-AS
-AS
*Pikachu*
Any dialect of LISP (e.g., Scheme) will treat tuples (OK, pairs) as first-class objects. Even better, programs themselves are essentially complex structures built from pairs. This is all a consequence of LISP's incredibly simply syntax (even simpler than Python, I'm sure). That makes LISP a great language for writing programs that manipulate programs (evaluators, compilers, etc.). I've seen simple compilers implemented in hundreds (not tens of thousands) of lines of LISP code. If you like Python's ability to built complex structures from basic pieces, you'll really like LISP.
Hi, for those people who want auto-indent-like stuff but don't like emacs: Python comes with an excellent IDE, called Idle. It has an editor with auto-indent, backspace drops an indentation level, many syntax color highlighting, etc. I can imagine you hate emacs - use Idle instead! regards, Gerrit.
Well, this is getting off-topic but I had to reply...
Not knowing much about ML, I looked it up online. It is amazing how many websites about ML seem to assume you already know what it is! Anyway, from what I can tell ML falls into the subset of languages known as "Functional Languages" which are really a form of "Declarative Languages" -- and I already mentioned "SQL and other declarative languages" in my original post. In other words you still haven't told me about a "Procedural Language" (OOP or non-OOP), other than Python, that supports Tuples as first order constructs.
Don't take this to mean that I am trying to refute you, I could have completely misunderstood what I read.
Jack
P.S. I have never liked Declarative Languages because they expect me to describe what I want the computer to do and then let the computer figure out how to do it. In my experience this always leads to convoluted code (and lots of lost time) as I attempt to get the computer to do it slightly differently than it thinks I asked for. I excuse this in SQL because I have nothing better to replace it with, but business rules tend to be best implemented in a procedural style...
- -
Are you an SF Fan? Are you a Tru-Fan?
Any fool can see that Python one of the Lesser Languages of the world, along with the inferior and obsolete likes of C, C++, LISP, Fortran, and all other non-Perl languages. Python is fit only for the use of babbling imbeciles who prefer so-called "elegance" to labyrinthine complexity, those helpless morons who believe that a programming language is a mere tool rather than a way of life.
Well, for them a programming language may well be a mere tool. This is why they will soon be exterminated. They have fallen behind in the evolutionary sweepstakes, and are no longer worth the oxygen they consume. They will all be killed, and Perl will have finally earned its rightful place as the Only Language.
All communication will take place exclusively in Perl. You will propose marraige in Perl. If your beloved cannot understand the question, that's for the best: People like that must not be permitted to breed. You will order your meals in restaurants in Perl. If you can't make yourself understood, you will justly be ejected, and you will starve.
There Is More Than One Way To Do It! This will be the battle cry of the New Human Race. All those mental and moral degenerates who insist on using inferior languages will be forced do things in multiple ways, and to use the One True Language to do it. If they cannot learn, they will be terminated.
The human race will be purified and improved -- and there is ONLY ONE way to do THAT.
Is it really that hard to figure out what a girl might like about a python? (or 'python' in this case)
Get you mind in the gutter soldier!
Java is simply too verbose. It takes 50 lines of java to do what Perl does in 10 lines. This is 10 lines of well written (not intentional compacted or expanded) code. Not sure about python, but I suspect that python is probably closer to Perl in this respect.
I think the choice of language matters less than the programmer who speaks it.
Generally if you become truly proficient in one programming language, it is not that hard to pick up another. They are all tied to machine code, and in some fundamental sense, are the same. The only attempt I've seen to make a language that is different is Intercal. Try comparing that to any other language out there, I dare you.
Try to be the best programmer you can be, and let the others argue over which ice cream flavor is best.
Dear Python User:
I understand that we have some small differences of opinion with regard to programming languages, and that's a very painful thing to me, because it means that the community is divided. As we all know, "a house divided against itself cannot stand". For that reason, I'd like to offer a solution to the problem which should be beneficial to both of us: We'll exterminate you and all of your family. This way, the community will no longer be divided, and the superior uebermenschen of Perl will no longer be bothered by the mindless buzzing of people who program in inferior languages. You, meanwhile, will benefit enormously by being relieved of the need to live out your miserable, wretched, inferior life.
DIE, INFIDEL! DIE! PERL RULES!
We will hang you by your heels and devour your liver! Wild dogs will drag your corpse through the streets, and finally we will bury the tattered remains at midnight under a crossroads! Your name will be cursed for eleven generations, and all children born who resemble you will be flayed alive!
PERL RULES!
Thank you for considering this little peace offering of mine.
Sincerely,
Larry Wall, Perl Central Committee Chief Commissar and Absolute Maximum Leader of All Programmers.
There the indentation is rather misleading, in a non-obvious way. (The else gets grouped with the inner if, not the outer)
Ahhh, but in Python, it behaves exactly as you'd expect it to -- the else is in fact grouped with the outer if!
case1 = 0
case2 = 0
if case1:
if case2:
print("case 2")
else:
print("Neither 1 nor 2")
prints 'Neither 1 nor 2'
if you change the value of case1 to 1, nothing is printed.
This is why indentation in Python is valuable, once you get past your old C/C++ habits.
dook, dook, dook!
Perl does have an app like Zope.
:) )
:) Soon...
:)
Mind you, I'm only pointing this out to say that Perl is not completely lacking in such a 'killer app', not to start another Python war.
Iaijutsu is an object oriented web content management and application development framework. It has a lot in common with Zope, but diverges in many conceptual areas.
What's magical about Zope is that it looks, to users, like a content-management system with a simple Web interface that anybody can use. A non-programmer can manage a simple website, using Zope, with little training.
Iaijutsu does that now. Although I can't mention the names of very many sites because they are clients for my day job, we have quite a few fairly large name clients using Iaijutsu's content management for their sites, intranets, and business-to-business document stores.
Yeah I know, kinda a weak claim. Just suffice it to say that someone is using Iaijutsu now.
Thanks to Zope's powerful object-oriented framework, it's easy to build such a site in an efficient and economical way, inheriting (or, in Zope-speak, acquiring) common elements from ancestral objects
Acquisition != Inheritance. More of a close cousin.
And you don't need acquisition for efficiency and economy-- on the contrary, I've kept acqusition from permeating the design of Iaijutsu because it seemed to me to be one of the most confusing aspects of Zope. However, acquisition is still possible in Iaijutsu. (There's more than one way to do it!
Thanks to Zope's built-in object database, it's easy to restructure the site -- for example, by cutting a subtree of objects from one location and pasting it into another.
I implemented this about 6 months ago.
Out of the box, in other words, Zope is a useful Web content manager for nonprogrammers.
Iaijutsu is this right now. However, the documentation is even less complete than Zope's.
There's a tag language called DTML (Document Template Markup Language) which, like Cold Fusion Markup Language or Java Server Pages or Active Server Pages, mixes HTML templates with programming instructions that can populate these templates with data drawn from SQL stores or Zope's own object database.
Iaijutsu has this, via Andy Wardley's awesome Template Toolkit.
However, unlike Zope, Iaijutsu is designed with the philosophy that content, logic, and presentation should be like oil and water. The templates are for presentation-- you do not build application with template documents. This goes against the concept of DTML, ASP, JSP, LiveWire, PHP, EmbPerl, and all the other code-in-page systems.
You compose content in object properties, applications with object methods, and display content and application results via templates. The only logic in your HTML templates should be only what's required for display. (See XSL for a similar concept.)
When this mid-level programming environment runs out of gas, you can drop down to Python -- Zope's native implementation language -- to write powerful extensions that communicate intimately with Zope's internal machinery.
The same ability exists in Iaijutsu. Content and application classes can be written in Object Oriented Perl.
However, there is also a hybrid Perl/XML format for writing classes online in web forms. And you need not write any perl at all in these class definitions.
Anyway, I've babbled enough. Just trying to set the record straight, that Zope is not without competition soon.
I've only dabbled so far in both perl and python. Python seems more straight-forward to use, but the white-space sensitivity makes me very nervous. It's like Fortran all over again. Mind you don't inadvertently slip a space character between the tab and the code, or your program will fail, just as Fortran will fail if you put the continuation mark in the 5th (or was it 6th? 7th?) column by mistake.
Others have already mentioned this, and I give it my full support: make tab indentation optional (allow blocks to be defined by {} for instance) ! Let the programmer choose what the best method of indentation is for readability, not for syntax! Please!
I could be a lot more confident about using python if this misgiving were to be fixed up.
Rizzer
Python holds a special place in my heart, Perl is a troublesome beast I'm coming to grips with. Still, it always bugged me having to write : i = i + 1 instead of i++ In Python. Gary
It's been done. I don't recall exactly when; more than a year ago IIRC.
It turned into a massive flamewar, pitting actual programmers against morons (the same ones who whine resentfully about spelling flames) claiming that HTML and batch files count as "programming languages".
The whitespace issue debated previously is a big one. Python, IMO, is a worse language because of the whitespace inflexibility. I have problems going from emacs to vi, for example.
Other problems with python? I don't like that there isn't any c-like short cuts to getting things done like the incrementor ++, or += or -=, etc. I would also like to see a more elegant way to import modules than having to set a python path.
Don't get me wrong, I use Python all the time. My website was built using it, I just think it could be turned into the new "Uber" language with out much work.
-- Moondog
Sincerely, Perl Central Committee Chief Commissar and Maximum Leader Larry Wall
...or to each other, embed ll sorts of interpreters inside each other!!!
I hate it when people argue about which language is better. Usually the arguments boil down to "yes it is" and "no it isn't".
People should understand that all languages have both strengths and weaknesses, and each time programmers are confronted with a new problem, they should choose the right language for the job.
I use both Perl and Python. Whenever I want to do some magic with text, Perl is the natural choice for me. Also when it comes to CGI, but that's probably just because I don't know how to do it in Python.
In this example, C++ or Java would be just plain stupid. Neither language is able to do what Perl can do in as few lines.
When it comes to GUI stuff, I prefer Python and its Tk interface. The reason is that Python enables/forces me to structure my code (Perl does not, and I'm too lazy to control myself).
It isn't about "There's More Than One Way To Do It" (TIMTOWTDI) or "Keep It Simple, Stupid" (KISS), but "Choosing The Right Tool For The Job" (CTRTFTJ).
Thank you.
vr
You said: Java code is compiled to bytecode, not native code.
But the fact is, you're wrong. Java is *packaged* as bytecode for platform independent distribution, but at runtime, on the vast majority of Java VM's in production use, Java is *NOT* interpreted, but *JUST IN TIME* compiled to, for instance, Intel 386 code. You're the one who needs to learn how JVM's work. Today's modern JIT's perform inlining, subexpression elimination, peep-hole optimizations, code-motion, and some even perform a limited amount of global analysis. IBM and Sun also produce "mixed-mode" VMs which mix interpretation and compilation. They compile the 10% of code that is executed most, and spend lots of CPU time optimizing that code. The rest, they leave to be interpreted. As a result, the VM's startup quicker, and the core "tight loops" get agressively optimized and sit in the CPU's cache.
Like I said, byte-code is merely a convenient compression technique for source code as far as Java is concerned. Java's byte-code format almost contains enough information to completely decompile to identical source code. In execution, only on the oldest VM's is it strictly interpreted. All modern VM's compile to native x86 code during the loading process.
I said: But Perl/Python can't beat Java unless you write a program that is almost entirely made up of calls to Perl's native facilities (perlfunc functions, regex, and hashtables).
You said: Which is almost every perl program. Perl has everything and the kitchen sink built in....most userland programs are executing compiled functions...this is why perl typically executes much faster than Java.
But you're wrong again. Perl typically executes faster on text processing benchmarks because of the builtin regexp. But you cannot conclude from this, that Perl is faster than Java per se. Perl is fast at what it does (and I speak as someone who has written over 100,000 lines of Perl code and have been writing it since 1991).
However, Perl is slow on numerical algorithms, graphical algorithms, data structure manipulation (or lack, thereof), and any other function not related to sucking in files, spliting and matching text, and shoveling it into lists and hash tables. I love Perl, but the idea that Java is slower than Perl is hogwash. I wrote a ray-tracer in Java and I know for a fact that it would run 100 times slower in perl from simple experience of writing a FFT/convolution algorithm in Perl. So would a browser, or 3D modeling program.
Objects in perl for example (if you can call them that), rely heavily on using hashtables and lists to "emulate" datastructures that you get in other languages. There is no way that $ref->get_member_variable() is faster in Perl than in Java, for example. The Perl code yields either an array index operation, or a hashtable operation. Both of which are many orders of magnitude slower than object field references in Java which get translated into a 2-instruction assembly code pattern. (yes yes, Perl can slowly manipulate real data-structs via pack/unpack(), but very few .pm modules use this technique)
Perl isn't even always faster than Java at text processing. In the field of parsers, if Perl has to both parse, and build a parse tree representation of a context free grammar, Java based parsers end up winning, even though Perl has regexp built in, probably because datastructure operations are slow.
You will soon get the chance to try yourself. Someone is bound to take Perl's XML parser, create an XSLT implementation, and then we can benchmark Perl directly against Java at parsing and transformations. Next time, learn something about Java VM's before you speak.
I'm an ardent admirer of perl, but no enemy to python -- after all, shouldn't the greater vision of "Tim Toady" extend to other languages if appropriate?
There are shortcomings in perl (lack of function signatures, array context weirdness, inability to specify non-autovivifying hashes, etc.) that have encouraged me to look to Python for relief while working on certain projects.
I've found a great barrier, however, in the documentation: the O'Reilly python books, though they parallel the perl books in name, don't approach the quality of the latter.
Whereas "Learning Perl" offers a conceptual tutorial grounded in simple examples, and "Programming Perl" sets forth the definitive specification and philosophy of the language, the python books both seem to me to take a fairly scattered "cookbook" approach, introducing specific applications of the language, but never offering a comprehensive initiation, either for beginners or experienced programmers.
Maybe I rely more than I ought to on dead trees, but I've also failed to find worthy online docs.
Has anyone else out there found better info? Am I wrong in my assessment of Lutz's books? Suggestions for further reading are welcomed!
Comment removed based on user account deletion
PHP should at least get a thought. It has many of the features of Perl/Python but is embedded in the html (like asp). It has all the flexibility of Perl. A PHP programmer can write in whatver style works best for him/her.
-- soldack
I am not a programmer and I have never used Python or Pearl but I once was told a little story: Python was invented by Guido van Rossum. Guido has a brother called Just, who togheter with his partner Eric Blockland is a very well know typeface designer. The two of them have a company called letteror. A year ago I had the pleasure of seeing one of their presentations. Their presentation was showing an overview over their typographic work and all of their applications were made in Python. They said that they were probably the first users of Python and heavily involved in the design process. Maybe thats a reason why the code has to be strictly structured and formated - it was developed with the help of non Programmers. Something every developer for every application should do.
Hank! White!
for perl morons who clamor about the power of perl's 'map', check out this perl module
m atica.html
http://xahlee.org/PerlMathematica_dir/perlMathe
ps first serious post in screen order.
Xah
xah@xahlee.org
http://xahlee.org/PageTwo_dir/more.html
Yes, they should. For example, if the mod_perl version of "big HTML + Hello World" employs the <
Or, in the JDBC benchmark, are they using the thin driver or the OCI driver? Are they using connection pooling? Are they using PreparedStatements?
What are the parameters the VM is using?
Do they using String's or Sring buffers when manipulating text?
When they load text files, which technique are they using?
How you write the code matters alot. For example, in Perl, @array = <FILE> is faster than while(<FILE>) { push(@array, $_); }
I'm not sure I trust their benchmarks as representative either. The only benchmark that seems relevent is the database benchmark
-Ray
All the arguments about the readability seem to a priori favor Python. I've found Python indeed very readable and when I've had to fiddle with it I haven't had much trouble.
On the other hand, the best Perl code I've had to maintain is highly readable and if anything even easier to maintain than they Python examples I've worked with.
Perhaps the difference is the Perl is simply more expressive than Python. I don't mean this in a Turing sense obviously. This can be a blessing or a curse depending on who is doing the expressing.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Of course, the biggest problem with WebObjects is the cost. Not too many folks can afford the $10,000 entrance fee to get started.
You can get Mac OS X Server for $499, including a limited version of WebObjects, at the Apple Store. Of course, you need to shell about for a recent Mac if you don't already have one, but it's still cheaper than $10,000.
-jimbo
"Hold me Bob!" "I would if I could man!" -Larry and Bob in VeggieTales
a lot articles fuddle around the word 'expressiveness'.
...etc. These are not readily present in other languages. Does it mean that these language are more expressive?
m atica.html
Question: the more syntax variation a language offers, the more expressive it is, true?
Question: some "advanced" languages has constructs that does first class objects, tail recursion, closure, monads, OOP features (inheritance, polymorphism...etc.), dynamic evaluation, pattern matching (on expression structures, not strings), infinite streams, infinite precision arithmetic
to Perl morons: if syntax sugar quantity defines expressiveness, then Perl is expressive indeed, but have you ever thought about expressiveness in terms of functionality? I code Perl daily for food, but i can tell you it is fairly not expressive at all. (better than C for sure.)
food for your thought
http://xahlee.org/PerlMathematica_dir/perlMathe
Xah
xah@xahlee.org
http://xahlee.org/PageTwo_dir/more.html
a lot articles fuddle around the word 'expressiveness'.
...etc. These are not readily present in other languages. Does it mean that these
t ica.html
Question: the more syntax variation a language offers, the more expressive it is, true?
Question: some "advanced" languages has constructs that does first class objects, tail recursion, closure, monads, OOP
features (inheritance, polymorphism...etc.), dynamic evaluation, pattern matching (on expression structures, not strings),
infinite streams, infinite precision arithmetic
language are more expressive?
to Perl morons: if syntax sugar quantity defines expressiveness, then Perl is expressive indeed, but have you ever thought
about expressiveness in terms of functionality? I code Perl daily for food, but i can tell you it is fairly not expressive at all. (better than C for sure.)
food for your thought
http://xahlee.org/PerlMathematica_dir/perlMathema
Xah
xah@xahlee.org
http://xahlee.org/PageTwo_dir/more.html
Yup. And in Python you would get a syntax error at the else since the indentation is ambiguous.(assuming that you change the rest of the code to be Python, of course! ;)
No dangling else issue.
'Course I never see those in C or Java either, since I *always* use braces, just like you need to for Perl.
--
If your map and the terrain differ,
trust the terrain.
Ok, so now we're debating readability? how about effiancy? Which one runs faster?
Whats this talk of not needing comments? All large apps(20,000+ lines) need comments. No not on every line detailing incrementions, but the reader needs to know what Intent the original programmer had at that point in code/time.
There are several reasond for this, somebodies intent may have been different then the specs, or the specs changed, or your co-worker was taken away to the funny farm, do to "Frag" shock.
Short, clear concise.
I'd rather write a few extra lines of comment and use a wicked fast language, then have an easy to read slow language any day. Since I have a couple years of perl, and only about 3 weeks of python, I can not make a judgement on this.
I was hoping some of you would talk about this, but aparently the amount of comments a Language needs is far more important then the quality of apps.
Also can you make an executable app in python, like you can in TCL? just curious.
The Kruger Dunning explains most post on
a lot articles fuddle around the word 'expressiveness'.
...etc. These are not readily present in other languages. Does it mean that these
t ica.html
Question: the more syntax variation a language offers, the more expressive it is, true?
Question: some "advanced" languages has constructs that does first class objects, tail recursion, closure, monads, OOP
features (inheritance, polymorphism...etc.), dynamic evaluation, pattern matching (on expression structures, not strings),
infinite streams, infinite precision arithmetic
language are more expressive?
to Perl morons: if syntax sugar quantity defines expressiveness, then Perl is expressive indeed, but have you ever thought
about expressiveness in terms of functionality? I code Perl daily for food, but i can tell you it is fairly not expressive at all. There are just many paradigms and functionalities that i cannot do. (of course, i can always implement it, which is just a scaled-down version of saying implementing a compiler in lang x yourself.)
food for your thought
http://xahlee.org/PerlMathematica_dir/perlMathema
Xah
xah@xahlee.org
http://xahlee.org/PageTwo_dir/more.html
Well, you were the one saying:
If you look at caucho.com, they have proof that Java servlets are faster than mod_perl. (emphasis mine)
The benchmarks I quoted (you did read the thread I linked didn't you?) were just corrections of the Perl code AFAIK. I have no clue about Java, servlets or otherwise; I was just taking issue with your 'proof', which used less than optimal mod_perl (to put it mildly). I'm assuming the authors of your 'proof' were using optimal enough Java code for you, otherwise you wouldn't have used the magic word: 'proof'. The persons who sent the corrected benchmarks merely improved the Perl and ran new benchmarks. These benchmarks are proof that the original benchmarks aren't proof, and that's the only claim I'm making.
Chris
San Francisco values: compassion, tolerance, respect, intelligence
I don't really trust the idea of an OO scripting langauge. Ok, well smalltalk could dose it when it tries, but not these procedural/OOP hybrid things like Python. It seems all the advnatages you get by OOP are nullified by the space constraints of scripting. Plus, they are not really inovative enough, i.e. part of making a langauge fun is making it weird in meaningful ways. I think the relevent quote is "A langauge which dose not teach you something about programming is not worth knowing."
:)
Now, a monadic functional langauge like Haskell might make an interesting scripting langauge if you standardised all the tools (like regex) since it is so quick to write code in these things (monadic means you can do neet things like OOP and IO without really cheating the way lisp dose). I would really like to see someone perlify Haskell, i.e. say "we have enough syntatical purity for now, so lets be preatical and figure out how to make the langauge human without loosing too many of our cool functional short cuts." It's just really fucking cool (and very relevant to scripting) to be able to define a subtil algebraic datatype in like 2 or 3 lines. Plus, all the advantages of being able to extend things like regex on the fly (since they are actually in the langauge). The only real problem is that no one like Larry Wall has come allong to make a more fun & human version of the Haskell. Imagine all the weirdness of Haskell with all the weirdness of Perl.. that would be wonderful..
The Christian religion has been and still is the principal enemy of moral progress in the world. -- Bertrand Russell
anybody know where i can download python?? it seems like the ideal language for a newbie (relativly) like me to begin his quest into the world of coding.
Then you need to make the distinction. javac and alternative JIT systems are considered distinct in Java-lore, and you know it.
Like I said, byte-code is merely a convenient compression technique for source code as far as Java is concerned.
This is not correct - bytecode can include compile-time optimizations.
All modern VM's compile to native x86 code during the loading process.
That must be a real drag on a Sun box.
Perl typically executes faster on text processing benchmarks because of the builtin regexp. But you cannot conclude from this, that Perl is faster than Java per se.
Benchmarks are irrelevant - I care about the speed of working code I use everyday, in which case Java gets easily trounced by a number of other languages. If you want benchmarks, try The Practice of Programming by Kernighan and Pike. Its unbiased, unambiguous, and clearly shows what a dog Java is.
Objects in perl for example (if you can call them that)
Oh please, Java has the worst performing class library anywhere, even Javaworld.com lists articles describing this in detail. Besides the absurd object churn and heavy syncrhonization, Java's approach to objects is heavily verbose and basically treats developers like idiots.
Perl isn't even always faster than Java at text processing.
More conjecture. Provide hard data or clam up, cuz common wisdom says your full of it in this regard.
One reason I haven't seen mentioned yet is that it saves vertical screen space. A } or 'endif' will usually be on a line of its own.
Studies have shown that pieces of code become harder to understand as they become longer[1] - with a steep increase when the code becomes longer than a page, regardless of the length of the page. You have to scroll up and down to see it all.
One number I've heard is that a big (few hundred thousand lines) Modula project (Modula uses 'end') had 1 in 6 lines that only had 'end' on them. That means that a Python function can be around 20% longer than the same function in a language that uses end marks, for the same readability.
Btw, most of those 'confused cases' where the programmer uses an odd indentation scheme are simply a syntax error in Python. Yes, if he moves some line a complete indent to the left or right, it may be actually legal sometimes, and mean something else. That can only happen on the last line of a block. Then you have a bug. You get bugs with misplaced braces as well.
-- Remco
[1] Although I'm checking this in Steve McConnell's Code Complete now, and the studies *he* cites say it's no problem. I still like them smaller than a page, myself. Besides, Linus' CodingStyle agrees, and this is Slashdot.
I believe posters are recognized by their sig. So I made one.
http://dev.scriptics.com/advocacy/perl.tml
First time I've seen this attitude expressed in real life for quite a while...
Apparently you also don't believe in maintenance, or collaboration. Or perhaps are trying for job security through indispensability. Or have no job.
This is not a perl vs python issue, either. I wish the python coders whose work I have to maintain or interface with had bothered to comment their code.
It is NOT true that you don't need to comment python. Who came up with that nonsense? I keep hearing it.
As to the original post: well, I found that when I was learning I wrote those sorts of comments. And when I looked at the code 6 months later I took out the comments that explained syntax, and left the general functionality ones. Don't sweat it.
No matter how cynical you become, it's never enough to keep up.
The same way a "C" program can be faster than the assembler version of the same program:
Expressing the problem specification at a higher level allows greater degrees of freedom to the optimization machinery.
Think about how much you hate being micromanaged and why...
Seastead this.
With as little time as I have today to research and create such examples I am certain anything I do will be picked apart and I will be shown (by proponents of both sides) multiple ways that I did something stupid in my examples. I would rather concede the point than start that kind of pointless one-upmanship. Perhaps someone else wants to take up the gauntlet?
Which was most of my point in the original post.
Which is missing my point -- I was saying that, in a general way, providing many different ways of doing similar things often provides you with an opportunity to pick the most optimal one for a particular task. But I also implied that it takes a guru to do that. Not everyone is a guru.
Which is why I prefer Python to PERL, Objective C to C++ and so on. I tend to believe the 'Kitchen Sink' approach to language design has the long-term effect of making it difficult (or at least not helping) to create maintainable code. And, as a business programmer and lead developer, maintainability is my primary concern. Clearly bad programmers can mess up Python and good programmers can write readable PERL and you cannot do anything in one language that you cannot also do in the other. But PERL was designed to write code quickly, not to write code well.
Conversely Python was intentionally designed to promote those things known to create readable/reusable code! And for that I say cheers to Guido; may he never decide to start dumping things in for the sake of bullet points...
Jack
- -
Are you an SF Fan? Are you a Tru-Fan?
A easy, working definition of a first order object is one which the language can create an manipulate at runtime. Thus, in C, integers and arrays are first object, but, functions, say, are not. i.e. you have to *write* a function and recompile your program to have a new function appear in your system. In lisp, for example, functions *are* first order---you can write your program to create new functions as they are required at runtime.
I can't argue with that, but we are talking interpreted scripting languages here. If they are compiled at all it is to a p-code level which is then interpreted on a virual machine. Now the virtual machine itself can provide run-time optimization, but it will be optimizing the p-code which might be a wash between the two languages.
Besides, everything I had to say was a general case anyway. As I mentioned in another post, any attempt to get specific can lead to code one-upmanship where different gurus compete to show how you missed this keyword or that compiler switch. My point was that I don't care if PERL is faster or requires less lines of code to do the same thing. I prefer Python because I write code (and direct others in writing code) that has to last (and be extended) for years. Terseness is not cool in that kind of environment.
Visual Basic was the COBOL of the nineties. Python may well wear the crown for this decade! And if you don't understand the point about COBOL, let me point out that there are billions of lines of COBOL, originally written in the seventies, running the businesses of the world even today. Perhaps it is not sexy, but business software makes up most of the code on the planet...
Jack
- -
Are you an SF Fan? Are you a Tru-Fan?
If you use VIM (like I do), you can use :set expandtab and VIM will convert your tabs to spaces. Combine that with :set softtabstop=4 (or whatever your preferred tab setting is) and VIM will still read tab-containing files with 8 tabs, but will insert 4 spaces per tab when you press the TAB key. Highly useful for "one tab == one indent".
Already have displaced Java (not to mention C++) on servers and clients.
Start being displaced by a next generation technology -- thus crowding out any potential play for dominance Python might have had.
For a look at a next generation technology, any of the distributed declarative semantics systems would do (the most commonly referenced ones being RDF-like). However, at present, my money is on something at least as capable as Mozart.
Seastead this.
I'm not writing about how Perl sucks, because the way in which Perl sucks are well documented: auto-obfuscated, too focused on text processing if you want to do something else, etc.
Perl sucks at some stuff for good reasons, or at least because it is getting old and new stuff had to be kludged in oddly to avoid breaking too much old code. Python, on the other hand, seems to suck because Guido was taking shortcuts when he wrote the original parser and engine, and then never cleaned them up.
The colon: with all this nice, minimal syntax, why oh why do you have to start each block with a colon? You already have the indentation, and you know the line has started at the line break, so why would this superfluous character be included? It's always there, so it provides no useful purpose and you shouldn't have to type it. If it was optional, to be used for single-line blocks, then I would understand, but as it is, it's as silly as if you had to end every line with a semicolon.
The "self" variable: okay, I can sort of accept typing "self" every time I want to access a member, but why do I have to explicitly include it in the declaration of every single method? It is always there, yet you have to type it in again every time!
Why don't the lists efficiently and trivially act as dequeues, like in Perl? A great many problems become trivial with the application of a hash (fortunately present), stack, or queue. A fair portion of Programming Python is dedicated to examples of working around the fact that Python doesn't come with an explicit stack data type built in. The simple inclusion of push, pop, shift, and unshift methods for lists would have standardized and simplified a whole class of problems.
Why can't I specify what data members my class has? If I mistype a name, I want a compile-time error! What kind of class definition doesn't include explicit data members? The mind boggles...
Butt ugly operator overloading: when I define I symbol, I don't want to call it by another name! Use quotes, or use a single new overloading keyword, but don't make me remember a new keyword for every single operator.
No '+=' type operators: I can live without '++' quite happily, but with names stretched by OOP, I just can't stand having to type 'self.objectList[self.currentObject].counter = self.objectList[self.currentObject].counter + 1'. The need for cutting and pasting is a flaw in any language.
No adequate goto replacement: even though Perl has a goto, it also provides an excellent way to avoid goto altogether: the next, last, and repeat statements. With these you can break out of deeply nested loops without any stupid flags or gotos.
These all seem like trifling, silly little things, but in a scripting language, it's the little things that count most, and I've only touched the tip of the iceberg of all the annoying little things in Python. Much as Python people like to talk about the superiority of Python for large-scale projects, I usually reach for a scripting language when I want to hack something with a couple hundred lines of code; if I end up cutting and pasting stacks, or having to write modules for such an elementary function, or otherwise including standard "boilerplate", I might as well go use C++. These are actually major reasons I chose not to switch from Perl to Python.
Python has some really incredible ideas, and borrows some good stuff from Perl. Unfortunately, it fails to steal the very best ideas from Perl, doesn't follow out its own best ideas to their logical ends, and does some other really dumb stuff for no apparent reason. It's a tragedy, because the clean syntax, OOP support, and list handling (except for the dequeue thing) is so superior to Perl it's not even funny. Even with all these flaws, it was a very near race, and I probably would have stuck with Python if I had learned it first.
I have been using linux and freebsd for a year but I am afraid to fool around in vi or emacs.
I got the "Unix Power Tools" hand book and and practiced using both but I do not know where I can find info on how to setup emacs or vi to use python mode, c mode, or even lisp mode.
If any of you know a cool website or book that shows me more then basic functionality, I would really appriciate it.
With no university cs or engineering background, its tough to learn it.
I like and use Perl plenty. But Perl enthusiasts love to paint it as a language for all users and all purposes, when it really more demanding and specialized at heart.
::? Dereferencing with %@ vs. ->[]{}? Or all the myriad ways to structure a simple object? Ack! Too many ways to do it for code to be readable.
IMO, Perl has a well defined role as a powerful scripting language for users who know the Unix environment. Perl is an awk-sed-sh synthesis with a C syntax. I am a big awk and sed fan so it pleases me just fine to use perl for the same things I would use awk or sed for: (regex based) text and flat file db processing. But to build large systems with large numbers of developers in this kitchen sink of a language is stupid. It is so big, so cryptic, that unless everyone on the team is a $150/hr Perl god, you are going to wind up with a mess as junior people produce unreadable, wordy crap. You have to be some kind of Talmudic scholar to be able to read and write all common styles of Perl.
Perl does not have anything resembling a reasonable overall syntax or semantics. Is there any such thing as a truly correct syntax-aware editor for perl? When emacs can't parse a language you are in trouble.
The Perl community has some funny sayings. "Baby talk is OK." That's because unless you are coming from the right C-sh-awk-sed background you are guaranteed to misuse the language.
"TMTOWTDI." Like my and local? ' and
The perl interpreter is really weird and crazy under the hood, which doesn't make the language any more attractive for high reliability work.
Perl is a Unix hacker language, with most of the same mysteries and ways to shoot yourself in the foot as sh and friends. Mere mortals should use something with more rules and fewer options.
I said: But the fact is, you're wrong. Java is *packaged* as bytecode for platform independent distribution, but at runtime, on the vast majority of Java VM's in production use, Java is *NOT* interpreted, but *JUST IN TIME* compiled
You said: Then you need to make the distinction. javac and alternative JIT systems are considered distinct in Java-lore, and you know it.
What's your point? Nothing in the Java language spec says that "Java must be interpreted", Javachips exist, and even Transmeta demonstrated byte-code executing directly on their CPU. TowerJ, TurboJ, VisualCafe, SuperCede, Jove, and even GCJ all demonstrate direct native compilation of Java.
Java bytecode is nothing more then a intermediate compiler stage, just like GCC's RTL, or other intermediate compiler languages.
What matters is the real world implementations, and in the real world, most Java VM's use JIT compilation, and thus, are not executing intepreter loops, but translated bytecode-to-native code.
You can play semantics all you want, but you're still wrong. Perform a random sampling of Java VM's, and run a numerically intensive benchmark. Next, pick a random sampling of Perl implementations and run a similar benchmark. The result will be that Java will execute most low-level operations faster because of the preponderance of JIT's combined with the usage of real structs vs perl-pseudo datastructures. End result: Java is faster, contradicting your claims.
I said: Like I said, byte-code is merely a convenient compression technique for source code as far as Java is concerned.
You said: This is not correct - bytecode can include compile-time optimizations.
There are also *source code optimizers* out there which can perform transformations of C code without even compiling it. Technically, GCC does a lot of optimization at the RTL level, but again, RTL is just an intermediate representation.
But that's moot. In the real world VMs on Windows, Solaris, HP-UX, inside Oracle, on Tru64 UNIX, under OS/2, in AIX, and even on OS/390, Java bytecode is rarely interpreted. JIT's are used by default on all these platforms. You're basically wrong.
I said: All modern VM's compile to native x86 code during the loading process.
You said: That must be a real drag on a Sun box.
Hahah, trying to score debate points by nitpicking? Must be desperate. By the way, on my Solaris x86 box, it does indeed, translate bytecode to x86 code.
You said: Benchmarks are irrelevant - I care about the speed of working code I use everyday, in which case Java gets easily trounced by a number of other languages. If you want benchmarks, try The Practice of Programming by Kernighan and Pike. Its unbiased, unambiguous, and clearly shows what a dog Java is.
Let's stick to the topic at hand and compare Java to Perl execution speed, which as your original claim. I don't want to get into the C/C++ systems level debate. I view C personally as barely a step above assembly programming.
You claimed Java is a dog compared to Perl. *PROVE IT* Show me the applications your wrote in Perl and Java, otherwise shutup. For all intents and purposes, Java and Perl perform well enough to do most run-of-the-mill tasks like formatting database data on websites, and processing text.
If you want to bring C into it, I'll note that Perl is total DOG compared to C if you want to write a database, search engine, computational fluid dynamics, symbolic math, ray tracing, or video game in it.
So stop your FUD. You don't like writing Java code? Fine. You don't like Sun? Fine. But don't spew outright lies without backing up your claims, otherwise, someone is going to call you on them and embarrass you.
I said: Objects in perl for example (if you can call them that) (I proceeded to explain Perl's idea of a datastructure vs Java's)
You said: (obviously ignorant) Oh please, Java has the worst performing class library anywhere, even Javaworld.com lists articles describing this in detail. Besides the absurd object churn and heavy syncrhonization, Java's approach to objects is heavily verbose and basically treats developers like idiots.
Hahaha. Java's approach to objects is heavily verbose? Compared to what? C? C++? Eiffel? Objective-C? Smalltalk? Java syntax for objects is virtually lifted straight out of C/C++.
Object churn? Perl excels at this. Before Perl5, there wasn't even a way to pass structures, arrays, or hashes by reference. (Except for a hack technique using globals or aliases). Everytime you passed or returned data, you ended up making a copy, except if you only passed scalars and didn't copy them with the local(named args)=@_ technique. Perl5? Still tremendous object churn with arrays and hashtables being created up the wazoo everytime you do anything.
Boy, you sound ignorant. Please list those Javaworld articles, haha. Yeah, they criticized the old Vector/Hashtable, but of course, the newest HashMap/ArrayList perform much better, even better than the JGL, which they lauded, which is the Collections API won the Editor's Choice award.
I said: Perl isn't even always faster than Java at text processing.
You said: More conjecture. Provide hard data or clam up, cuz common wisdom says your full of it in this regard.
Easy. Just go grab the XML modules for Perl5 and compare the speed of the nonvalidating parsers against AElfred or XT on Java. (the Perl validating parsers would fare even worst) Next, go grab some XSLT modules in Perl for transforming XML. Now compare the performance to James Clark's XT, SAXON, EZ/X, Apache's Java XSLT project, or Oracle XSLT. I'm not going to run the benchmark for you, but if you run a dejanews search, you'll see some comparisons. We're talking an order of magnitude difference in some cases.
But enough about me, you're the person who opened his mouth and made the initial claims. *YOU* back them up. The burden of proof is on *YOU*, the person making the claim. If you can't, shutup.
Every JPython function is translated ultimately, to Java bytecode, so if Java's execution speed is slower than "Python", than JPython cannot be faster than Java since it is doing nothing but executing Java code!
JPython's "optimizer", which executes Java code, cannot run faster than Java, period. If I write a for() loop in Java, and one in Python, Python will be slower. The only way if could possibly be faster if it Python "removed" the loop, but Python doesn't do this.
Besides this, Python isn't much "higher level" than Java.
perl can just as easily create a list of lists of hashes of whatever and in one line as you have put.
] ] ? In fact I would say the syntax is strikingly similiar.
@a=(["a","b","c"],{"c" , ["d"]});
This line assigns to the array @a an array with two elements. First element is a reference to an array with elements "a","b","c", and the second element is a reference to a hash which has "c" for a key and an an reference to an array ( which contains "d") as the value. If you want to group the key value pairs, you can always use the '=>' operator or somesuch.
Tell me how that is any more hideous than x=['a','b',{'c':'d','e':['f','g']},['h',['i','j']
I was involved in this test. As someone else pointed out, we didn't write the Java; the guys at caucho.com did. All we did was fix the Perl code. I have to assume the Java code was written with speed in mind, since it was used to highlight the speed of their JSP tool.
This was simply a test between two programming environments we were considering. The results came out close enough that we decided we couldn't make a decision based on performance and ended up making it based on other factors.
Caucho's Resin is great, but don't underestimate the performance of mod_perl.
You make two separate references to claims for perl vs. java benchmarks. I already gave you one in my previous post - Kernighan and Pike.
Object churn? Perl excels at this. Before Perl5
Perl 5 is over five years old. Thats older than any production quality JDK. If you honestly expect me to take seriously a comparison of Java vs. Perl 4 (which is six years old), you're off your rocker. Of course, these are the only types of serious comparisons Java can handle. I'm sure Java is also quite favorable when comapred to PL/1.
Java syntax for objects is virtually lifted straight out of C/C++
Except they made Java both idiot proof and poorly performing by removing the virtual keyphrase. With Java you pay for a vtable whether you want it or not.
But lets face it, that is what Java is all about - making OO idiot-proof for the masses. Unfortunately, you get pissed on in the performance due to Sun's over-reaching assumptions.
I'm not going to run the benchmark for you
Thanks for playing, you've barked about benchmarks numerous times in your post but are unwilling to provide your own (even when I've given you a clear reference to a good unbiased comparison of perl and Java).
Heeheh ... assembler version ?
...
You know, C _is_ assembler version when it gets executed.
"Expressing the problem specification at a higher level allows greater degrees of freedom to the optimization machinery. "
It is exactly the other way around.
It is true that sometimes compiler can generated better asm code than begining asm programmer but only because it has hardcoded knowledge about particular ASM. However, hardcored knowledge can't compete with flexible mind the same way, expert systems can't compete with real thinking person
The TPOP benchmark was debunked a long time ago. Even TCHRIST didn't like it, even though it showed Perl leading. In fact, the first sloppy implementation showed C++ to be the slowest. (they retracted it) Pike/Kernigan are not exactly "unbiased" anymore than Bjarne S is, or the creator of Eiffel. And we known Tchrist isn't.
The Perl implementation uses a two-dimensional hashtable which requires an O(1) lookup to locate a prefix.
The Java implementation on the other hand, is totally different. It uses an object as the Hashtable key, it doesn't cache the value of the hashCode() function, the hashCode() function and the equals() method are both O(n) worst case. Thus, a large amount of time is spent calculating hashcodes, and because they don't preinitialize the hashtable, those objects get rehashed as the load factor goes up.
Continuing on, they don't use a BufferedInputStream for reading, they use StreamTokenizer on an interactive stream (docs warn against it), and of course, the benchmark was ran on an old VM.
I modified the code to use buffered I/O, and HashMap/ArrayList, plus hashCode() caching, and ran it on IBM JDK1.1.8 (with javax.util.collections) and JDK1.2.2 -classic. The result? My running time on a Celeron 400Mhz on Windows 2000 running JDK1.2.2 was 2.8 seconds total (not 9 seconds), and subtracting the startup time of the VM yields a runtime of 661 milliseconds, only 50% slower than their C-benchmark and 3 times faster than Perl (1.8 secs). If you leave in the startup time, 2.8 still isn't bad (vs 9 seconds they listed). Under JDK1.3RC1, the startup time reduced to yield 2.1 seconds total.
And of course, this is hampered by the inferior implementation they used. Let's switch to a 2-dimensional associative array approach and then do a comparison.
Except they made Java both idiot proof and poorly performing by removing the virtual keyphrase. With Java you pay for a vtable whether you want it or not
Patent nonsense. In the first place, you can use "final" if you want to. Non-virtual functions are idiotic, and cause a nonstop source of headaches in C++ code. See "Effective C++". virtual functions aren't slow, and in most cases, a C++ compiler can replace it with a direct dispatch.
Nevertheless, what makes it even more nonsense is that Java JIT's have enough dynamic type information at runtime to *INLINE* virtual functions. HotSpot does this, by profiling code at runtime, and replacing dispatch sites an inline version. The technique is no more sophisticated than branch prediction in CPUs.
Smalltalk compilers have been doing this for a while too.
But lets face it, that is what Java is all about - making OO idiot-proof for the masses. Unfortunately, you get pissed on in the performance due to Sun's over-reaching assumptions
Yeah, anyone who wants type safety is a idiot. And of course, you're a master programmer right? Programming in an idiot-proof language with automatic resource reclaimation (Perl), because you're not smart enough to write code in a real man's language like C or C++. Haha!
P.S. You're still wrong on performance. But keep writing your "top 5" website code, haha.
Geez, an "X vs Y" story and I have to scroll almost all the way to the end of the article before I find even a single flamewar! What's Slashdot coming to? Still, I suppose you earn some extra points by making the flamewar off-topic as well....
;-)
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
It's probably because Python encourages clean, readable code, and has mechanisms that make it easy for code to be self-documenting.
Which brings up one of the features I love about Python that hasn't been mentioned so far -- document strings. Modules, functions, classes and methods can have a constant string before any statements that is available at runtime as the __doc__ attribute. I find that this encourages me to write one for each of these entities as I create them, so that's there always a brief description of what a given procedure or class is meant to do.
Because they're available at runtime, they can serve to document code even when the source is unavailable. For example, a couple of weeks ago I was working with one of the libraries in the MacPython distribution that wraps part of the Mac toolbox. This library wasn't documented and was only provided as a binary shared library, so it wasn't clear how it was to be used. Since a module in Python can be used as a dictionary of functions and classes, I was able to find what functions the library provided by importing it and looking at its contents. For each of the functions, the document string gave a one line explanation of how to use it.
One of the most cynical deals recently involves the merger of two software companies trying to cash in on the Linux operating system craze: Andover.net Inc. of Acton, Mass., and VA Linux Systems Inc. of Sunnyvale, Calif.--which went public within 24 hours of each other back in early December. Less than eight weeks later, on Feb. 3, the two companies announced a stock-for-stock merger in which the California company has agreed to acquire the Massachusetts crowd for about 6 million shares of VA Linux and $60 million in cash. The cynicism in the transaction is not simply that the deal took place so shockingly soon after the two companies wrapped up their I.P.O.'s, but that the transaction included what amounted to a legalized bribe on the part of the VA Linux bunch to get the Andover.net crowd to accept the offer. The deal means that the $60 million in cash from VA Linux will go directly to Andover.net's shareholders, at $3.81 per share, in effect handing over the same amount of money Andover.net raised in the I.P.O. only weeks earlier. Prior to the I.P.O., the company's insiders had only paid a grand total of $15.7 million in cash into the company. Now they are being handed back $60 million as compensation. What a deal. As for investors in VA Linux, they are getting hosed. The company's stock was priced in the I.P.O. at $30 per share, but opened for trading at $299 and instantly shot to $320, then collapsed like many of the others and eight weeks later is now selling for $110. Faced with 39.7 million total shares outstanding already--of which only 4.4 million are held by the general public--investors in the stock can now look forward to the imminent registration of 4 million more shares by the company, which will doubtless come pouring into the market soon thereafter, thanks to the Andover.net deal. In other words, the only really valuable asset Andover.net ever had--its cash from the I.P.O.--was creamed off by the company's insiders almost the very instant they got their hands on it, leaving VA Linux's shareholders to face a 100 percent increase in the float of their own stock for the privilege of winding up with the worthless trash that the Andover.net bunch dumped at the very first opportunity.
Right. And what I wanted to point out is that it's not because the code is longer/more readable that it's less efficient (I was arguing that python code could be optimzed and that its human readability and good structure can actually help the compiler at doing a good job.)
Can anyone tell me if ZOPE is free sorftware? I went to the ZOPE web site but there's no reference to a licence.
Someone correct me if I'm off track here, but FUNCTIONAL != DECLARATIVE. In SQL, you say nothing about how to achieve a result. In a functional language you still have to say exactly how to solve it, it's just that you avoid assignment as a tool to solve it (leading to a whole lot of benefits). Admittedly a pure functional program starts to show some similarities to declaritive (like saying n! = n*(n-1), but it's not quite the same thing).
The evil python god will appear and squeeze the life out of you!
The current Slashdot moderation system is made by gay communists!
As always, it still depends on how good the compiler is. If it can optimise common p-code sequences to a compiled solution, or do run-time java-type stuff, then you're ahead.
For those of us who have been working with Perl a long time, but like the idea of a strong Web content management system, there is an alternative to learning Python. Midgard is a powerful open-source Web content management system that combines MySQL and Apache with the scripting power of PHP3. Definitely worth checking out, if you can get through the challenging installation. (As a hint, try using the Monster RPM under Linux, it's much easier.)
--
Paul Gillingwater
Paul Gillingwater
MBA, CISSP, CISM
Try C's "struct" keyword, or if you want it to be a little nicer, full classes in C++ ( if for nothing more than operator overloading.) If you really are talking about tuples in the mathematical sense, I think "struct" fits the bill. It just doesn't generally look like a tuple unless you are initializing it. C++ can fix this by overloading the function call operator.
In any case the difference is syntactic.
GNU OCTAL http://www.gnu.org/software/octal
What percentage of programmers can really out-do an optimizing "C" compiler by writing hardcoded assembler given the time constraints under which they typically must complete projects?
The fact is that modern optimizers are pretty damn good, and I say that as someone who wrote assembler code for Cray's CDC Cyber series to support 500 real-time graphics users simultaneously at 1/4 response time (Plato circa late 1970s -- about 1.5 million lines of COMPASS code written by the entire system staff) as well as tens of thousands of lines of assembler code for a multiuser BBS/Chat system with its own OS (FORA) that could support 32 simultaneous users on an 8MHz 8088 running at 2400bps flat out with 1/4 response time maximum.
Come back when you've accomplished similar feats and we'll discuss just how optimal humans, operating under real world constraints can make assembler code compared to optimizing compilers of higher level languages.
Seastead this.
Unlike Java and its ilk, Python doesn't make you write everything as objects and methods. You can write scripts using only functions and control structures if you like. Though having classes for doing things such as HTTP, XML parsing, database access, &c., is very useful. Though if you're violently averse to OOP, you can ignore that completely.
Unlike Perl, the syntax and implementation of the object-oriented features isn't hideous. Doing OO in Perl is only slightly less bogus than doing it in raw C with structs of function pointers. Much of this bogosity comes from Perl's crufty syntax when it comes to type-handling and declaration, which seems to have been (to paraphrase Douglas Adams) not so much designed as congealed. Behaviours and modes of usage were added as a series of afterthoughts, and hence, inconsistencies abound.
And furthermore, Perl's lists aren't a first-class data type. Thus you cannot have a list of lists, only a list of references to lists, using the @ operator. Attempting to pass a list of lists to a function flattens them all into one list. The requirement to explicitly delve into language mechanics to get something as simple as a list of lists is not something you'd expect from a high-level language.
I worked with Perl for several years, both professionally and on personal projects. After learning Python recently, I can say that I will probably never use Perl for anything more than a short throwaway hack, in its awk-on-steroids capacity. Several other programmers I know have reported similar experiences.
Seriously, I tend to skip all programming languages whos names start with a 'P'. Pascal? Python? Perl? PHP? Sorry, not for me. There is something strange about all programming languages starting with 'P'.
:-)) And in binary its code starts with 101. So are programming laungages starting with 'P' just for beginners?
'P's ASCII code is 120(oct), 80(dec), and 50(hex). All not serious numbers to me (pi is a serious number
No, no. If you want to ensure that I don't use your language, give it a name starting with 'P'.
Well, yes, however, isn't one of the virtues of Python that it makes it easier to maintain other peoples code? It's easy for a single programmer to be consistent - but Python forces consistency (to some degree) upon you, to make it easier to work with multiple people on code. With multiple coders come multiple editors. With multiple editors come different ways of indentation. While most programmers will use editors that will automatically indent as much as the previous line (usually, some editors will extra indent if the previous line ends with an opening brace/paren, or a colon), but they aren't consistent on how to pad the new line. Some editors will only use spaces, other editors will use as many tabs as possible. And while on programmer has a tabstop of 8, another has it set to 4.
Using a consistent indentation is good. But forcing it upon the programmer is, IMO, not the best solution. It's not necessary if there's only one programmer, and inconvenient when there are multiple programmers.
OTOH, save of vertical space does have merit. I usually don't care much about it; it isn't too hard to live by, although it sucks if all you want to do is a quick cut-and-paste job. For me, it's not a reason not to program in Python.
-- Abigail
In their book "Programming Perl" larry wall and tom christiansen advises the readers on several "ways of making perl code easier to read,understand, and maintain"?? hehe.. They said, "just bcoz you can do something a particular way doesnt mean you should do it that way" well why did you make Perl the way it is in the first place????? some of the most esoteric feature of perl are now obsolete or is being changed and i bet some of them are going to be in the next couple of years. Thank gawd we still have the Bell Labs folks (Brian Kerninghan, Al Aho, Jon Bentley, etc.). Perl is bad...bad...bad...it'll be obsolete as soon as newer..more elegant language takes its place...like Python..hehehe
Scintilla is good with Python.
http://www.scintilla.org/
linux&win32 available!!
your truly AC
Try the Python Language website, here.
Actually, there is fourth version of Python: Stackless Python - a version of Python which doesn't use the C Stack.
If you are wondering "Why?" right now, and the usual answer "Why Not?" doesn't satisfy, then the link goes some way toward explaining what the advantages are (specifically, much faster for some classes of problems).
You talking about writing entrire programs in ASM , I am talking about optimizing specific , usually small part of program. Of course compiler will do better job cause it can apply optimization to the whole program ... But it will never do a better job for something small and specific like transparent run-lenght encoded blit.
Half decent asm programmer will always be able to roll faster routine simply because he knows more at the problem at hand than compiler does.
With most languages, the syntax tells you what the program does, and the indentation tells you what the programmer intended.
The readable programs I see always include 'unneccessary' breaks between program sections, because it's actually neccessary to allow our brains to see patterns.
Well, you're close, except it would be the serpent to break the silence. And he would get much more insulting, while the pearled monk would be much nicer. At least this is the trent I've noticed on slashdot.
/x (admittedly, not that I've ever used it, if you know regular expressions they're generally clear enough)? So if you want readable code, write it. Yes, this takes a bit of discipline. Big deal. Force all your programmers to use strict. Have them run with -w every friday for good measure.
Perl people, believing that there's more than one way to do things and being adaptable creatures don't mind that python people use python at all. Python people, being something which forces them to try to convince the world that python is the way the truth and the light, do so.
I don't know why this is so. I don't know why the python people seem to insist that because perl is a big langauge it's bad. I don't know why they think that having to learn perl to use it makes it a bad language.
Perhaps python is a great language for beginners because it really forces them to do things that they should have learned anyhow. Maybe it's a great language because it doesn't differ from most other languages very much (this is usually called easy to learn). Maybe it's great because it's extremely inflexible because God talked directly to guido van rossam (sp?) and guido just wrote down the lines. I don't really know.
I do know that I think that a very heavily OO approach to problems is putting the theory before the practice and being way too anal. I like perl's modules because they give you the flexibility of OO with the reduction in typing of OO without giving you the increase in typing of B&D OO.
Besides, I can write a filter and then write very sloppy python code. If you need clean code, use strict and execute with -w. If you are stuck maintaining the code of someone who is sloppy and determinted to be so, your in trouble. Maybe python encourages writing clean code. So does perl -Mstrict -w when you get down to it. Probably more so. With the right packages installed perl will even check for Y2k bugs (a moot point nowadays).
The closest theory that I can come up with is that there are probably a few really intelligent python programmers, and these people aren't zealots. There are hords of mediocre python programmers, and these people are zealots because they lack the ability to learn many languages, especially if some of those languages aren't minimalistic languages.
As larry wall has said, there's more than one way to do it. Perl can be used to optimize for many different things. One of them is readability. There are readability flags in regular expressions, for crying out loud. Does python have
Do it how you want. I really just wish that the python fanatics would stop prattling that people need to be in chains before they'll be moral. In the end, that's why I'll never use python - any language whose main claim is to be nearly as good as perl but without any flexibility just isn't worth the time. I can go learn Alpha in binary if I really want minimum flexibility for maximum readability. Just think, only around 100 instructions to memorize and then I know the entire language! Just a few hours and I can read anyone's code and know instantly what it does!
They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- C. Sagan
All hashtables have unit time lookups. Crack open your undergrad text.
Yeah, anyone who wants type safety is a idiot
Then stay away from Java - the only way you're going to get useful polymorphism outside of templates (which Java doesn't support) is to excessively cast from base classes, perhaps as far up the tree as Object. Bye-Bye type safety.
P.S. You're still wrong
Blah Blah Blah...you STILL haven't provided me with one concrete unbiased performance suite that shows Java beating perl.
People who think coding is engineering favor python. They want a large and structured language where they can talk about larger and larger concepts more efficiently. The example is object oriented lanuages like C++ that brought structure to another level. Soon there will be another generation of languages, probably based around design patterns, kind of like a meta-object language. However, if you're a perl type who considers coding an art form, you believe in small and versatile languages that can express things in multiple ways. This takes more of the approach of mapping the language to the problem space. I personally code far better the perl way. Although it may be called sloppy by computer science types it really is the quickest and most natural way to solve a coding problem, rather than building sealed off layers of code that an engineer just places together like interchangable parts.
Using a consistent indentation is good. But forcing it upon the programmer is, IMO, not the best solution. It's not necessary if there's only one programmer, and inconvenient when there are multiple programmers.
It is horrible to have multiple ways of indentation within one project in combination with version control tools. If you try to do a diff between two versions to see the differences, often you see 10% real diffs, and 90% where someone just changed the indentation (like Emacs with it's auto-indent-region). Thus it is great to force people within a team to use the same indentation conventions.
The only thing that makes sense to me is to always use one tab for one indentation level. To how much space a tab expands, everyone can choose for himself (and doesn't affect the contents of the file).
Seems that we just found the latest person on Earth not having ever heard of JIt compilation and Hotspot...
Except they made Java both idiot proof and poorly performing by removing the virtual keyphrase. With Java you pay for a vtable whether you want it or not.
Hum, and never heard of the final keyword as well... Why bother others if you really don't know anything about Java ?
Java bytecode isn't Java -- it is an abstract high level assembler which is relatively language independent.
Besides this, Python isn't much "higher level" than Java.
The experience of my professional acquaintances who have worked extensively in both Python and Java (~100K line applications) tell me they can get the same job done in about 1/4 the number of lines in Python and maybe 1/5 the lines in Perl.
These are guys who have been doing OO programming in Java's progenitor, Objective C, ever since the beta release of the NeXT cube and follow design patterns rigorously (as well as teach the subject on occasion).
Seastead this.
There is evidence that using genetic algorithms, best practice human optimization of specific functions have been substantially beaten by machine evolved algorithms. Having used these optimization techniques in other systems myself, I find such claims plausible. It may be a while before sophisticated compiler optimization technology actually exploits JPython's higher level expressive power than Java and produces the faster JVM sequences for the same application, but the point is that arguments that this is impossible in principle are bogus. This is a little like the argument over whether machines will ever beat humans at chess. That argument has now been put to rest. Machines are routinely playing chess at Grand Master level. This isn't general artificial intelligence -- but it is usefully specialized "AI".
Seastead this.
I agree that mathematical algorithms are slower in perl. I too have written nested loops of matrix manipulations, and they were inexcusibly slow. Even when you specifiy integer only, and use for( 0..100) instead of for( $i = 0 ; $i ( notice my aversion towards the bastard word "proof" ).
Perl is glue, and should be treated as such. You can't write big perl programs without having an intimiate understanding of C ( since you're bound to call a great many c-library functions, and you really should consider writing stuff in C in tandem ).
In this respect, perl has the potential to be faster than Java for certain classes of projects. In general, an all native project will run faster in java IF, the delay in JIT ( or VM loading/ initialization for that matter ) compilation is marginalized away by either a sufficiently large computationally intensive core, or through persistent operation ( serverlet, etc ). Otherwise, gcc optimizations are bound to make better work of the perl-c libraries, than JIT will on the java-byte-code.
In my experience, the load time of java applications is very frustrating. Perl has very little to initialize, and is single processed at that, so will run faster than java-native-threads for simple applications. Plus I rarely find a perl-daemon eating up 100% of my CPU time, which I have regularly found in java ( at least netscape's version of it ). As a disclaimer, these are _my_ experiences with Java, and I do not claim this to be the general case. I'm sure bad code design had much to do with it.
-Michael
Python gets compiled down to bytecode just like java in both CPython and JPython. So does Perl for that matter. It can be JIT'd but no one has done so as of yet with pure python, and jpython w/ JIT is a bit unreliable as of yet. (The java bytecode comes out like a java compiler on drugs, and some JITs don't seem to like it all that well)
JPython's speed hit over Java comes from the fact that it does name binding of everything at runtime, there is no concept of a final method, and everything has to come through a dictionary. Java can cache many of these things, but Python gives too much Smalltalk like message method handling controls for many of these facilities to work.
And all of your endorsements for java double as endorsements for JPython. I can just as easily import the java library into my JPython app.
Sanity is a sandbox. I prefer the swings.
I don't really agree that it is great, but Python is not helping you to force the same indentation levels throughout your program, let alone between versions.
The only thing that makes sense to me is to always use one tab for one indentation level. To how much space a tab expands, everyone can choose for himself (and doesn't affect the contents of the file).
Setting tab stops any other than 8 seems like a dumb idea to me. While most editors allow you to twiddle the length of a tabstop, other programs don't. Furthermore, there's no excuse of lines over 80 characters. But a twice indented line of 70 characters will fit in the 80 char limit if the tabstop is 4, while it won't fit it the tabstop is 6 or 8. Furthermore, it still doesn't solve the problem of some editors using leading spaces and others leading tabs on auto-indented lines. It just makes the problem worse.
IMO, the only "rule" that makes sense when it comes to indenting styles is: no tabs, ever.
-- Abigail
I think I'm in love.
No, as the web page I referenced before explained, Byte still had a reader base, and the group was as varied as it always had been. The varied readership made it harder to attract advertisers who wanted a focused audience. If an advertiser was selling Windows productivity software (sic.), they wanted "a Windows Magazine". If they were selling chips, they wanted "an Embedded Designer Magazine". etc.
They had too few advertisers, not too many.
The paper version of the magazine died a while back, but shortly afterward it was reborn and re-cast as an online mag (BYTE.com).
Lansdowne
I disagree.
The intent is fused with the actual performance.
How can you suggest that having two channels that can be desynchronized is a good thing?
dook, dook, dook!