I'd think 99% of people don't have access to a computer with 4Gb of RAM
4GB is not that extraordinary any more. Sure, you're not likely to see 4GB in too many people's desktop PCs, but is that the operative definition of "ordinary"? I'd say that any computer that the manufacturer can ship to you off an assembly line because they make thousands like it is ordinary, and that covers a lot of machines with a lot more than 4GB.
Actually, they need to revamp the system so that the abstract of the patent is announced and posted publicly
I'm not sure even that is safe, for some combination of the following reasons:
Even an abstract has to be detailed enough to distinguish the invention from other similar work. In many cases, it would be impossible to provide this necessary level of detail without also giving away the key ideas of the invention.
Companies would monitor these abstracts. Every one would be challenged multiple times, often based on only the slimmest of pretexts by big rich companies with no principles
Industrial espionage is real. I've seen it first hand. Publishing abstracts would basically be telling the thieves where to look.
Companies like the one in Redmond already have a tendency to announce vaporware for the sole purpose of squelching innovation by competitors. Publishing abstracts would allow them to do this more efficiently and effectively.
There's no shortage of companies that would be willing to steal an idea from an abstract, block the patent with bogus claims of prior art, and then outmuscle the inventor in the marketplace. The endless counterclaims would make the patent process even more cumbersome, making it even more difficult for the patent office to keep up. The net result would be that patents would fail to protect inventors - in fact it would make them even more vulnerable to various forms of predation - and nobody would bother filing for patents at all. Everything would end up being protected as trade secrets instead, meaning that they'd never be disclosed, and I don't think that would be a good thing.
I don't think abstracts should be made completely public. However, I think patents are important enough to justify a different solution: the patent office should, like a court, be able to subpoena experts within a technology area to comment on the potential validity of a patent. Obviously, some safeguards would have to exist:
Experts summoned thus would have to be subject to nondisclosure rules with criminal penalties behind them - as patent officers themselves are already.
The company filing a patent would have to have some right to challenge a particular expert, perhaps even peremptorily.
The experts themselves would have to have some right to excuse themselves to avoid conflicts of interest.
If examining patents were considered a civic duty for experts in a field, just like jury duty is for all citizens, I think that would be a big improvement. It would have the same effect as drastically increasing the number of patent officers, but without the cost. Obviously there would still be a lot of legal wrangling going on, but I believe it would be a lot less than currently.
I know it's not fashionable to look at things from the enemy's perspective, but has it ever occurred to you folks that the reason there are so few good managers is that managing people is hard? Let's try looking at this from a couple of different perspectives.
Look around you, right here on slashdot. Pick a half-dozen messages from this very thread. Would you want to manage a group consisting of the people who wrote those messages? Well, I know I sure as hell wouldn't. "Herding cats" doesn't tell half of it. Most cats are at least a little bit predictable, sleep a lot, occasionally show affection or at least look cute, etc. Maybe herding really smelly ill-tempered cats who miss the litterbox regularly and have a tendency to use your legs as scratching posts at every opportunity is getting close.
Managers get to spend a lot of time cooped up in small windowless rooms all day with other managers. Sounds like a working definition of hell to me. It's like No Exit. Every organization has people who will try to screw you and who are good at it. Even if such people are only 10% of the managers, that's enough to keep the other 90% going to the meetings and making sure they and their people don't get totally worked over.
Most managers get next to no training. Trying to keep a non-trivial project, particularly one that involves new technology, on track takes some doing. Trying to juggle the desire of everyone in the group to go off and do the Next Cool Thing while you still have products to ship is tricky. Dealing with the conflicts between the two would-be Top Guns in your group, or between the Process Weenie and the Cowboy, or between the NT bigots and the UNIX zealots, could drive anyone insane. And then someone comes along with a patent issue or a sexual harassment lawsuit and your goose is truly cooked.
Where are you going to find good people to do all this? Where do you find someone who can keep both the technical details and the corporate goals in mind, who's reasonably intelligent and has a decent set of ethics and yet doesn't mind sitting in rooms full of Machiavelli wannabes and Just Plain Dumb people, and who's willing - all to often - to do all that for less money than some of the people "under" them get paid? There really is a shortage of quality people in the industry, but it's not a shortage of hands-on techies; it's a shortage of managers who aren't scum or morons or both.
I whine about my job as much as anyone, but I honestly don't think there's anything I could find myself doing in my prized role as an individual contributor that would be worse than being a manager. It is necessary to have someone else to do all that stuff, but I'm damn glad it's not me. Next time you feel like a few minutes of manager-bashing, spare yourself at least one second to give thanks that you have a better job than they do.
Firstly, "term of art" is an incredibly pretentious phrase, beloved by lawyers (and wannabes) but generally shunned by true technical people.
Secondly, hot potato is indeed a "term of art"...one which has had a clear and well-understood meaning for twenty years and which does not apply to the routing we're talking about. Real network professionals know that; it's only the tyros and dilettantes who slept through their basic networking class (or never took one) who would abuse such a time-honored and universal term. Read any basic networking text; they're all very clear on what "hot potato" routing is and is not.
I know I'm coming in rather late, but I just have to object to the abuse of the term "hot potato" to describe the common backbone routing policies. True hot-potato routing is totally naive with regard to network distances from a destination; it just forwards to some node (or in this case network) other than the one the packet came in on - usually the one with the shortest queue length. This will often end up routing a packet away from its destination. If backbone providers truly did things this way, packets would wander around quite aimlessly, often expiring before they reached their destinations. Every backbone provider would get saturated with such "lost" packets, creating more traffic for all of them and leading to a complete collapse of the Internet.
Obviously, that is not what's really happening. I'd call the technique in common use "warm potato" instead. Providers do want to dump the packet on someone else quickly, but subject to the limitation that they dump it at least a tiny bit nearer the destination than when they received it. This is still strongly suboptimal[1] and slightly antisocial, but it's nothing like true hot potato.
[1] It actually approximates hierarchical routing rather closely. The efficiency loss (in terms of hops) of hierarchical routing has been thoroughly studied and quantified by Tanenbaum and many others, but it does have the (sometimes critical) advantage of keeping routing-table sizes under control. As others have pointed out, one of the weaknesses of InterNAP's approach is the potentially very large number of routes involved. None of this is new. It has all been well understood in the networking community for decades.
INS requires that the employer pays at least 90% of prevailing wages for the position.
Then I have to wonder how they determine the prevailing wage. I work with a whole bunch of H1-B folks, mostly from China and the Indian subcontinent, and they are consistently paid 75% or less of what their skills are worth. One trick that seems to be involved in skirting the INS rules is hiring people with senior-engineer skills into junior-engineer jobs and paying them junior-engineer salaries.
Does source code for software comissioned by the Government not go into the public domain? If not, why not?
Security comes immediately to mind as a possible answer. I don't just mean military-style security either, though that's certainly an important case, but also defense-against-crackers kind of security. I don't think the "more eyes and brains improving the code" theory would apply to the government. If there were an exploitable bug in some piece of IRS code, for example, does anyone really think there'd be lots of people offering them a fix? Hell no, everyone would be exploiting it. When there are practically no white hats and millions of would-be black hats, "security through obscurity" might not be a totally bad policy.
I haven't used exceptions; so far, it looks like a way to check for error codes after something has already screwed up, and I'm not convinced its a good approach yet.
Well, exceptions encompass a lot more than true errors - resource unavailability, deliberately aborted waits, etc. etc. In a large program, where the function that recognizes a condition may be several calls removed from the topmost function that needs to know about it, propagating status codes all the time gets real old, real fast. Exceptions provide a way to streamline the whole process quite nicely.
However, I'm also starting to learn Java, so I'm sure I'll see how they use it.
IIRC, Java's exception model was fairly reasonable but the common usage of exceptions was somewhat less so. Like anything, exceptions can be abused or used wrongly, so you need to be careful to distinguish the usage from the model.
I think "my" is a feature, I just wish it was the default. However, Perl defaults to something simple for the novice--making variables global.
Well, the simplest scope of all is no local variables at all. Everything's global. You could even do away with function arguments as such; if you want to pass parameters to foo() you just assign to foo_x, foo_y, etc. before you call it and the return value is in foo_result. Or you could use a register-like model.
Obviously, simplest isn't necessarily best here, even though in general simplicity is a virtue. The question is which model provides the best balance between expressiveness, intuition, flexibility, etc. Personally, I think it's safer to have things be local by default to avoid unintended name clashes than to have them be global by default. Those kind of bugs tend to be really nasty to track down, and having too much stuff global makes them all but inevitable.
AFAIK, both Perl and Python use reference-counting garbage collectors
Historically yes, but that's one of the biggest changes for Python 2.0. Extension writers still have to manipulate refcounts, but Python itself can apparently figure out that if all of the references to objects in a set are satisfied by other objects also in that set then the whole set must be disconnected from anything else and can be GC'ed. That's about as good as you're going to get in such a thoroughly extensible language, I think.
I'm silently debating to myself over syntax-parsing and data-type handling at the moment
Does Perl have modules specifically geared toward language processing? I'm quite sure Python does.
Perl...provides wonderful modules for CGI and database integration. I suppose Python has its own modules for this
You bet. Some of the very biggest web players use Python rather than Perl for this kind of stuff, and I've yet to hear of a serious Perl equivalent to Zope. Check out the Vaults of Parnassus sometime; even compared to CPAN, the variety of modules represented there is pretty impressive.
Well, it was just a simple example of how to add syntax, really, but notice how cleanly it integrates into the rest of Perl; that's the impressive part.
I agree that it's kind of cool that you can do that in Perl. OTOH, I have mixed feelings about being able to add arbitrary syntax like this. I've seen operator overloading abused far more often than I've seen it used at all reasonably, causing no end of headaches for people who have to work with code written using it, and this capability seems like operator overloading on steroids. I know Schemers love the feel of creating a language specific to each problem, but my experience out here in the Real World tells me that's an express ticket to Trouble.
I'm also still curious about whether this facility can be used to create a real exception mechanism - one that has finally and rethrow, that doesn't succumb to creepy scope problems, etc. I'm a little skeptical, actually, and decent exception handling is something I believe should be part of any modern programming language.
I haven't really used Tcl either, but it looks like it has its own unique, interesting syntax
That's putting it politely. I've been critical of Perl, but that's nothing compared to how I feel about Tcl. Tk is great, I use it a lot via Python's native Tkinter interface, so I get to read a fair amount of documentation written for Tcl users, and none of it has made me think better of the language. Perl may be a mistake, but Tcl is a true crime against reason.
They do make it harder to implement C extensions, but again most of the time you probably don't need to do that, and CPAN has more than enough modules for doing everything else
Being able to compile Perl into C is definitely cool. Python's equivalent is "freeze" which does some magic to collect all of the modules you need plus a runtime and bundle them into an executable. I've never tried it, so I don't know how well it works; from time to time I've wondered how it handles things like eval and exec, and it seems like certain forms of dynamic behavior would be almost impossible to support.
That said, it's just not the same as being able to create a true dynamically loadable extension module which can define its own types etc. and be loaded into a running language-interpreter instance. For example, it can be very handy to choose at runtime which module you load to perform a function, or fall back from one to another if the first isn't found, etc. Being able to unload/reload an extension module on the fly is really cool for debugging, too. It sort of looks like Perl supports a lot of this to some degree, but it's not 100% clear and it certainly doesn't seem to make it anywhere near as easy as Python does.
I guess the long and the short of it is that I don't see any reason whatsoever for anyone ever to switch from Python to Perl. You probably don't see any reason whatsoever to switch from Perl to Python; fair 'nuff. The real question is whether a case has been made for recommending either one over the other to someone who currently knows neither. I'd say the balance still tips toward Python.
Pros for Python:
Better/fuller OOP, including meta-programming.
Real exception handling, that people actually use.
"Real language" syntax (e.g. real argument lists, no "my", no funky variable prefixes); more familiar to CS types.
Cleaner separation between language and libraries.
Better C-extension handling.
JPython.
Pros for Perl:
No enforced indentation.
More familiar to *sh/awk programmers.
Ability to add syntax on the fly (a mixed blessing IMO).
More libraries available (though Python is far from deficient).
??? (I'm sure there are others, but I'm not the Perl advocate).
About even:
Scope issues.
Functional programming facilities.
Performance?
Portability?
The scorecard's far from complete, but the points in Python's favor seem both stronger and more numerous. What else can you suggest to even things up?
Oh yeah, I forgot to mention. I looked at some of the stuff on extending Perl using C. It doesn't look anywhere near as clean as doing the same thing in Python, though that may be in part due to the fact that I could only find a reference and not a tutorial. I think that's one area of Python that you should really check out. Adding extension modules in Python is so easy it's almost a bad thing, because you can be tempted into doing things as extension modules that really should be done as plain old Python modules.
The example I gave with exceptions is actually very clean, with no C-style hackery required...[example elided for brevity; see the parent article]
I'm sorry, but...yuk! I mean, really. It doesn't handle finally, or rethrows, or catching some exceptions but not others (except by using an explicit conditional in the catch). The implementation is probably pretty opaque not only to a beginner, but to even a medium-level but casual Perl programmer. The comment alludes to creepy visibility issues regarding $_. That's clean? I'd like to keep this on a positive note, I wish I could say "yeah, that's cool, it's a nifty hack", but I just can't. There's no way I could consider that an adequate substitute for exceptions in Python or most other languages.
The lack of proper argument lists is another thing that bugs me. It probably shouldn't. It's really not so bad if the first line of every function parses the argument list into local variables. Having thought some about how I'd design and implement The Perfect Language, I'm well aware of how much easier that is on the language implementor. Nonetheless, it's something I find hard to stomach. It's one of those "making it easier to write sloppy code than to write neat code" things; people are more likely to use real argument lists than "my" and $_ (ick), and the code will be better for it.
Perl doesn't have any arbitrary quoting, scoping, and argument-passing rules. It's quite clear on all of these points, and the quoting rules especially are very handy. And from what I've heard here, Python has some interesting scoping rules that aren't lexical or dynamic scope, while Perl supports either one, and more.
Even though neither is fully compiled or fully interpreted, Perl has more of a compiled-language flavor and Python has more of an interpreted-language flavor. In that context, each language's scope handling makes more sense. Personally I don't much care for "my" and "local" but at least it's better than Tcl's "upvar" (double-plus ugh). As for Python's scope handling, you have to be very careful. The very same things that make it seem a little odd when you allow yourself to forget the rules - lots of Python programmers have bookmarks in Lutz's book where there's a table of what the local and global namespaces will be in various situations - are also critical to meta-programming and a whole grab bag of other nifty tricks. It would be sad to sacrifice those things to make a few CS gradual students happy. Once you grok how scopes and namespaces work, it all makes quite a bit of sense - in some ways more sense than either pure-lexical or pure-dynamic scope.
Perl doesn't have a built-in exception system, but it has prototypes, which basically lets you add syntax to the language; there's a simple example (in Programming In Perl, I think) that adds a try..catch construct to the language.:)
If you have non-local goto (setjmp/longjmp) you can get something pretty close to real exceptions. I've seen many such attempts or approximations, in many languages. They're never quite the same as having exceptions supported directly, but they're usually good enough.
Perl does have features for integrating with other languages
Do you by any chance have a pointer to an API document that describes this?
Python might follow the 'principle of least surprise' for someone unfamiliar with programming languages, but Perl looks like a few popular (also ugly?) languages, and might be better for migrating old Unix hackers as needed.:)
Au contraire. I'm an old UNIX hacker, and if you think the crap embedded into *sh has anything to do with real programming languages you need your head examined. Bourne, Korn, et al have made many people's lives miserable with their arbitrary and silly quoting, scoping, and argument-passing rules. To anyone familiar with real programming languages, particularly those in the Algol/Pascal/C family, I think Python will seem more familiar than Perl, not less.
I didn't like having to use $, @, and % all the time, either
I've always found it amazing that Perl users will criticize Python for abusing indentation, then turn around and blithely accept Perl's abuse of variable names.
There are lots of default arguments to functions in Perl
To built-in functions, you mean. The Perl function-declaration syntax doesn't seem to have a place for default arguments, or in fact for real argument lists at all. In this it is much like *sh and very unlike a real programming language.
The only time I had to do something really ugly in a Python program was when I had to deal with some issues about default parameters being evaluated at function-definition rather than function-call time.
BTW, I should probably point out that this was more my fault than Python's. The default parameters in this particular situation should have been instance variables on a single-method object, and I knew that. I was just being lazy. This actually highlights what I think is one of Python's most endearing features: Python makes it easier to do things the right way than the wrong way. It's eerie sometimes when you realize it, as though GvR is psychic or something, but it's a very real phenomenon noted by many Python programmers. Keep in mind that I still could have kept doing things the ugly and painful way if I had wanted...but why?
I know it will strike many as hyperbole, but I really think that Python makes it possible for below-average programmers to write above-average code. I've seen it happen too often not to believe in this effect, and the best thing is that those skills honed in Python can be transferred to other languages. A Certain Other Language, by contrast, rewards sloppy habits and punishes clean ones, all too often resulting in above-average programmers writing below-average code.
Riddle me this: does Python have lexical scope, closures, useful built-in data-types, familiar syntax, functions, variables, looping constructs, or objects?
Before I get started, I invite a Perl advocate to answer the same set of questions for Perl so we can all compare. Any volunteers?
OK, here goes:
Lexical scope: kinda, sorta. Truth be told, Python scope is neither truly lexical nor truly dynamic. It is, however, well documented and easy to understand; see this post and the pointers therein for a better explanation. Short form: the language generally tends more toward lexical than dynamic, and is certainly evolving even further in that direction
Closures: not as such, but there's a very standard trick involving lambda default arguments that gives the same effect without requiring an extension to the language.
Useful built-in data types: damn right! Lists, dictionaries, objects, you name it.
Functions, variables, looping constructs: yes, yes, and yes. Also a nice exception system.
Objects: absolutely. A well-designed set of interactions between objects, dictionaries and namespaces is at the very core of Python. OO is not just something bolted on to Python after the fact; it has been there since day one, and it's almost impossible to write any non-trivial program without using objects.
Before we go on, I'd also like to touch on two things about Python that you didn't even ask about but that help make it even cooler.
Python maintains a good separation between language and environment. A lot of stuff that clutters up A Certain Other Language is in libraries with Python, often using much nicer object-based interfaces. This makes things much more portable, extensible, etc.
The ability to extend Python with modules written in C, using a well-documented API, should not be underestimated. This aspect of the language is, again, not an afterthought. As with Tcl, extensibility and embeddability (something with which I personally have less experience) were design goals from Day One. Time-machine references aside, this is what happens when you design stuff well to start with. Extensions have been written that I'm sure Guido van Rossum could never have imagined when he was designing Python, but because he followed good design processes they were easy to create.
Next question:
How does it help you manage a program better than, say, Perl?
I have to admit that it's hard for me to put some of this into words, because it has to do with general philosophy rather than specific features. A lot of what's in Python is there specifically to improve clarity, reduce possibility for error, etc. Sometimes Guido has arguably gone too far, such as with the indentation thing or long-standing (but finally overcome) opposition to augmented assignment, but it's hard to fault him for that. He knows what he's doing, and so do the other decision-makers. Despite quibbles from Perl or Scheme folks who are surprised by anything not Perl or Scheme, Python generally follows the "principle of least surprise" rather well.
The fact that objects are central and not just peripheral to Python is one example of something that has far-reaching but hard to define consequences. The fact that it has had mature module and exception features from the start is similarly helpful, especially in larger programs. Object-persistence stuff like pickle and shelve (yeah, weird names), rudimentary as they may seem, have also proven invaluable to many people. One might say that Perl has caught up in many of these areas, though I personally think it still has a way to go, but catching up is still not the same as doing it right the first time. Legacy code written "before we had X" is a pain.
What does it *not* let you do that you might conceivably want to do, and how ugly are the methods used to get around this?
Damn little. A lot of people have done a lot of very fancy things with Python. There's very little you can't do even if you only use the language in the most straightforward way. If that doesn't work, you can step into meta-object programming and namespace manipulation, which are a little bit tricky but still not "black magic". If that doesn't work you can write an extension module, which again is about as painless as one could reasonably expect it to be. Overall, whatever level you have to go to, it's about as non-ugly as one could hope for. The only time I had to do something really ugly in a Python program was when I had to deal with some issues about default parameters being evaluated at function-definition rather than function-call time.
In a post of this length, I would of course be remiss if I didn't mention some of the things that I think are wrong with Python. Bear in mind, though, that I'm loth to gainsay the language developers' decisions even when I might have done it differently myself. They have done a better job than I would have.
I live with the indentation thing, but I'm among those who would be at least half an iota happier if Python used braces.
The fact that certain built-in types are not true objects is suboptimal (this is improving).
Not being able to subclass extension-module objects sucks. You can get around it by creating a Python class to wrap the C class, but that is kind of kludgy. In general, some of the internal relationships between objects, classes, and namespaces could be improved.
Some nitpicky details about lists/tuples/slices have never felt right to me. This is definitely a matter of personal taste; most people would probably hate the way I'd do it.
Some of the newer package stuff seems a little baroque to me, but it's still evolving, so who knows?
just reply to this one and tell me what features make Python a better language
Being more specific about how Python is superior is exactly equivalent to being more specific about how Perl is inferior, and yet that seems to be what you're whining about. Thanks for the attempted double bind, but I'll pass. Instead, what I'll do, and what I've already done, is try to steer you toward the information that will let you make your own informed choice about which language is better. Here (again) is a link to the Python tutorial. It really does a better job of "hitting the highlights" than I can here. Go through as much or as little of it as you feel you need. For your convenience, though, I'd recommend some of the following sections as particularly relevant or potentially indicative of differences between Python and Perl:
Sections 4.6 and 4.7 (function definition, lambda).
Sections 5.1.3 (functional programming) and 5.1.4 (list comprehensions).
Section 9 (classes and scope).
There's also a separate document about extending and embedding Python, which I think is one of the best things about the language.
I hope you enjoy and learn from these sources of information. If you need more, somebody else has already pointed out that comp.lang.python is very newbie-friendly and full of helpful folks. It's true.
Ok...I promised myself I'd stay out of the Perl/Python flamewars...but...
Welcome to the mudpit. We're all having a good wallow here.;-)
So, your argument is that Perl is hard to program in unless you know the language...?
I guess we need to stop and think about what "knowing the language" means. Is it a Good Thing if "knowing C++" means knowing all sorts of details like constructor/destructor ordering and implicit type conversions, for example? What ever happened to the "principle of least surprise"? IMO, the ideal language would have the characteristic that when you look at a piece of code you either know from a set of very simple rules what it does, or you know immediately that you don't know and you need to find out. A language in which you can often look at a piece of code, think you know what it's doing, and be utterly wrong, is therefore less than ideal. Worse is when even running the code on nine out of ten test cases doesn't reveal that it's working any differently than you thought, but the tenth case takes down your whole application five months after you or anyone else last looked at the code.
If something looks like a function call taking arguments x and y, it should act like a function that takes arguments x and y, even if it is in fact a built-in language feature and not a true function. This precludes acting like a function that takes arguments x, y, and this or $_.
No form of flow control (if - elif - elif - else, not endIF
Even in languages that have it, "endif" doesn't do anything. It's just a marker, to show where a block ends. C doesn't have endif either; it has braces. Either would be redundant in Python, because the end of the block is already known from the indentation (yeah, lots of people can't get over that, but we had that flamewar yesterday).
No GOTO
That's a good thing. Read Edsger Dijkstra's paper on "Goto Considered Harmful" from thirty years ago for an explanation. Python has a rich enough set of control structures - most notably exceptions - that make goto unnecessary.
you have to call (import) you
other.py files
Another good thing. It helps prevent the experience, familiar to C and C++ programmers, of scrabbling around trying to find out where something was defined and which definition is operative. Like many experienced Python programmers, I don't even use "from foo import *". That forces me to use "foo.func(x)" later, which is a little more verbose but makes it blindingly obvious to everyone which definition of "func" I'm using.
These all make Python quite difficult for the man in the street to use.
Like Perl is easy for the man in the street to understand? Or Scheme? Or any possible programming language? Be careful not to use the "man in the street who happened to learn Perl/VB first" too much in your examples.;-)
Of course they both grew over time, you idiot. All software does. The difference is whether something ever went through an actual design phase before being "released into the wild" or whether all of its evolution has been guided by momentary expediency. It's a little bit of an oversimplification, but not much, to say that Python was designed while Perl just kind of wandered according to Larry Wall's needs at each particular instant.
The familiar is always easier to understand than the unfamiliar. That's an obvious, well known, and basically meaningless fact. What's more interesting is what happens when that effect is factored out, i.e. when someone is presented with two things that are equally familiar or unfamiliar. In such "apples to apples" comparisons, languages well-grounded in studies of programmer productivity (e.g. Python) will always win out over languages that just kinda grew over time (e.g. Perl).
If you would dispute that characterization of the two language's heritage and origins, just ask Guido and Larry, or read the histories that are available online.
You sit someone familiar with neither Perl or Python down in front of two moderately complicated computer programs, and see which one they figure out first.
Is that a fair test? No. Is that a test that goes on every day? Yes.
I disagree. I think it's a very fair test. Unless you want to argue that there's absolutely no correlation between readability of code to one familiar with a language and one unfamiliar with it - be my guest - readable code is pretty much readable code. Sitting a language-novice in front of typical pieces of code written in the two languages may not be a perfect test, but it's not a totally useless one either.
One particularly interesting form of unreadable code is code which is easily mistaken at first glance for other code which does something either subtly or drastically different. This is a particular kind of unreadability for which Perl is justly notorious, and which Python generally avoids (though it falls down on the job sometimes too). You're right that a lot of what goes on in language wars is just noise, but some aspects of a language's syntax and semantics do have quantifiable effects on the maintenance cost of programs written in that language.
pb:
Also, judging from the Python code you have on your website, well, it looks a lot like perl code, without some braces and semicolons
I only found one script on the site, and I think its similarity to Perl code is more related to the problem domain - web page creation - than with the languages. If you want a better example of doing things reasonably well in Python that would get incredibly ugly in Perl, look at the Traveling Salesman Playground on my web site. Alternatively, you could just pick some code at random from CPAN and Parnassus. Only a blind man or a zealot would fail to see that a random Python program can be grokked more readily than a random Perl program, regardless of experience level.
pb:
It sounds like you like Python, but it doesn't sound like you've *really* used all three languages.
That's a pretty darned rude assumption, especially since Sanity had explicitly stated that "You may not have used all three languages, but I have." in #61 to which you were replying. I don't think you have any right to gainsay him on that.
pb:
you seem to appreciate syntax over language features. If this is the case, then try out BASIC, and you will see my point.
That's just rudeness for its own sake. I see nothing in Sanity's comments to justify your statement, or your gratuitous mention of BASIC to demean your opponent.
I picked Python over Perl years ago. However, if I were to make the choice today based on the behavior of each's proponents in this discussion I'd make it the same way. Someone else said something about Perl's lower "barriers to entry" resulting in a high percentage of its advocates being inexperienced and immature programmers. I think that's exactly right, except that the inexperience applies to advocacy as well as coding styles.
I assume you mean lambdas. What do you think is broken about them, specifically?
Python DOES NOT HAVE REAL SCOPE
Ahhh, now I see your problem. The above statement is untrue. Python does have real scope. In fact, Python's scope rules are among the simplest and most understandable I've seen in a coupla dozen languages. Here's the thing, though: it's lexical scope. If you're one of those people who prefers dynamic then of course Python's scope will appear broken, and lambda expressions will be one of the most affected areas. It seems that the transition from one type of scope to the other, in either direction, takes most people a while.
Are you by any chance at MIT? I only ask because it seems like a high percentage of dynamic-scope bigots picked up their disease there. If so, you might be interested to know that you can do some kinds of continuations in Python, and there are some side projects directed at making support for your favorite programming style more complete so that old (or dumb) dogs won't have to learn new tricks.
local/global distinctions are implicit by merit of RHS vs LHS mysticism
You're not making it at all clear what you're talking about, but I'll try to guess anyway. For the onlookers, if the first reference to a variable name in a Python function is an assignment, that assignment will go into the local variable scope even if a same-named variable already exists in the enclosing module scope...unless the variable is predeclared in the function using the "global" keyword. Even worse, the idea of "first reference" is dynamic even though Python scope is generally lexical. I guess that's what the AC means by "schizo".
What's my answer to that? Well, I don't have one. I'm a Python advocate, but that doesn't mean I'm blind to its failures, and the "global" issue is one of Python's ugliest warts. Even experienced Python programmers get bitten by this occasionally. Even the relative rarity with which it occurs is no excuse, because (as I've pointed out in previous posts) it's generally good for faulty code to reveal itself as such ASAP instead of lurking until the specific conditions for failure are created.
That said, I will say that even the best programmers occasionally have bad days. Python has several warts. UNIX has some pretty bad ones too. C'est la vie. At least Python and UNIX only have warts, instead of being mostly warts on top of warts all the way to the core like Perl or Windows.
This is the kind of crap that Python shovels down your through, and which makes Perl seem direct and obvious in comparison
Anyone who can criticize Python's scoping and handling of lambda expressions, then turn around and fail to address Perl's own much greater failings in those very same areas, is the rankest sort of hypocrite.
That's the most ridiculous false paraphrase of what I've been saying that I can imagine. I don't know why I'm even dignifying it with a response, except to ensure that my silence is not misinterpreted as acceptance.
Ruby uses simple naming conventions to denote the scope of variables
Ick. IMO, such a "naming convention" is an even worse crime than Python's "indentation convention", since the former is semantic while the latter is merely syntactic. This was a dumb idea in FORTRAN, but at least they had the excuse of not having had the opportunity to learn from experience. In Perl or Ruby it's even worse than a dumb idea.
Bunk. Quite a few real-world applications have been based on Python, from imaging applications to persistent object-based web scripting environments to God knows what else. Check out some of the stuff in the Vaults of Parnassus (forgot the URL, look on www.python.org) before you claim it's "just a toy".
Real world scripting requires a fast, loose, flexible approach, which is totally absent in Python.
Python is just as "fast and flexible" as any other language in the ways that matter. Looseness, though, is not a virtue. Languages in which an exotic and rarely-useful construct is a mistyped character or two away from a common idiom make it way too easy for bugs to creep into code. Languages should allow you to do tricky stuff, but the tricky stuff should be very distinct and obviously different than the straightforward stuff. Python is based on this understanding. You can do some pretty funky things with object metaprogramming and faked scopes, for example, but when you do them it's obvious to other programmers that something out of the usual is going on.
Languages have superficial features and deep features. Guess who gets all hung up on the superficial stuff? That's right...beginners. First-term Pascal programmers used to bitch and whine about "begin" and "end" all the time. As soon as they found something more important to worry about they just got over it and you should too. Python's indentation rule is not much beloved even among dedicated Python advocates (including myself) but we put up with it because we know it's just fluff and at least Python got the deep stuff right. By contrast, Perl's ugliness ranges all the way from the cosmetic (variable-reference syntax, quoting rules) to the deepest of the deep (bizarre scope rules, lack of an object or exception model worth the name).
Slashdot Mirror
4GB is not that extraordinary any more. Sure, you're not likely to see 4GB in too many people's desktop PCs, but is that the operative definition of "ordinary"? I'd say that any computer that the manufacturer can ship to you off an assembly line because they make thousands like it is ordinary, and that covers a lot of machines with a lot more than 4GB.
I'm not sure even that is safe, for some combination of the following reasons:
There's no shortage of companies that would be willing to steal an idea from an abstract, block the patent with bogus claims of prior art, and then outmuscle the inventor in the marketplace. The endless counterclaims would make the patent process even more cumbersome, making it even more difficult for the patent office to keep up. The net result would be that patents would fail to protect inventors - in fact it would make them even more vulnerable to various forms of predation - and nobody would bother filing for patents at all. Everything would end up being protected as trade secrets instead, meaning that they'd never be disclosed, and I don't think that would be a good thing.
I don't think abstracts should be made completely public. However, I think patents are important enough to justify a different solution: the patent office should, like a court, be able to subpoena experts within a technology area to comment on the potential validity of a patent. Obviously, some safeguards would have to exist:
If examining patents were considered a civic duty for experts in a field, just like jury duty is for all citizens, I think that would be a big improvement. It would have the same effect as drastically increasing the number of patent officers, but without the cost. Obviously there would still be a lot of legal wrangling going on, but I believe it would be a lot less than currently.
I know it's not fashionable to look at things from the enemy's perspective, but has it ever occurred to you folks that the reason there are so few good managers is that managing people is hard? Let's try looking at this from a couple of different perspectives.
Where are you going to find good people to do all this? Where do you find someone who can keep both the technical details and the corporate goals in mind, who's reasonably intelligent and has a decent set of ethics and yet doesn't mind sitting in rooms full of Machiavelli wannabes and Just Plain Dumb people, and who's willing - all to often - to do all that for less money than some of the people "under" them get paid? There really is a shortage of quality people in the industry, but it's not a shortage of hands-on techies; it's a shortage of managers who aren't scum or morons or both.
I whine about my job as much as anyone, but I honestly don't think there's anything I could find myself doing in my prized role as an individual contributor that would be worse than being a manager. It is necessary to have someone else to do all that stuff, but I'm damn glad it's not me. Next time you feel like a few minutes of manager-bashing, spare yourself at least one second to give thanks that you have a better job than they do.
Firstly, "term of art" is an incredibly pretentious phrase, beloved by lawyers (and wannabes) but generally shunned by true technical people.
Secondly, hot potato is indeed a "term of art"...one which has had a clear and well-understood meaning for twenty years and which does not apply to the routing we're talking about. Real network professionals know that; it's only the tyros and dilettantes who slept through their basic networking class (or never took one) who would abuse such a time-honored and universal term. Read any basic networking text; they're all very clear on what "hot potato" routing is and is not.
I know I'm coming in rather late, but I just have to object to the abuse of the term "hot potato" to describe the common backbone routing policies. True hot-potato routing is totally naive with regard to network distances from a destination; it just forwards to some node (or in this case network) other than the one the packet came in on - usually the one with the shortest queue length. This will often end up routing a packet away from its destination. If backbone providers truly did things this way, packets would wander around quite aimlessly, often expiring before they reached their destinations. Every backbone provider would get saturated with such "lost" packets, creating more traffic for all of them and leading to a complete collapse of the Internet.
Obviously, that is not what's really happening. I'd call the technique in common use "warm potato" instead. Providers do want to dump the packet on someone else quickly, but subject to the limitation that they dump it at least a tiny bit nearer the destination than when they received it. This is still strongly suboptimal[1] and slightly antisocial, but it's nothing like true hot potato.
[1] It actually approximates hierarchical routing rather closely. The efficiency loss (in terms of hops) of hierarchical routing has been thoroughly studied and quantified by Tanenbaum and many others, but it does have the (sometimes critical) advantage of keeping routing-table sizes under control. As others have pointed out, one of the weaknesses of InterNAP's approach is the potentially very large number of routes involved. None of this is new. It has all been well understood in the networking community for decades.
Then I have to wonder how they determine the prevailing wage. I work with a whole bunch of H1-B folks, mostly from China and the Indian subcontinent, and they are consistently paid 75% or less of what their skills are worth. One trick that seems to be involved in skirting the INS rules is hiring people with senior-engineer skills into junior-engineer jobs and paying them junior-engineer salaries.
Security comes immediately to mind as a possible answer. I don't just mean military-style security either, though that's certainly an important case, but also defense-against-crackers kind of security. I don't think the "more eyes and brains improving the code" theory would apply to the government. If there were an exploitable bug in some piece of IRS code, for example, does anyone really think there'd be lots of people offering them a fix? Hell no, everyone would be exploiting it. When there are practically no white hats and millions of would-be black hats, "security through obscurity" might not be a totally bad policy.
Well, exceptions encompass a lot more than true errors - resource unavailability, deliberately aborted waits, etc. etc. In a large program, where the function that recognizes a condition may be several calls removed from the topmost function that needs to know about it, propagating status codes all the time gets real old, real fast. Exceptions provide a way to streamline the whole process quite nicely.
IIRC, Java's exception model was fairly reasonable but the common usage of exceptions was somewhat less so. Like anything, exceptions can be abused or used wrongly, so you need to be careful to distinguish the usage from the model.
Well, the simplest scope of all is no local variables at all. Everything's global. You could even do away with function arguments as such; if you want to pass parameters to foo() you just assign to foo_x, foo_y, etc. before you call it and the return value is in foo_result. Or you could use a register-like model.
Obviously, simplest isn't necessarily best here, even though in general simplicity is a virtue. The question is which model provides the best balance between expressiveness, intuition, flexibility, etc. Personally, I think it's safer to have things be local by default to avoid unintended name clashes than to have them be global by default. Those kind of bugs tend to be really nasty to track down, and having too much stuff global makes them all but inevitable.
Historically yes, but that's one of the biggest changes for Python 2.0. Extension writers still have to manipulate refcounts, but Python itself can apparently figure out that if all of the references to objects in a set are satisfied by other objects also in that set then the whole set must be disconnected from anything else and can be GC'ed. That's about as good as you're going to get in such a thoroughly extensible language, I think.
Does Perl have modules specifically geared toward language processing? I'm quite sure Python does.
You bet. Some of the very biggest web players use Python rather than Perl for this kind of stuff, and I've yet to hear of a serious Perl equivalent to Zope. Check out the Vaults of Parnassus sometime; even compared to CPAN, the variety of modules represented there is pretty impressive.
I agree that it's kind of cool that you can do that in Perl. OTOH, I have mixed feelings about being able to add arbitrary syntax like this. I've seen operator overloading abused far more often than I've seen it used at all reasonably, causing no end of headaches for people who have to work with code written using it, and this capability seems like operator overloading on steroids. I know Schemers love the feel of creating a language specific to each problem, but my experience out here in the Real World tells me that's an express ticket to Trouble.
I'm also still curious about whether this facility can be used to create a real exception mechanism - one that has finally and rethrow, that doesn't succumb to creepy scope problems, etc. I'm a little skeptical, actually, and decent exception handling is something I believe should be part of any modern programming language.
That's putting it politely. I've been critical of Perl, but that's nothing compared to how I feel about Tcl. Tk is great, I use it a lot via Python's native Tkinter interface, so I get to read a fair amount of documentation written for Tcl users, and none of it has made me think better of the language. Perl may be a mistake, but Tcl is a true crime against reason.
Being able to compile Perl into C is definitely cool. Python's equivalent is "freeze" which does some magic to collect all of the modules you need plus a runtime and bundle them into an executable. I've never tried it, so I don't know how well it works; from time to time I've wondered how it handles things like eval and exec, and it seems like certain forms of dynamic behavior would be almost impossible to support.
That said, it's just not the same as being able to create a true dynamically loadable extension module which can define its own types etc. and be loaded into a running language-interpreter instance. For example, it can be very handy to choose at runtime which module you load to perform a function, or fall back from one to another if the first isn't found, etc. Being able to unload/reload an extension module on the fly is really cool for debugging, too. It sort of looks like Perl supports a lot of this to some degree, but it's not 100% clear and it certainly doesn't seem to make it anywhere near as easy as Python does.
I guess the long and the short of it is that I don't see any reason whatsoever for anyone ever to switch from Python to Perl. You probably don't see any reason whatsoever to switch from Perl to Python; fair 'nuff. The real question is whether a case has been made for recommending either one over the other to someone who currently knows neither. I'd say the balance still tips toward Python.
Pros for Python:
Pros for Perl:
About even:
The scorecard's far from complete, but the points in Python's favor seem both stronger and more numerous. What else can you suggest to even things up?
Oh yeah, I forgot to mention. I looked at some of the stuff on extending Perl using C. It doesn't look anywhere near as clean as doing the same thing in Python, though that may be in part due to the fact that I could only find a reference and not a tutorial. I think that's one area of Python that you should really check out. Adding extension modules in Python is so easy it's almost a bad thing, because you can be tempted into doing things as extension modules that really should be done as plain old Python modules.
I'm sorry, but...yuk! I mean, really. It doesn't handle finally, or rethrows, or catching some exceptions but not others (except by using an explicit conditional in the catch). The implementation is probably pretty opaque not only to a beginner, but to even a medium-level but casual Perl programmer. The comment alludes to creepy visibility issues regarding $_. That's clean? I'd like to keep this on a positive note, I wish I could say "yeah, that's cool, it's a nifty hack", but I just can't. There's no way I could consider that an adequate substitute for exceptions in Python or most other languages.
The lack of proper argument lists is another thing that bugs me. It probably shouldn't. It's really not so bad if the first line of every function parses the argument list into local variables. Having thought some about how I'd design and implement The Perfect Language, I'm well aware of how much easier that is on the language implementor. Nonetheless, it's something I find hard to stomach. It's one of those "making it easier to write sloppy code than to write neat code" things; people are more likely to use real argument lists than "my" and $_ (ick), and the code will be better for it.
Even though neither is fully compiled or fully interpreted, Perl has more of a compiled-language flavor and Python has more of an interpreted-language flavor. In that context, each language's scope handling makes more sense. Personally I don't much care for "my" and "local" but at least it's better than Tcl's "upvar" (double-plus ugh). As for Python's scope handling, you have to be very careful. The very same things that make it seem a little odd when you allow yourself to forget the rules - lots of Python programmers have bookmarks in Lutz's book where there's a table of what the local and global namespaces will be in various situations - are also critical to meta-programming and a whole grab bag of other nifty tricks. It would be sad to sacrifice those things to make a few CS gradual students happy. Once you grok how scopes and namespaces work, it all makes quite a bit of sense - in some ways more sense than either pure-lexical or pure-dynamic scope.
If you have non-local goto (setjmp/longjmp) you can get something pretty close to real exceptions. I've seen many such attempts or approximations, in many languages. They're never quite the same as having exceptions supported directly, but they're usually good enough.
Do you by any chance have a pointer to an API document that describes this?
Au contraire. I'm an old UNIX hacker, and if you think the crap embedded into *sh has anything to do with real programming languages you need your head examined. Bourne, Korn, et al have made many people's lives miserable with their arbitrary and silly quoting, scoping, and argument-passing rules. To anyone familiar with real programming languages, particularly those in the Algol/Pascal/C family, I think Python will seem more familiar than Perl, not less.
I've always found it amazing that Perl users will criticize Python for abusing indentation, then turn around and blithely accept Perl's abuse of variable names.
To built-in functions, you mean. The Perl function-declaration syntax doesn't seem to have a place for default arguments, or in fact for real argument lists at all. In this it is much like *sh and very unlike a real programming language.
BTW, I should probably point out that this was more my fault than Python's. The default parameters in this particular situation should have been instance variables on a single-method object, and I knew that. I was just being lazy. This actually highlights what I think is one of Python's most endearing features: Python makes it easier to do things the right way than the wrong way. It's eerie sometimes when you realize it, as though GvR is psychic or something, but it's a very real phenomenon noted by many Python programmers. Keep in mind that I still could have kept doing things the ugly and painful way if I had wanted...but why?
I know it will strike many as hyperbole, but I really think that Python makes it possible for below-average programmers to write above-average code. I've seen it happen too often not to believe in this effect, and the best thing is that those skills honed in Python can be transferred to other languages. A Certain Other Language, by contrast, rewards sloppy habits and punishes clean ones, all too often resulting in above-average programmers writing below-average code.
Before I get started, I invite a Perl advocate to answer the same set of questions for Perl so we can all compare. Any volunteers?
OK, here goes:
Before we go on, I'd also like to touch on two things about Python that you didn't even ask about but that help make it even cooler.
Next question:
I have to admit that it's hard for me to put some of this into words, because it has to do with general philosophy rather than specific features. A lot of what's in Python is there specifically to improve clarity, reduce possibility for error, etc. Sometimes Guido has arguably gone too far, such as with the indentation thing or long-standing (but finally overcome) opposition to augmented assignment, but it's hard to fault him for that. He knows what he's doing, and so do the other decision-makers. Despite quibbles from Perl or Scheme folks who are surprised by anything not Perl or Scheme, Python generally follows the "principle of least surprise" rather well.
The fact that objects are central and not just peripheral to Python is one example of something that has far-reaching but hard to define consequences. The fact that it has had mature module and exception features from the start is similarly helpful, especially in larger programs. Object-persistence stuff like pickle and shelve (yeah, weird names), rudimentary as they may seem, have also proven invaluable to many people. One might say that Perl has caught up in many of these areas, though I personally think it still has a way to go, but catching up is still not the same as doing it right the first time. Legacy code written "before we had X" is a pain.
Damn little. A lot of people have done a lot of very fancy things with Python. There's very little you can't do even if you only use the language in the most straightforward way. If that doesn't work, you can step into meta-object programming and namespace manipulation, which are a little bit tricky but still not "black magic". If that doesn't work you can write an extension module, which again is about as painless as one could reasonably expect it to be. Overall, whatever level you have to go to, it's about as non-ugly as one could hope for. The only time I had to do something really ugly in a Python program was when I had to deal with some issues about default parameters being evaluated at function-definition rather than function-call time.
In a post of this length, I would of course be remiss if I didn't mention some of the things that I think are wrong with Python. Bear in mind, though, that I'm loth to gainsay the language developers' decisions even when I might have done it differently myself. They have done a better job than I would have.
Being more specific about how Python is superior is exactly equivalent to being more specific about how Perl is inferior, and yet that seems to be what you're whining about. Thanks for the attempted double bind, but I'll pass. Instead, what I'll do, and what I've already done, is try to steer you toward the information that will let you make your own informed choice about which language is better. Here (again) is a link to the Python tutorial. It really does a better job of "hitting the highlights" than I can here. Go through as much or as little of it as you feel you need. For your convenience, though, I'd recommend some of the following sections as particularly relevant or potentially indicative of differences between Python and Perl:
There's also a separate document about extending and embedding Python, which I think is one of the best things about the language.
I hope you enjoy and learn from these sources of information. If you need more, somebody else has already pointed out that comp.lang.python is very newbie-friendly and full of helpful folks. It's true.
Welcome to the mudpit. We're all having a good wallow here. ;-)
I guess we need to stop and think about what "knowing the language" means. Is it a Good Thing if "knowing C++" means knowing all sorts of details like constructor/destructor ordering and implicit type conversions, for example? What ever happened to the "principle of least surprise"? IMO, the ideal language would have the characteristic that when you look at a piece of code you either know from a set of very simple rules what it does, or you know immediately that you don't know and you need to find out. A language in which you can often look at a piece of code, think you know what it's doing, and be utterly wrong, is therefore less than ideal. Worse is when even running the code on nine out of ten test cases doesn't reveal that it's working any differently than you thought, but the tenth case takes down your whole application five months after you or anyone else last looked at the code.
If something looks like a function call taking arguments x and y, it should act like a function that takes arguments x and y, even if it is in fact a built-in language feature and not a true function. This precludes acting like a function that takes arguments x, y, and this or $_.
Even in languages that have it, "endif" doesn't do anything. It's just a marker, to show where a block ends. C doesn't have endif either; it has braces. Either would be redundant in Python, because the end of the block is already known from the indentation (yeah, lots of people can't get over that, but we had that flamewar yesterday).
That's a good thing. Read Edsger Dijkstra's paper on "Goto Considered Harmful" from thirty years ago for an explanation. Python has a rich enough set of control structures - most notably exceptions - that make goto unnecessary.
Another good thing. It helps prevent the experience, familiar to C and C++ programmers, of scrabbling around trying to find out where something was defined and which definition is operative. Like many experienced Python programmers, I don't even use "from foo import *". That forces me to use "foo.func(x)" later, which is a little more verbose but makes it blindingly obvious to everyone which definition of "func" I'm using.
Like Perl is easy for the man in the street to understand? Or Scheme? Or any possible programming language? Be careful not to use the "man in the street who happened to learn Perl/VB first" too much in your examples. ;-)
Of course they both grew over time, you idiot. All software does. The difference is whether something ever went through an actual design phase before being "released into the wild" or whether all of its evolution has been guided by momentary expediency. It's a little bit of an oversimplification, but not much, to say that Python was designed while Perl just kind of wandered according to Larry Wall's needs at each particular instant.
No, I did not. I said nothing of the sort. Please learn to read before you post.
The familiar is always easier to understand than the unfamiliar. That's an obvious, well known, and basically meaningless fact. What's more interesting is what happens when that effect is factored out, i.e. when someone is presented with two things that are equally familiar or unfamiliar. In such "apples to apples" comparisons, languages well-grounded in studies of programmer productivity (e.g. Python) will always win out over languages that just kinda grew over time (e.g. Perl).
If you would dispute that characterization of the two language's heritage and origins, just ask Guido and Larry, or read the histories that are available online.
Sanity suggests, in #61:
pb replies, in #107:
I disagree. I think it's a very fair test. Unless you want to argue that there's absolutely no correlation between readability of code to one familiar with a language and one unfamiliar with it - be my guest - readable code is pretty much readable code. Sitting a language-novice in front of typical pieces of code written in the two languages may not be a perfect test, but it's not a totally useless one either.
One particularly interesting form of unreadable code is code which is easily mistaken at first glance for other code which does something either subtly or drastically different. This is a particular kind of unreadability for which Perl is justly notorious, and which Python generally avoids (though it falls down on the job sometimes too). You're right that a lot of what goes on in language wars is just noise, but some aspects of a language's syntax and semantics do have quantifiable effects on the maintenance cost of programs written in that language.
I only found one script on the site, and I think its similarity to Perl code is more related to the problem domain - web page creation - than with the languages. If you want a better example of doing things reasonably well in Python that would get incredibly ugly in Perl, look at the Traveling Salesman Playground on my web site. Alternatively, you could just pick some code at random from CPAN and Parnassus. Only a blind man or a zealot would fail to see that a random Python program can be grokked more readily than a random Perl program, regardless of experience level.
That's a pretty darned rude assumption, especially since Sanity had explicitly stated that "You may not have used all three languages, but I have." in #61 to which you were replying. I don't think you have any right to gainsay him on that.
That's just rudeness for its own sake. I see nothing in Sanity's comments to justify your statement, or your gratuitous mention of BASIC to demean your opponent.
I picked Python over Perl years ago. However, if I were to make the choice today based on the behavior of each's proponents in this discussion I'd make it the same way. Someone else said something about Perl's lower "barriers to entry" resulting in a high percentage of its advocates being inexperienced and immature programmers. I think that's exactly right, except that the inexperience applies to advocacy as well as coding styles.
I assume you mean lambdas. What do you think is broken about them, specifically?
Ahhh, now I see your problem. The above statement is untrue. Python does have real scope. In fact, Python's scope rules are among the simplest and most understandable I've seen in a coupla dozen languages. Here's the thing, though: it's lexical scope. If you're one of those people who prefers dynamic then of course Python's scope will appear broken, and lambda expressions will be one of the most affected areas. It seems that the transition from one type of scope to the other, in either direction, takes most people a while.
Are you by any chance at MIT? I only ask because it seems like a high percentage of dynamic-scope bigots picked up their disease there. If so, you might be interested to know that you can do some kinds of continuations in Python, and there are some side projects directed at making support for your favorite programming style more complete so that old (or dumb) dogs won't have to learn new tricks.
You're not making it at all clear what you're talking about, but I'll try to guess anyway. For the onlookers, if the first reference to a variable name in a Python function is an assignment, that assignment will go into the local variable scope even if a same-named variable already exists in the enclosing module scope...unless the variable is predeclared in the function using the "global" keyword. Even worse, the idea of "first reference" is dynamic even though Python scope is generally lexical. I guess that's what the AC means by "schizo".
What's my answer to that? Well, I don't have one. I'm a Python advocate, but that doesn't mean I'm blind to its failures, and the "global" issue is one of Python's ugliest warts. Even experienced Python programmers get bitten by this occasionally. Even the relative rarity with which it occurs is no excuse, because (as I've pointed out in previous posts) it's generally good for faulty code to reveal itself as such ASAP instead of lurking until the specific conditions for failure are created.
That said, I will say that even the best programmers occasionally have bad days. Python has several warts. UNIX has some pretty bad ones too. C'est la vie. At least Python and UNIX only have warts, instead of being mostly warts on top of warts all the way to the core like Perl or Windows.
Anyone who can criticize Python's scoping and handling of lambda expressions, then turn around and fail to address Perl's own much greater failings in those very same areas, is the rankest sort of hypocrite.
That's the most ridiculous false paraphrase of what I've been saying that I can imagine. I don't know why I'm even dignifying it with a response, except to ensure that my silence is not misinterpreted as acceptance.
Ick. IMO, such a "naming convention" is an even worse crime than Python's "indentation convention", since the former is semantic while the latter is merely syntactic. This was a dumb idea in FORTRAN, but at least they had the excuse of not having had the opportunity to learn from experience. In Perl or Ruby it's even worse than a dumb idea.
Bunk. Quite a few real-world applications have been based on Python, from imaging applications to persistent object-based web scripting environments to God knows what else. Check out some of the stuff in the Vaults of Parnassus (forgot the URL, look on www.python.org) before you claim it's "just a toy".
Python is just as "fast and flexible" as any other language in the ways that matter. Looseness, though, is not a virtue. Languages in which an exotic and rarely-useful construct is a mistyped character or two away from a common idiom make it way too easy for bugs to creep into code. Languages should allow you to do tricky stuff, but the tricky stuff should be very distinct and obviously different than the straightforward stuff. Python is based on this understanding. You can do some pretty funky things with object metaprogramming and faked scopes, for example, but when you do them it's obvious to other programmers that something out of the usual is going on.
Languages have superficial features and deep features. Guess who gets all hung up on the superficial stuff? That's right...beginners. First-term Pascal programmers used to bitch and whine about "begin" and "end" all the time. As soon as they found something more important to worry about they just got over it and you should too. Python's indentation rule is not much beloved even among dedicated Python advocates (including myself) but we put up with it because we know it's just fluff and at least Python got the deep stuff right. By contrast, Perl's ugliness ranges all the way from the cosmetic (variable-reference syntax, quoting rules) to the deepest of the deep (bizarre scope rules, lack of an object or exception model worth the name).