Perl vs. Python: A Culture Comparison 351
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. "
How does Python deal with all types of whitespace? (Score:2)
No, Perl! No, Python! Idiot! (Score:2)
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.
Order vs Disorder (Score:2)
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
Re:No, Perl! No, Python! Idiot! (Score:2)
I've recently had to go through a bunch of old scripts written by people who were (at the time) pretty new to Perl. The simpler scripts were fine, but the more complicated they got, the more some real discipline would have helped the code.
I'm not advocating a B&D language like Pascal, but if it's a script that is important to our business operations, I turn on warnings and use strict. It's amazing how many local-looking variables were used as globals. Still, I'm happy to have Perl as my nth language. Hmm, good subject for a Slashpoll, "how many languages have you developed programs in?"
Pete
Re:Asbestos Underwear Anyone? (Score:2)
Don your asbestos!
You, you, and you. Break out the weapons!
You, you and you. Into the rigging!
And you! Put the kettle on..
Re:How does Python deal with all types of whitespa (Score:2)
python ==great to know (Score:2)
Re:JPython? (Score:2)
Typically, a scripting language has automatic variable declaration, doesn't need to be compiled before running, does little type checking, has high-powered built in types (assoc arrays, f.ex) and is easy to connect to prebuilt components (such as system libraries written in C or small helper programs such as grep). Python and perl both qualify.
Python (and these days perl) also have system language features such as OO and modules. In my very predjudiced taste, python's ortogonality ("there isn't more than one way to do it" -- none of this "current line" or "default argument" or "side-effecting comparisons" stuff that perl has) makes it more of a systems language than perl. In perl's defence, these very featuers make it very convenient for a wide array of tasks -- tasks that I don't do much, and hence my preference for Python.
This is a subject that has started more flame wars than any other language feature except maybe LISP's parens.
JPython is almost exactly like CPython, appart form the lack of certain default modules. Oh, and JPython can interface trivially with java -- this is a BIG win for me. I use it alot.
Re:How does Python deal with all types of whitespa (Score:2)
But no, I don't think tabs are treated the same as spaces(unless your editor automagically converts tabs to spaces...)
-AS
Indentation (Score:2)
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.
It has quite some advantages (Score:2)
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.
and Another Thing... (Score:2)
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.
Championship bout (Score:3)
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?
Natural Languages and P--- Languages (Score:5)
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...
Horay! We finally got coverage. Python rocks! (Score:2)
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!
Of Zope, whitespace and style (Score:4)
Zope sounded interesting, but I'm also checking out Mason [masonhq.com], 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?
No, Perl! No, Python! FOOL! (Score:2)
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
TIMTOWTDI -vs- KISS (Score:3)
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
Re:It has quite some advantages (Score:2)
This has not made Python easier to read for me, certainly.
Emacs works great on Python whitespace... (Score:2)
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
Re:How does Python deal with all types of whitespa (Score:2)
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!
Re:JPython? (Score:2)
I think it's neat that Python is small enough so that you stand a reasonable chance of implementing it on top of your system language of choice, be it C, Java, OCaml, Modula-3, or whatever.
How holy wars start.... (Score:5)
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.
Zope for Perl (Score:2)
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 [manning.com]), 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 [everydevel.com] engine is very flexible, and Slash [slashcode.com] lets you get a lot done, there's really nothing out there like Zope [zope.org] for Perl.
At the risk of a shameless plug, let me just say that that's why i started Jellybean [sourceforge.net].
--
Re:Order vs Disorder (Score:3)
> 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.
What? Because Python forces you to a strict coding style doesn't mean that your code is "correct". It's still possible to write a bad algorithm in Python, just as it is in Perl.
> Its the difference between grafting OOP into a
> text processing language or including it from
> the start.
Perhaps you should actually point out some limitations of Perl's OOP. Maybe you could also explain what this has to do with your own code quality.
> 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.)
What are you talking about? Sure it's possible to write Perl code on one line, just as in many other languages. Unless you're an idiot, or purposefully writing obfuscated code, it's generally not done.
I'm sick of all these comments complaining about how hard Perl code is to read.
Providing that:
a) you actually know the language, and
b) the code was written by someone who actually knows the language
You should have zero problems with readability. Remarkably enough, the above applies for nearly every other programming language.
> From someone who has dabbled in both and used
> neither significantly.
Like so many others in this discussion, I doubt that you're qualified to make such broad assumptions about either language.
Library interface between Perl and Python (Score:3)
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?
Re:how to comment perl (Score:2)
Anyway. I don't believe in comments particularly. I'm firmly of the "if you can't read it and it's valid perl, that's your sad loss" mentality. Not that this allows me to go out of my way to obfuscate code, but if it's something the way I'd expect to read it, then I expect you to read it the same too.
Amongst other things, if you're paying me to write perl, you're not paying me to write English. If you can't read it, that's your bad lookout. There's nothing worse than excessive real-language usage for confusion or wasteage. (C.f. SQL, COBOL,
Perl for now, Python later (maybe?) (Score:2)
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.org]. Worldforge is going to be a massively-multiplayer online game. Neat stuff.
numb
Re:Closures? (Score:2)
ftp://ftp.cs.usyd.edu.au/jskaller/viper_2_0_a1.
What is wrong with closures in CPython?
Burris
I must be an exception to the norm :) (Score:2)
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 :)
Re: Perl/Python faster than Java (Wrong) (Score:3)
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.
Solution (Score:2)
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.
#############################################
Re:Natural Languages and P--- Languages (Score:2)
This seems to do a pretty good job of summarizing the philosophical differences between Perl and Python, but I think that the writer makes but ignores an important point. It's true that you want to incorporate structure into some forms of communication and programming, but that doesn't prevent the use of a natural language. After all the air-traffic controlers he mentions are still speaking English- they're just using a controlled syntatic and semantic subset of English. The same thing is true of Perl; if you want to do something rigidly structured, you can limit yourself to a subset of the available semantics and syntax and produce a rigidly structured program.
The converse is not true, though. If you start out with a language with rigidly structured syntax and limited vocabulary, you will have a hard time expressing yourself freely.
And this is a great example of the point. A haiku is nothing if not rigidly structured, but it's quite possible to express both haiku and air-traffic controls using English. A language designed specifically for one or the other, though will never be able to do both.
Re:I must be an exception to the norm :) (Score:2)
i'm also not fond of its naive scoping rules (i have a slight conceptual disagreement with passing parameters as themselves, e.g. lambda x=x). the list slicing semantics is inconsistent -- 1-based in one slot and zero-based in the other. much of python and perl seem to have been based on "what's good for guido/larry is good for everyone". I guess i identify with larry's warped and confused mind better.
i like cats. when was the last time you had to walk the cat?
Re:How does Python deal with all types of whitespa (Score:3)
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.
Re:how to comment perl (Score:2)
I don't mean to pick on PigleT here... but I think this attitude is absolutely terrible... even rather iconic of tech mistakes.
If I am hiring someone to write code (in whatever language, this isn't about Perl/Python specifically), I am most certainly also hiring them to write English. I just simply do not want to hire someone whose only strong language is a programming language (rather than also a natural language). If anything, for almost any real-life programming job, the natural language skills are a lot more important to doing the job well than are the programming language skills.
I have inherited a fair amount of code that suffers from just the problem I am pointing at. Programmers who really have quite poor verbal skills, but think of altogether too clever ways of doing a programming job. This is almost completely worthless six months later. And as likely as not, it winds up missing the real business requirements of a given job... since it is only clever programming; not equally clever specification and technical analysis.
Re:Bzzzt...The Winner is Java (Score:2)
Well, try editing their launching scripts and run them all in the same VM. Or try adding -X parameters to alter the default memory. I run about 6 Java servers on my site: SMTP, POP, Tomcat/Servlets, Enterprise Java Beans, stand alone image generating servlet, and an separate RMI server. The machine has 256Megs of ram and is not stressed (it also runs Oracle8 with 100 instances)
Re:Championship bout (Score:2)
new religion in programming world. (Score:2)
I just saw this article [ibm.com] over @ IBM's developerWorks [ibm.com], 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 [ibm.com] by the way.
Interesting things about Python and Java (Score:3)
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 [jpython.org].
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[:
Re:I must be an exception to the norm :) (Score:2)
As for the whitespace thing, it's really something that's hard to measure objectively. If a language doesn't have the right "feel", it gets uncomfortable to stick with all day long. Perl's little language inconsistancies never felt right to me, and I found Python much more pleasurable to spend in over my typical workday. Other people no doubt feel the opposite. Fortunately there's more than enough room for the Other Scripting Language in the world.
I like dogs. Walks are good for me :) And its nice to have someone that's happy to see me when I get home.
Re:Of Zope, whitespace and style (Score:2)
3 years ago, it was still the way to go.
2 years ago, things like Zope, Cold Fusion and Tango became the way to go.
Unfortunately, all of these have the same problem... they tie the interface and the logic together into one big mess. Great for throwing together a quick web page, or even a large, complex web site, but horrible for trying to maintain that website as new technologies come along. Why do you think that most major websites throw everything out and start over fresh every 6 months or so?
I've started playing around with WebObjects now, and I find it to be a lot more friendly to change. The interface is pretty much completely removed from the back end logic (which is then removed from the back-end data to boot), and I think it's great. Heck, I can take some of my current web-based apps, and throw a WAP-based interface on them with almost no effort at all. I can even take that web-based app and make it a stnad-alone Java application, with very little effort.
Of course, the biggest problem with WebObjects is the cost. Not too many folks can afford the $10,000 entrance fee to get started. The next biggest problem (for me anyhow) is that it doesn't support Perl. Damn. At least I can choose between C, C++, Objective C, and Java, but sometimes you just gotta have Perl.
Re:Order vs Disorder (Score:4)
$x->{'y'} versus x.y -- and let's not forget about x.__class__=mypackage.MyClass. Can you even do the latter in perl?
The distinction seems pretty clear to me... perl's class / package syntax is MUCH obviously cruftier. If you think that it's not ... well, then use perl for OOP. We disagree.
Have you ever tried to read befunge, or brainf***? I know these languages, and this is certainly NOT true for them. Perl also makes heavy use of punctuation marks to mean things which are not only not immediately obvious, they can be confusing. In fact, a quote from Larry Wall himself is "admittedly, readability suffers..."Perl is not as readable as python. If you don't have any trouble reading perl, that's anecdotal evidence... there is a statistically significant number of people who don't have any problems -- and in fact, enjoy -- reading python (read the python mailinglists, or c.l.python, or www.python.org, or #python on IRC... I've been to the perl equivalents, and I've never seen them advertising readability or maintainability), because it was designed to encourage that. This doesn't mean perl is worthless: it's a language feature of python to be consistent and easy to read. It is a language feature of perl to be terse and easy to write.
Finally, consider this python statement: x=['a','b',{'c':'d','e':['f','g']},['h',['i','j']] ]. I admit that perhaps I'm not the swiftest perl programmer ever, but it is certainly not that easy to make a data structure which is a list of strings, hashes of strings and lists, and lists of lists in perl. The syntax gets really hideous and doesn't mean what it looks like it should. (I can't even come up with a way to write that in perl on they short notice required for posting this comment: perhaps a better perl hacker than I can elucidate..)
Re:How does Python deal with all types of whitespa (Score:2)
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".
Re:Asbestos Underwear Anyone? (Score:4)
Re:How does Python deal with all types of whitespa (Score:3)
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
Re:Natural Languages and P--- Languages (Score:5)
Oh, you asked for it now...
Haiku
JFK Junior
Angle is too steep, pull up
Shit, call the coast guard
The Love Song of J. Alfred Pilot
Let us go then, flight 355
The 747 looks at the stretching sky
Like a patient etherised upon a table...
Where the heck's the flamewar? (Score:2)
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?
Re:Natural Languages and P--- Languages (Score:2)
is declaring pan pan pan
smoke in the cockpit
You should look into Oulipo, a literary movement dedicated to the idea that arbitrary constraints are actually a path to greater (more fundamental) creativity. Haiku are an earlier form of the same idea. Both have significant natural hacker appeal (although neither counts English as its native language).
In other words, python R0012, perl sucks, bee-otch.
Python in the real world (Score:3)
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
Re: Perl/Python faster than Java (Wrong) (Score:2)
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 [swarthmore.edu] in the mod_perl mailing list archive [swarthmore.edu]
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
Re:Cool! (Score:2)
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.
Re:Library interface between Perl and Python (Score:2)
$a[0]{'this'}[2]="value";
Creates or modifies an array where the 0th element is a hash, who's 'this' element is an array, who's 2nd element is "value";
perldoc perllol & perldoc perldsc will give you more than you need to know about nested data structures.
Re:Natural Languages and P--- Languages (Score:2)
While I agree with the vast majority of what you say, I think you are overstating it here:
To me the thing is that in programming languages, both the flexibility of a Perl and the regularity of a Python have their place. Just as in natural languages slang and say "medical terminology" or other highly formalized modes have a place.
It may seem at first that in programming a highly formalized language would always be better, since as you point out many times we are trying to precisely implement some spec or other. That begs the question though 'Which do you write more often, programs or prototypes of programs?' I find that I spend alot of times writing prototypes, in a very loose way, that I later refine into a much more formalized program, often in a much stricter language.
Another thing to think about, is that in natural languages many of these highly formalized modes are subsets of a big mess like say English. Perl and alot of other 'messy' computer languages show some notion of this with their pragmas like 'strict'. Maybe some of these more formal languages like Python need a pragma like 'loose' which says, "Let me indent anyway I want, and shine the type-checking 'cuz I'm just talking to myself"? :)
Re:how to comment perl (Score:2)
# wait for job complete would probably fall into Pike's
Re:new religion in programming world. (Score:2)
For example, as pointed out in the c.l.p thread, the DeveloperWorks article says "For example, Perl's use of "@", "$", and "%" often causes considerable grief and confusion." The root problem the article's talking about is more the presence of explicit references, not the arbitrary syntax characters, but anyway... Later on, the article explains some of Ruby's syntax: ""var" specifies a local variable, "@var" specifies an instance variable, "$var" specifies a global variable." Hmm...
I remember postings years ago where people argued that Java would probably kill off Python, though Perl would survive. Thanks to JPython, Java now represents a growth area for Python, and one where Perl doesn't yet have anything comparable, so things turned out just the opposite. Neither Perl nor Python have killed off Tcl. Don't go talking about Ruby replacing other languages, because it certainly won't, and because such hype leads to bitter disappointment later. (See Java, again, for an example of that.)
Cosing Standards (Score:2)
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>
Killer App & TMTOWTDI (Score:3)
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.
Re:Order vs Disorder (Score:3)
Providing that:
a) you actually know the language, and
b) the code was written by someone who actually knows the language
You should have zero problems with readability. Remarkably enough, the above applies for nearly every other programming language.
And I'm sick of all these dismissive oversimplifications of a complex issue.
Some languages lend themselves more to readability than others.
Admittedly, readability has as much to do with the reader than it does with the writer, but there are some attributes of a programming language that make it more readable when the readers are most human programmers who might try to modify code.
For example, I can parse and completely understand the semantics of simple aritmetic more easily than I can most English prose. This is true, even though I spend probably a minumum of 1000 times more time practicing writing and reading English than I do with arithmetic. Thus, it's not a matter simply of experience with the language.
English prose is far more expressive and powerful and completely contains all the expression and power of simple arithmetic.
The TIMTOWTDI nature of Perl leads to a lot of different ways to express a program. To understand the semantics of a Perl program one might have to think in a number of different idioms. Depending on the original author, the different styles and idioms might cover a large subset of the language in a given program, and Perl is a "big" language, with lots of odd corners.
Here's an extract from a discussion I was involved in a few years back in comp.lang.perl.misc with none other than the redoubtable Randall Scwartz that I think helps illustrate the point I'm trying to make:
>>>>> "Jordan" == Jordan Henderson writes:
Jordan> For example, say I want to extract preformatted text from an HTML
Jordan> file. Note that this is not a general purpose preformatted-text-
Jordan> extractor, but it's handy for files where I can guarantee the
Jordan> format (in a case where I wrote the original HTML file with another
Jordan> program, for example):
Jordan> while () {
Jordan> last if
Jordan> }
Jordan> if (eof) die "HTML format bad, couldn't locate preformatted text.";
Jordan> while () {
Jordan> last if
Jordan> print;
Jordan> }
Jordan> if (eof)
Jordan> die "HTML format bad, couldn't locate end of preformatted text.";
Jordan> Is there a better, clearer way to do this sort of thing?
I usually write something like this:
$found = 0;
while () {
$where =
$found = 1, print if $where;
last if $where =~
}
die "we didn't find it!" unless $found;
print "Just another Perl hacker,"
--
Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying
Email: Snail: (Call)
PGP-Key: (finger merlyn@teleport.com)
Web: My Home Page! [stonehenge.com]
Quote: "I'm telling you, if I could have five lines in my
Now, I was somewhat of a Perl newbie and I'm still nowhere nearly at the level of a Randall Schwartz, but I had a hard time with Randall's answer at the time. I was familiar with the .. operator, but had never used it.
I still feel that my original attempt using the eof operator was simple and very readable. I also love the elegance of Randall's solution.
See, I like Perl, I really do. It's very expressive. Randall's solution points to many other opportunities for good use of the .. operator. I don't think it's the most readable, in this case.
There's the rub. The most readable solution may not use the most expressive idioms. Readability isn't the only criteria on which to judge a work. Shakespeare is harder to read than Suess, but I don't want to be limited to a Suess-like style in my own writing
However, I'm sympathetic to the camp that seems to believe that computer languages should not have the same ambiguities and expressive power than natural languages. In some settings, it may be more productive to use languages with a more limited selection of possible idioms.
For example, I might prefer that an Air Traffic Control system be written in Ada rather than Perl. I want the maintainer of that code to be able to immediately and completely grasp the semantics of the code in front of him or her. I want the maintainer to be immediately comfortable with the style and choice of idioms.
Horses for Courses. Perl still excels in it's adaptability, it's functionality and it's expressive power. Python may excel in simplicity, it's applicability to programming language education and it's readability. I don't actually know Python so forgive me if I misrepresent it.
I'm glad I have simple arithmetic for some things. I'd hate to have to express number problems in English. I prefer "2 + 17 = 19" to "Two plus seventeen equals nineteen."
-Jordan Henderson
Re:How does Python deal with all types of whitespa (Score:2)
Because tab-whitespace is different than space-whitespace?
Again, unless tab = 8 spaces and you always uses 8 space indents...
-AS
Indentation problem solved for emacs haters (Score:2)
Perl does have an app like Zope: Iaijutsu (Score:2)
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 [ninjacode.com] 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 [ninjacode.com] 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 [ninjacode.com]'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 [ninjacode.com] 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 [ninjacode.com] because it seemed to me to be one of the most confusing aspects of Zope. However, acquisition is still possible in Iaijutsu [ninjacode.com]. (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 [ninjacode.com] 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 [ninjacode.com] has this, via Andy Wardley's awesome Template Toolkit [cpan.org].
However, unlike Zope, Iaijutsu [ninjacode.com] 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 [ninjacode.com]. 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.
Re:Order vs Disorder (Score:3)
Yeah, use bless. But your point is well taken. Perl's OO stuff is pretty much roll-your-own, which is great except when it sucks. I love Perl, but at times it's so crufty that I immediately revert to Scheme.
Well, actually, it's pretty straightforward:
The syntax is fairly clean, I think (although it does look much nicer when properly indented and formatted), although accessing it can be uglier:
One striking thing about Perl that I haven't seen in other language communities is the ease with which experienced programmers almost unconciously create personal dialects of the language. This is great for writing code, much less great for, say, fixing it. There are so many weird tricks possible, such a rich idiom, that it's natural to recycle exceptionally clever bits, sometimes (often?) to the detriment of readibility
In any event, both languages are fun to code in, and can certainly peacefully co-exist.
Cheers,
(jfb)Fortran 77 sux (Score:2)
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
Re:Zope for Perl (Score:2)
Re:Of Zope, whitespace and style (Score:2)
This is at the heart of the philosophy behind Iaijutsu [ninjacode.com]-- an open source, object oriented web content and application development framework written in Perl.
Iaijutsu [ninjacode.com] is similar to Zope in that content and application objects are created and maintained online, through folder trees and online forms. Classes can be created to handle various types of content (ie. GIF, PDF, XML, etc) in different ways. Classes can be created to do specific application tasks (ie. weblogs, discussion boards, parse headlines from RSS xml files)
However, where Iaijutsu [ninjacode.com] parts with many other systems is a discipline of separation of content, presentation, and logic. Content is composed in object properties. Presentation is done with a very flexible template language. Logic is done either in Perl object classes, or with a hybrid XML/Perl class definition document where properties, methods, templates used, and template accessors are defined with optional perl implementation blocks.
The separation is a discipline: Content should never be tied to the presentation or logic. Logic should never be contained in the presentation (ie. the application should never be built in the template language!!!). Presentation should never be dictated by the logic.
In this way, you can target the results of a well designed set of content and application classes to just about any presentation device. (ie. layout & graphic 'themes' or 'skins' for 5.0 web browsers, VoXML for telephone access, WAP for handhelds and phones, etc...) Think XSL and XML.
The right language for the job (or How Stop a War) (Score:2)
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
Re:Please learn how a JVM works (no, you learn) (Score:2)
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.
Go Python -- but better docs, please! (Score:2)
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!
Re: (Score:2)
And where does PHP fit in? (Score:2)
Re: Perl/Python faster than Java (Wrong) (Score:2)
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
Re:the one true way (Score:2)
If you've done any programming, you should know that the first rule of optimization is to optimize where it matters. If all of the CPU-intensive functions of a program are written in a low-level language, scripting languages can be incredibly helpful as the logical 'glue' to bind the low-level bits together. This is not a CPU-intensive task, generally, and makes the program more extensible and (generally) easier to write at the high level.
For an example of this, compare Sawmill, which wraps low-level C window management functions in Lisp and encodes all higher-level operations in Lisp routines, with Enlightenment, written entirely in the ever-so-efficient language of C.
How do they compare? Sawmill is faster, stabler, has a smaller memory footprint, and is infinitely more extensible than Enlightenment. And to pick a more fair opponent, it doesn't compare shabbily at all to some of the more 'lightweight' window managers such as fvwm or icewm; it's slightly less efficient, but not nearly as much as Enlightenment.
As long as the lowest level of stuff, where (presumably) the majority of CPU time is spent, is done efficiently, efficient design is far more important than highly optimized machine code.
Daniel
Re:TIMTOWTDI -vs- KISS (Score:2)
In Smalltalk, for instance, collections (of which tuples would only be a subset) are objects on par with anything else -- integers, booleans, etc. Collections and their associated functionality are one of my favorite parts of Smalltalk.
Though I haven't used them, my impression of APL and J (a successor) are that they allow manipulation of collections -- arrays and matrices -- superior to most languages.
And any Lisp treats lists as first-class objects, and usually vectors (equivalent to tuples and arrays) as well.
What's always struck me is how people could stand not to have collections as first-class objects. C with it's horrid pointer arithmetic, Tcl with it's disfunctional string/lists... ugh. Collections of objects are one of the fundamental parts of programming, right along with numbers and bytes. Every language should consider collections as a core part of the language.
Most languages don't allow the sort of implicit packing and unpacking of tuples that Python does (as in a, b = (1, 2)) -- though there are a number. I don't think there's anything Python does that some other language hasn't done before. Not to criticize Python for it. It's not wrong to learn from the past.
Maybe the difference is expressiveness? (Score:2)
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.
Re:Horay! We finally got coverage. Python rocks! (Score:2)
You haven't used Lisp, have you?
Lisp (actually Scheme) code:
(define a '(1 2 3 4 5 6 7))
(define f (lambda (x) (lambda (y) (map (lambda (n) (+ n x)) y))))
(define b ((f 5) a))
(define c ((f 6) a))
(b is '(6 7 8 9 10 11 12), c is '(7 8 9 10 11 12 13))
I tried but failed to write the equivalent C code. However, here's the equivalent of (map (lambda (n) (+ n 1)) lst) in c, except that it modifies the list in place:
typedef int (*unaryfunc)(int);
int addone(int x)
{
return x+1;
}
void map(int *lst, int len, unaryfunc f)
{
int i;
for(i=0; ilen; i++)
lst[i]=f(lst[i]);
}
.
.
.
map(some_lst, some_lst_len, addone);
Tell me that's more logical and concise?
Daniel
Re:Java still broken after years of hype (Score:2)
Synchronization in the collection classes only has a minor impact on the modern JIT's. Why don't *YOU* try writing some simply benchmarks to test synchronization in Java, or go look up the old Dr. Dobb's articles. In both the Symantec JIT and Hotspot VM, a non-contended monitor has neglible impact. Back when I was a HotSpot beta tester, I run benchmarks on the interpreter vs the classic (symantec) JIT, vs HotSpot, and tests showed neglible differences between synchronized and non-sychronized methods. For pure-interpretative, on the old JDK1.1 VM's, sure, sync'ed methods could have a perform hit of up to 50 times slower.
Even so, the Java2 collection classes solve the "problem", and they are available for JDK1.1 as standard extensions, plus you could always use ObjectSpace's JGL.
Parametric Polymorphism is being worked on, because they are trying to it right, not simply copy C++'s bloated mess and poor implementation (cause by a beyond-dumb linker requirement)
Contrary to your FUD however, Java is not falling off the radar. Recent studies in InfoWeek reveal that the number of Java programmers just edged out C++ programmers for the first time.
Re:Java is verbose (Score:2)
So? The same goes for C and C++. That's because Perl has built-in syntactic sugar for Hashtable and Array manipulation, plus variable interpolation, so one can avoid concatenation and printf() style APIs.
This hardly makes it the language of choice. It makes it great for quickly prototyping something. But when it comes time to write the final implementation, why should I care about syntactic sugar vs readability and documentation. Verbosity has its benefits too.
Perl's lack of named parameters for instance, makes it exceeding difficult to write something like JavaDoc or LXR.
Re:TIMTOWTDI -vs- KISS (Score:2)
Re:TIMTOWTDI -vs- KISS (Score:2)
I'm not challenging you so much as I can't think of anything that PERL let's you do that Python prohibits from from.
I think the way I see the differences between PERL and Python is that Larry has added everything including the kitchen sink to PERL. Guido is very careful about adding new things to python. (part of this may have to do with popularity, PERL is huge and has had far more developers than python has, should python's popularity continue to grow maybe it will become more complex) If there is some programming construct and you want it, it's probably in perl. It has to be compelling enough to be added to python. Python had a fairly complete design idea at the start where PERL was simple and stuff keeps getting thrown in to PERL which adds complexity.
I think the tersness of PERL code and the obfuscated feel of it (IMO) are a result of the syntax and how so many things have been added to the language, not that it some how liberates you to code things that python doesn't in the name of performance. As has already been said, PERL needs to simmer a little, the best of PERL needs to be sifted out and morphed into something else.
Re: Perl/Python faster than Java (Wrong) (Score:2)
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
Functional Scripting Langauges (Score:2)
Now, a monadic functional langauge like Haskell [haskell.org] 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..
Re: Perl/Python faster than Java (Wrong) (Score:2)
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...
Re:Fortran 77 sux (Score:2)
In any event, I recommend using '(setq indent-tabs-mode nil)' in Emacs to avoid the tabs in the first place (and something like Emacs' python-mode to keep your indentation consistent).
We don't need no stinkin' examples! (Score:2)
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
Re:Natural Languages and P--- Languages (Score:2)
> highly structured, syntactically and lexically
> limited, and stereotypical fashion!
While I would agree with this statement about air traffic control, I don't think it holds in other "precision" areas. A mathematician can grapple with concepts which seem hopelessly impenetrable, because of the flexibility that mathematical notation gives him to express his problem in a way which just features the important points, and not the irrelevant information. A good programmer can tackle a complex problem in an elegant and maintainable way if his programming language gives him the same flexibility.
Of course, many problems are not very complex and/or are being tackled by mediocre programmers. In this case, a language with inflexible notation is more appropriate because using esoteric syntax won't lead to a more elegant or more maintainable program.
Re:Compiler-level optimization (Score:2)
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
Game Over (Score:2)
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 [mozart-oz.org].
How Python sucks: (Score:2)
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.
Re:Please learn how a JVM works (no, you learn) (Score:2)
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.
Re: Perl/Python faster than Java (Wrong) (Score:2)
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.
Re:Java is verbose (Score:2)
When you write something more significant than a 500 line program, and have to work with a team of people who must understand and re-use your code, then let's talk about "valuing your time"
What does terseness of syntax have to do with THINKing? Except maybe in Obsfucated Perl contests, I don't see what value it has. Why do you use Intercal or ALGOLthen?
Perl's lack of named parameters have nothing to do with dynamic programming, and if you weren't 12 years old, you'd realize people were doing "dynamic" programming with Lisp a long time ago. Lisp can dynamically create and bind new subroutines at runtime *with* named parameters. So can Self, Smalltalk, and Objective-C I believe.
Java1.3 can also do this with proxy classes, and with Java1.0-1.2, it can be done with a custom class loader.
I have little need for Perl's autoloader and symbol table tricks, nor self-modifying or dynamically generated code. Such tricks are hacks to prevent refactoring code, and end up being unmaintainable over the long term.
I await you posting a significant Perl module that you have developed using these tricks.
Re:Java is verbose (Score:2)
Re:Please learn how a JVM works (no, you learn) (Score:2)
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.
Re:TIMTOWTDI -vs- KISS (Score:2)
The particular class inheritance isn't really a matter of functionality. In Smalltalk Integers don't even inherit directly from Object, nor True or False. I don't think that implies they aren't important to the language.
Almost every language provides some optimization for tuples. The only exceptions I can think of are Lisp languages, where lists are more important than tuples, and maybe some low-functionality languages like m4 (which hardly count).Python does have some syntactic sugar for tuples, and I won't say that's unimportant. But I don't think that makes something quite first-order or not. (doesn't Icon have similar syntactic sugar?)
In Smalltalk you can do "#(1 2 3)" to make a tuple, or even "{x. y. z}" if you are using Squeak [squeak.org] (which is the only Smalltalk I'm really familiar with). For other collections, you can use "#(1 2 3) as: Set" which will inline a Set into the code (as opposed to creating it at runtime). You can even do "{a. b} := #(1 2)" in Squeak, though nobody uses it and for half the releases it's broken.
In Scheme and other Lisps lists are more important, but their functionality is probably more powerful, since they are used for everything (even the syntax). There's no unpacking for assignment, but then assignment is almost looked down on :-/
I don't think Python is the most of anything. That's not bad, but it's definately a language of refinement not revolution. The only really novel think, I think, is the indentation.
Yahoo! We finally have a flamewar! (Score:2)
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....
;-)
Re:Java is verbose (Score:2)
Re:Java is verbose (Score:2)
The same line of code could be written as
sub_array = grep(pattern, array);
in C/C++/Java. Or
sub_array = array.grep(pattern)
You're arguing that a Java programmer would INLINE a for loop to iterate over it, but I would argue that most programmers would provide a subroutine for this idiom.
Neither is really superior. On the other hand, typeless variables cause more confusion the first time a coder looks at them. In perl, I can't just look at a subroutine declaration to determine what it returns. I have to seek out and check all return() statements within the routine to determine the range of types.
The following code
$obj = new MyObject($foo);
$blah = $obj->func($bar);
Provides no clues from context. Whereas
MyObject obj = new MyObject(arg);
Record r = obj.func(bar);
makes it clear what 'r' is, and what documentation I should look up.
As for named parameters, in C, C++, Java, Eiffel, and just about every stongly typed language, in addition to Lisp, etc, you can declare the types and names of subroutine variables
public int add(Complex c1, Real r2);
whereas in Perl, this looks like
sub add ($$) {}
With C/C++/Java, the arguments are passed by reference and by copy into the named parameters. With Perl, either peope write code like the following
sub foo ($$)
{
my $blah = $_[0] * $_[1];
}
which in my opinion, sucks, because looking at the subroutine, you have no idea what the arguments represent. You may as well write a program where every variable name is $x, $x1, $x2, etc. There *are* valid reasons for choosing verbose function and variable names to provide better understandability. You either make the variable names understandable, or you have to write very nice documentation.
To continue on, to name variables, you have to explicitly copy and assign them.
sub foo ($$)
{
my($interestRate, $principle)=@_;
my $interest = $interestRate * $principle;
}
The situation gets worse with OO, since you must remember to always pass "this"
sub calc
{
my($self, $principle}=@_;
return $self->{interest}*$principle;
}
Finally, Perl encourages broad use of implicit unnamed variables. Like, for instance, $_. Most of the library operates and returns data on these variables by default if unspecified. Convenient, but hard to understand unless you have completely mastered and memorized the function prototypes for all the perlfunc's, otherwise, the functioning of a particular piece of code is unclear. Perl allows either method, my person style is long variable names, argument checking, carp, assertions, and documentation, when I am writing code *for other people's use*
Let's not even mention context-sensitive functions which work differently depending on whether they are used in a scalar or list context.
Or, what about all those global $ variables like $;, $>, $, $', $`, $*,
I'm not bashing perl, I've been writing Perl since 1991, and I've written some very significant modules and projects using it. I love perl.
But the people bashing verbose languages, strictly-typed languages, etc don't seem to understand the purpose of these languages, or why people want to use them. Hint: It's not because they are "idiots", and it's not purely for performance reasons.
Eiffel's design-by-contract is a perfect example. Eiffel is the language that Java should have been. All the verbosity in Eiffel forces one to do is to *THINK* about what your designing, and declare/document how it works or should work, to both the users of your code library, and to the compiler.
I'm for pluralism. I can't stand the "Linux only!" or "Perl only" crowd. You use what works, and everything has its place.
Re:In the end it was Zope (Score:2)
Re:Python in the real world (Score:2)
Ok, cool. What part of this is Perl lacking?
One thought: if you have trouble reading your own code in *any* language (even assembly) I suggest you start commenting your code and being a little bit more verbose. People who want to maintain your code will thank you for it.