While Python is a great language, aren't "Things Guido doesn't like aren't supported at the language level" and "Python treats developers as adults" sort of at odds?
* TCO is dangerous and hard, let's not support it in the language
* ++ is ugly, let's not support it in the language
* Assignment during comparison leads to bugs, let's not support it in the language
* Python gives you more than enough rope to hang yourself, but at least hanging yourself is an option.
I wonder why supporting TCO or not has anything to do with the language. I mean isnt it up to the compiler or interpreter? If a compiler can get the same final results with TCO, then why shouldn't it? And the definition of a language should not define how a compiler works internally only what the actual effect of the language instructions should be. Compiler writers should be free to do what they want to realize the defined effect.
BTW as someone that moved from Pascal to C and C++, I can appreciate the ugliness of a lot of C shorthand syntax. It is confusing and can cause a lot of bizarre and hard to catch bugs.
As Guido says, TCO is not an optimzation, it's a language feature. Here's his reason, which I think is pretty sound:
"Second, the idea that TRE is merely an optimization, which each Python implementation can choose to implement or not, is wrong. Once tail recursion elimination exists, developers will start writing code that depends on it, and their code won't run on implementations that don't provide it: a typical Python implementation allows 1000 recursions, which is plenty for non-recursively written code and for code that recurses to traverse, for example, a typical parse tree, but not enough for a recursively written loop over a large list." - http://neopythonic.blogspot.com/2009/04/tail-recursion-elimi...
The problem with TCO is that it makes it impossible to get accurate stack traces for a function. If you optimize away the stack frame, there's no way to tell the user "this is what was running when the error occurred." You get odd behavior where a function may appear to call another function which never appears in its program text, because the intervening stack frame has been optimized away.
Stack traces are part of the Python language (besides looking pretty, the traceback module lets you inspect them), so it'd be really hard for a conforming implementation to include TCO - at least the type that actually has tail recursion run in constant space.
Java faces a similar problem with HotSpot's inlining, which is why you occasionally get <compiled code> in a Java stack trace instead a line and file number. They seem to have some hack in to avoid eliding the stack frame entirely though. This is probably what I'd do if I were designing language: push a bare-bones stack frame with just the debug info, but pop all the unused temporary working storage. Or punt on general TCO and just optimize tail-recursion - isn't that what Python was proposing to do with the @tailcall decorator anyway?
The languages I know of with TCO - gcc and Scheme - have really terrible debugging support. IMNSHO, I think that giving up debugging info for TCO is a poor tradeoff.
This sort of thing is still needed. I have a friend who's boss wont let him use anything except c, php, and perl. Any attempts to get python in there are met with resistance and vague hysteria. More posts like these from can slowly lower people's loyalty to php, and contribute to saving my friend and many like him.
Well, is Perl really a problem? Anything you can do in Python you can do in Perl just as easily; Perl actually has more abstractions available for the programmer than Python. (Grammars in regexes, real closures, coroutines, a metaobject system, etc.)
Also, last time I checked the programming language shootout, Perl 5.10 is slightly faster than Python 3.
So with that in mind, the logical "step up" from Perl would be something like Haskell. Python is pretty much Perl with different syntax, less features, and the impression that it's "cleaner" because nobody ever bothered using it for "quick and dirty" scripting.
It's a totally bogus claim. The only people that can't read their own Perl after 6 months are the people that don't really know Perl. And by "know" I just mean they read and understood most of Programming Perl/Objected Oriented Perl.
Anyone who has studied those two books can understand 99%+ of the code on the CPAN.
A lot of people have made a few halfhearted attempts at using Perl and were so put off by the scary looking sigils that they gave up. Then they blame Perl to comfort themselves. It's not them that's too lazy to look past a new kind of syntax, it's the language's fault!
"The only people that can't read their own Perl after 6 months are the people that don't really know Perl."
again replace "perl" with "APL" or "BrainFuck" (or any language with baroque syntax) and the above sentence is as (in)valid. This comes close to the "No True Scotsman" fallacy. If you really knew perl you would have no problems with reading it. Sure, but that applies to anything, no matter how convoluted.
It doesn't matter whether you think their claims are "bogus" or not, or whether they meet your standards of "really" knowing perl.
Some people find that they can read their own code in other languages easier than their own code in perl after 6 months. You might think this "bogus", that doesn't matter. For them, that is a reality they have to deal with. And many deal with it by shifting to other languages and leaving perl to its aficionados. This is as it should be. Everyone should use the language they like and not use languages they dislike (irrespective of my or your stances on what they should like or whether their claimed reasons for dislike is "bogus").
Nobody is compelling you to abandon perl. So what's your problem with them not using perl?
A language is a UI for programmers. Some people find some UIs hard. Telling them that their discomfort is "bogus" is not very useful.
I use a lot of Haskell. Many people say they find its type system, monads etc "too hard". That isn't a "bogus claim". And "If they really knew Haskell they wouldn't find it hard" (where I define the "really knew") is a useless statement.
I use Haskell, they don't. Everyone is happy.
Live and let live. There are enough languages for all of us.
Perl requires that you learn a bit before you can be comfortable reading/writing it naturally. Like Japanese Katakana characters or the Cyrillic alphabet, a little investment goes a very long way. It's not nearly as alien as it appears at first glance.
Some people think Perl is a good deal more expressive and powerful for them. A whole lot more people would if they managed to get past their initial reaction.
Python probably owes most of its success to its simplistic syntax. That is definitely a feature when you're learning. When you're going to spend years with a tool though it's often worth investing some time into new concepts.
More people should probably learn Haskell if they want to be better programmers. I think more should learn Perl too.
"Perl requires that you learn a bit before you can be comfortable reading/writing it naturally. Like Japanese Katakana characters or the Cyrillic alphabet, a little investment goes a very long way. It's not nearly as alien as it appears at first glance."
This is, no doubt, true. But if people find that for a lesser investment (in say Python or Ruby) they can get all the (or almost all the) benefits of learning perl, it is natural they prefer those languages.
If a hypothetical English speaker were to be given the choice of learning French or Japanese and if he could get his work done with either language equally well (this is where programming languages differ from spoken languages) why is it a problem that someone chooses to learn French (an English speaker could be fluent in french in year or so, Japanese would take years) instead of Japanese? A Chinese speaker might prefer to learn Japanese vs French and that's fine too.
Focussing on perl specifically, unless I am maintaining a legacy codebase or I have a situation where libraries I need exist only in perl (and not, say in Python) why should I learn perl in preference to (say) Python?
I can imagine making a case for learning Haskell in preference to Python (or vice versa!) but perl Python and Ruby are largely equivalent in practice and at least to some people Python is easier to read than perl.
"Some people think Perl is a good deal more expressive and powerful for them. A whole lot more people would if they managed to get past their initial reaction."
I agree. The counterpoint is that there are equally powerful and expressive languages where I don't need to get past the initial reaction. To some people aesthetics matter. And aesthetics is subjective.
I don't really disagree that Ruby/Perl/Python are roughly in the same league of power. I do think some people may find that Perl is a good deal more productive/expressive/powerful for them. The Moose object system, CPAN, Catalyst, DBIx::Class. Perl has some amazingly awesome stuff going for it now and I think it's a shame that many people never discover that because of the stigma surrounding Perl's syntax.
It's tiresome seeing the same old superficial argument about Perl's sigils. I'd like to see more discussion about how much more powerful and advanced Perl's Moose object system is than Python's :-)
"I'd like to see more discussion about how much more powerful and advanced Perl's Moose object system is than Python's :-)"
:-) I agree this would be a fruitful line of discussion. I know next to nothing about Perl and while (as of now) I have no intention of learning Perl, it would be great if someone (you? :-D ) were to write (or submit) such a post to HN
"Some people think Perl is a good deal more expressive and powerful for them. A whole lot more people would if they managed to get past their initial reaction."
Don't shoot me, but I also observe a similar symptom with high-priced and/or hard-to-move-away-from "corporate" (as in "boring") products. The more your company invested in said product, the more successful the enterprise will show up on internal communications, with little or no correlation however badly it failed.
People get attached to their investments, be they money, time or self-esteem. Or, in the corporate case, the jobs of the people who signed the check.
As for Python, as a long time pythonista, I can tell you there are many steps to Python-zen, exactly like what happens with Perl (I did a lot of Perl between 95 and 2002). The simplistic syntax hides a lot of power that elude the newbie. When I review my early code, I see it as childish and crude.
If someone wants to learn new languages, I always advise them to learn something as different and "alien" from his/her comfort zone as possible. Haskell is a good choice, a Lisp like Clojure or Scheme is another. And by learn I mean taking a couple years as a side hobby to do increasingly difficult problems, perhaps some you already took with your comfortable-set. It _has_ to be an enlightening experience or it loses the purpose.
No language should require people to 'advocate' it to other people, a language should stand on its own merits, the free choices made by people that have those choices available to them are all that matters.
The more vocal the advocates the more the it feels as if the choice is no longer free, that will be reflected in a resistance to observe the language objectively, some of the feeling has already been spoiled by the abrasive attitude of the proponents. Erlang suffered quite a bit from that when people started spamming HN with Erlang articles to flood other items off the new page. It could be an excellent language, but in the eyes of some it is a language associated with anti-social behaviour.
If perl were easier to learn it would lose some of its power, so maybe it is not possible to have a language that fits the bill for everybody.
These trade-offs are to be expected and are in no way a detraction, that is why we have many different programming languages in the first place. One size does not fit all.
A language should stand on its own merits, but many of the practitioners of programming are not in a position to make an informed evaluation. They are happy if they can remember the difference between an object and a class. The difference between type systems, meta object protocols, syntax extension mechanisms, and so on are going to be lost on them. They don't care, and they don't care to care. (So it's not an issue of "I haven't learned that yet", it's "I never plan to learn more".)
With this in mind, some advocacy is necessary to steer the field in a direction that is pleasing to those that know more. The advocates are just trying to help these people get more out of programming than they are going to get from $simple_language (Java, PHP).
The problem, however, is that many of the advocates are advocating because they randomly picked programming language $foo, think it's good enough, and have never tried anything else. Their advocacy is designed to recruit other followers to justify their own decisions. And that is very silly.
It is especially amusing when this type of advocate attacks the first kind of advocate. The argument is always, "well, but my code works". "Erlang works for phone switches!" "PHP can talk to a MySQL database!" Well, OK, but are you positive those things couldn't be done better in a different language? (The answer is usually, "uh, well, no...", but I digress.)
> The only people that can't read their own Perl after 6 months are the people that don't really know Perl. And by "know" I just mean they read and understood most of Programming Perl/Objected Oriented Perl.
Python taught me that there's no excuse for a language to have a learning curve like Perl's.
That's actually almost exactly the same thing as claiming that no language should be very different to everything else that has come before it.
I'm really not a Perl fan, but I really don't buy readability arguments. I'm a functional programmer, and the exact same feeble criticisms are leveled against ML and Haskell and Lisp and Scheme and whatever else. People say "ugh! It's so unreadable!", when they really mean "I can't read that having spent 2 days learning this new language, but I find it very easy to read C/PHP/Java/whatever, which I've been doing for several years".
It can take a very, very long time to actually become fluent in a programming language and paradigm to the point where you actually have a mental model of its semantics that is aligned with reality. This is why rookie programmers tend to get things wrong.
I spent almost 6 months learning Prolog. If I went and tried to write prolog now, I doubt I could remember very much at all. I've done C for more like 10 years, and I can still write C reliably despite not having touched it for 2 or 3 years.
So I don't buy it. I'm really not a Perl fan (nor a Python fan), but the idea that it's worse than python because it requires more intellectual effort to learn is bullshit, unless you're having a programming-for-people-of-limited-intelligence competition.
Scheme can indeed be learned in a day, if you understand the programming model.
And my standards for a programming language's learning curve applies to experienced programmers. It's just a happy coincidence that python offers a gentle learning curve for new programmers as well.
That is plain offensive.
The special olympics are an even greater achievement of the human body as a machine, since it must push itself with far lesser degrees of freedom.
As I saw, it was not meant to be offensive. Special olympics are for special people. They are not the best among all competitors. Most interpreted languages are not comparable to compiled languages.
Why not? NumPy offloads all the heavy lifting to LAPACK and BLAS which is some of the most optimized code on the planet. Numeric work in Python is bread-and-butter for many people.
Agreed. I have a bunch of pretty CPU intensive stuff written in C that was optimized as much as I could, given the time I had to write the code.
I re-wrote the same code using python on a lark to see how bad it would be, colour me very surprised when it actually beat the original code by a considerable margin!
Perl itself is not the problem. According to my friend, the problem comes from available tools: the ones he needs already exist for python but not for perl.
As for quick and dirty scripting in python: I do it all the time. Hell I just made a little "framework" [1] in python to do this better. I missed the while <> construct from perl for doing filters, so I made it easier to do in python. The funny thing is, many of my quick and dirty python scripts end up looking like more thought was put into them, and being more flexible, than they were ever intended to be.
Thats funny. I could say the same thing about the perl scripts I write. For that matter I could say the same thing The point is language and syntax for some of us at least has little bearing on how clear the code is. And like jrockway said perl is expressive enough that you can do far more abstraction in it. The only languages I've seen so far that can beat perl for expressive power are lisp and haskell.
As long as Python continues to not utilize multi-line lambdas. Then Perl and Ruby will continue to be a usable Lisp. But I don't think that's a bad thing. Python is Python and that's that.
No really, hence the saying "only Perl can parse Perl". Despite its dynamic typing, Python is quite amenable to tool support because of its regularity.
Sometimes taking out features is more important than having them. Python fans usually like it because every feature is exceptionally well-thought-out, not because there are a lot of features.
There's a complexity ceiling that you hit fairly quickly in PHP. Since there's no consistency in any of the libraries, you have to cram a massive amount of information into your head (or sit there with the reference manual open and look up every function call). If you're doing a quick one-week project, PHP is probably the tool of choice, but there's a large middle ground where PHP apps become way too spaghetti-ish and yet you don't want to shell out the upfront cost for a C++ or Java webapp.
Apparently Wikipedia, Facebook, Flickr, Wordpress.com, Facebook, Yahoo, Digg... haven't hit that complexity ceiling yet :) (Some of these use other languages as well, but AFAIK it's stuff like Java or Erlang for particular tasks)
PHP is far from perfect, and personally I've also moved from it to Ruby and Python, but the automatic "switch from PHP to anything" on a language that powers so much of the web is meaningless.
Wordpress has definitely hit the complexity ceiling; just look at all the security vulnerabilities and random bugs published for it. ;-)
FaceBook and I think Yahoo both make heavy use of an RPC-based, service-oriented architecture. They use PHP for the frontend but then call out to backends to do any sort of complicated processing. This is basically the only sane way to architect a large system. While I think their choice of PHP to power the front-end is regrettable (it's a major reason why I didn't apply to FaceBook), it's at least defensible.
And I'm also a PHP->Python refugee - I used PHP on a bunch of projects in college, one of which got to the 100k-to-million-user range. I would not take a PHP job unless I was desperate for cash; I hate the language that much.
AFAIK in its recent versions PHP doesn't have any unique design flaws that make them more vulnerable to attacks. In fact, being the most widely deployed web language means it probably had more security patches than most. Bugs and vulnerabilities in applications are certainly not unique to PHP..
I wouldn't take a PHP gig either. I would also prefer Ruby work to Python, since I enjoy it more. But that's my selfish interest as developer, it doesn't mean that for the project itself PHP isn't, sometimes, the best option for the project.
For people who want to create a web app and don't have much programming experience, PHP can still be the best choice - it's easy to deploy, it has great official and unofficial docs, it's easiest to find developers for and it's pretty reliable.
Now, this may sound crazy to many, but not only PHP has some good sides, a lot of them come from intelligent choices its designers made: for example, PHP script only runs in context of the request - no application server here - which helps reliability since memory leaking etc scripts can't cause too much harm. PHP's basically saw itself merely as an Apache module - in a rare, pre-hyposhpere display of egoless coding - making it extremely easy to deploy (compare and contrast with Rails before Passenger). The fact it comes with so many libraries welded into the common namespace is ugly for me, but a boon for beginners, and the fact you can mix PHP and HTML allowed many web designers to tinker with it, gradually moving from design to HTML to PHP - one of whom ended up writing Wordpress, I think :)
With the (possible?) exceptions of Wikipedia and WordPress PHP is used by these sides for the fairly thin front-end layer. The core algorithmic functionality is implemented in (usually) Java and C++ and occasionally Erlang, Python and Perl.
In fact, I am willing to argue that there's more reason to use something else if your app is simpler (i.e. it's a monolithic web application): you can add functionality without resorting to a more complex multi-tier/service oriented architecture or writing C-based extensions.
The article is about PHP & Python. Erlang, C++ and Java don't really compete in the same space - I doubt writing any of these sites in Python would mean they wouldn't need Erlang or C++.
Python is, in many cases, a serious contender for Java and C++. E.g. if you're dealing with any sort of machine learning (suppose you wish to add a recommendation engine to your site), Python (e.g. with NumPy) is more than capable of that (although these scripts will generally ran standalone, they could still use the same libraries for fetching user data).
Yes, there are many cases where Python/Perl/Ruby can't do what Java/C++/Erlang can, but their capabilities stretch far longer than those of PHP. PHP essentially limits you to front-end web development; writing standalone scripts/tools/daemons in PHP -- been there, when a boss at a startup I worked in refused to allow me to use any other language -- is horribly painful.
There's a progression between "simple CRUD pages" and "complex, service oriented architecture". Python can fill a lot more on that continuum.
C/C++ are low level languages. C++ has object orientation, but talking to C++ from Zend is very tedious (if I am not mistaken, you essentially end up passing objects as void pointers).
Python, Ruby, Perl, Java, Erlang, allow you to do systems-programming (i.e. writing daemons, doing threading and high performance event driven/non-blocking I/O) while still retaining high-level features such as reflection/meta programming.
Speaking as someone who is tangled in a love triangle between Python and PHP. I do agree that PHP does have it's strengths. For the programmer just making a living, it's quite ok to etch out just using it.
In terms of web applications, what you can accomplish in PHP you can pretty much do in Python. But the difference comes in when you do "care" about the tools you're using.
When you want that extra power.
When you want something sane to work with.
Python and friends give provide that for you.
I do love PHP, it's deployment is a snap and the frameworks we have now are kick ass. But Python is such a joy to work with it. And the longer I work with it, it gets harder to come back to PHP.
I'm at the stage where the temptation to use PHP for something quick & dirty (a one-off script or so) is still very strong, mainly because I know all the details by heart and can pretty much realize the script as fast as I can type it in.
In python it would take me a bit more time and that time is not always available.
But the future is clear to me, no more PHP if I can help it. There are plenty of things that irritate me about python, but they are mostly things that you learn about, then it stays learned.
PHP keeps throwing up new ways to trip you up even after years of using it.
In a way I'm glad to have gone this route, in spite of the learning curve with python (and Django), I can already see it pay off when I see functions shrink to 1/3rd the size they were using PHP.
The only thing really still missing from the python under apache model is a multi threaded shared state environment.
That would really allow you to blow other solutions out of the water in terms of speed.
Now you still have to make that round trip to the database on the next page fetch.
I use PHP every day, but have grown a bit tired of the lack of sophistication inherent in the language. The huge flat namespace, the inconsistent design of the standard library, the absence of advanced language features (functions aren't even a first class data member), and so on.
You have no idea how much I wish I could do this. Just testing my code from PHP 5.2 to 5.3 and there are several serious problems now that I get to find workarounds for, all while maintaining backward compatibility too.
How is it that a minor upgrade changes functions and their behaviour so much that it breaks existing PHP5-compatible code? WTF is wrong with the PHP developers?
If I didn't have so much code (whole product with contracts to support) invested in PHP, I would switch in a heartbeat and never look back.
Do you actually know anything about languages other than PHP and want to change for legitimate reasons? Or are you just jumping on the bandwagon because it sounds cool?
I'm perfectly aware 1.8 to 1.9 was a pretty big move for Ruby folks (maybe could've been called 2.0?), and 2.x to 3 in Python, that's the time for big changes. I've also written real production software in about half a dozen languages, so yes I do. I just happen to have a codebase of 100,000+ loc in PHP that I support, so I'm kinda heavily invested in it more than the others.
It sucked trying to rework so much PHP4 code for PHP5 while keeping b/c, since that felt like the slowest community migration to a new version I've ever seen... But it seems like each additional release from PHP changes and breaks something else. My codebase is older than many, so it's possible that's made it a bit more brittle over time, but things like completely changing the allowed characters in .ini file keys from 5.2 to 5.3 I find baffling. Yes, speed things up or improve things, but consider that existing liberties you've allowed may come to be relied on by your users. If you let them do something in 5.2, make sure they can still do it in 5.3. I'm always careful myself to make sure existing code will continue to work, and new features are offered as optional or via new APIs. Code from 3.x of my software continues to run fine on 5.x as a result, which lowers my support burdens.
So again, no I'm not just fanboying for other languages or falling for the "grass is always greener" line of thinking. PHP just has certain inelegant things that I find add to my overall frustration over time. I value terseness, so things like -> versus . for objects adds up, just like $ versus nothing for variables wears at the wrists too. I value consistency, so not remembering which parameter goes first for in_array() versus strpos(), or why the differences in naming add up too. Those are minor things that have been present from the start, but then when I start getting emails from people saying my software is messing up and I find out it's just that the latest version of PHP totally broke something I'd been relying on, that frustration is amplified tenfold.
Hah, just be careful, having to go back the other way is kinda painful. I keep a file for myself called pythonisms.php in it i define a few functions that let me continue to think in ways I've come to love in python. One example, the get function. It takes 3 arguments, and works like python's dict.get(). I seriously have no idea how I did php without it.
I'm going in the other direction right now. I have a sheet of notes titled "PHP WTF". Seriously, PHP is such a mess. Thank Jesus for Thrift http://incubator.apache.org/thrift/
As a former academic gone mercenary, I love that programmers of all skill levels can get into organization, language and specification through Python. It's a wonderful gateway to learning, and in this case, it seems to have done exactly what Python was specified to do!
For my own projects, I've used pretty much all the fad languages from BASIC to Pascal to C. I've used industry-adopted languages like Tcl, Java and Perl. I've experimented with Lisp and Erlang.
After all is said and done, I like Python/Cython/C. It gives me the option to use a glue language for the Windows programming I've done, which is perfect. It gives me a compiled (albeit ctypes-restricted) subset language for writing hashing/storage/whatever functions. It gives me a super-awesome library set that comes built-in.
I know it'll go away someday, but I'm glad to have worked in Python for as long as I have.
Python is remarkable for having a dozen or so major language features disallowed by fiat (removal of the GIL, unrestricted anonymous functions, TCO, braces) but still being extremely powerful, expressive, and used by programmers of all skill levels.
It's difficult to be obscure in Python. Yet if I really need to do something jinky like remapping an outside library's methods, I can do it with a few lines of slightly-uglier code. That's a very hard balance to make.
Good design involves a lot of "no". I don't think languages are an exception.
Minor correction. The removal of the GIL is not disallowed by fiat. The removal of the GIL was attempted (via granular locking) and destroyed single threaded performance. That's unacceptable for a variety of reasons. In the same thread, Guido has repeatedly stated that the GIL was a tradeoff, and he would welcome anything that helped lessen it's impact/remove it should it be proven not to significantly harm Python's primary function.
If someone showed up with a patch tomorrow which allowed free threading without seriously breaking python, or crippling single threaded performance, or making extension modules impossible to write, I could very well see it getting in. In reality, doing this requires a serious reworking of the interpreter (ala unladen swallow) to make it even feasible. There's a lot of things the GIL actually helps, for example the ease of writing c-based extension module, unfortunately they come with a price.
The price is/was seen as an acceptable tradeoff, and I think it has served it well, even if if it disappeared tomorrow no one would shed a tear.
Minor correction. The removal of the GIL is not disallowed by fiat.
To piggyback: don't forget that CPython ≠ Python. The GIL is an implementation detail of CPython, not a feature of the language. Other Pythons -- Jython, for one -- have no GIL.
BTW, if you'd like to chat more about concurrency, I'm around all weekend (although I'm late getting to the University of Belgrano today). As my comments during your talk yesterday indicated, I think you're pretty off-base arguing that people aren't trying out interesting concurrency solutions in Python — ZODB is a (somewhat broken) STM that's been production-stable for many years, and Stackless is specifically targeted at actor-based modeling.
So I think people in the Python community have actually been way out in front on these issues. It's just that most people use Python for production work, not research, so the researchy stuff doesn't make it into the mainline.
It's occasionally difficult to be obscure with Python syntax. It's not at all difficult to be obscure with anything in Python above that level. Even then, if you do weird things with metaclasses or decorators, it's easy to be obscure with Python.
Decorators are an odd case -- I find that they make code dramatically clearer at the call-site, but that the decorator definitions get hairy fast (and get worse the more life-saving they are). They ended up being one of the best macro systems ever devised (they're applied at compile-time!).
I seriously don't under stand that statement. Decorators are callables that return callables, nothing else, nothing special. Decorator Syntax is just sugar.
Decorators can be applied any time including runtime. I'm not even sure what you mean by "compile time" in regards to Python, import time?
Only decorator syntax happens somewhere around parse-time (which I call import time, but meh).
> completely mask the def that they are applied to.
@decorator reassign to the name of the def. But if there are other refs to that def they do not change and are not "masked". It is no different than assignment. You know that these two are identical, right?
@foo
def bar():
pass
def bar():
pass
bar = foo(bar)
Also this is a perfectly valid decorater that doesn't mask the original func
def deco(func):
# do something terrible clever here
return func
decorator syntax != decorators is my main point. But by conflating the two I can begin to understand your statement.
Aside from the obvious that just about everything will go away someday, is there a reason you believe this?
From my vantage point (albiet limited) python looks like it has staying power. It is easy to use, effecient enough (and with unladen swallow in development it may get a lot more effecient soon), and currently seems to be gaining ground instead of losing. Eventually I am sure that it and any other language you can possibly name will get supplanted, but I am not aware of any particular reason to expect that any time remotely soon.
Heh, first to be clear, I agree that very few things are truly permanent. In fact, I said that in my original question. What I said is that I do not think Python will be going away any time soon, and your examples play nicely into that theme.
The Roman Empire lasted for many centuries, Jovial, Forth, and PL/1 all had very long runs. In fact, they are all still used in some limited capacities today.
I might have dated myself above by mentioning Tcl and Pascal, but I've been programming for a few decades. Without ruining the cosmic punchline: all things go away surprisingly fast.
BASIC was never a 'fad' - it was frequently all you had (other than machine code). Remember, no internet, no CDs, even no modems for the vast unwashed such as myself - just a tape deck, 16K ROM and a TV.
The first language where I got to choose it was Lisp for the Sinclair QL, ~ 1985.
